Date: Wed, 02 Jan 2002 20:17:07 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: hackers@freebsd.org Subject: Junior FS hacker task (more observations on nullfs filesystem) Message-ID: <3C33DB43.AC29E161@mindspring.com>
next in thread | raw e-mail | index | archive | help
BOUWSMA Beery wrote: > This was tried under -current (and probably -stable too) > > Should a nullfs mount handle options the way that one would > expect from a normal filesystem mount? > > In particular, I have a read-only nullfs mount, but accesses > to that read-only filesystem result in the atime being updated > on the True Filesystem. > > Remounting the nullfs with `noatime' makes no difference -- > again accessing files in the read-only directories result in > updates of the Real Filesystem. > > Only by remounting the original fs with `noatime' do I get the > wanted result, with the drawback that not only are accesses via > the nullfs path, as desired, but all other accesses to the > original filesystem get ignored. Unfortunately, what you want is "a POSIX FS interface", and what you have is "a POSIX FS". In other words, it is the FS code, not the upper level code, that enforces the POSIX semantics. You could do it the other way around, and it would simplify some things, but make other more complex. Specifically, you would move the POSIX semantics that you could to the system call layer, and out of the FSs proper. This would simplify some of the FS code. But you would have to move it into any other VFS consumer as well... currently, this means the system call layer... and the NFS server code. A lot of people feel the NFS server code is hard to grok (it's actually not that complicated... in fact, it's uncomplicated to the point of being uninteresting, except that it is the only other VFS consumer, which _makes_ it interesting. In any case, you would need to move the semantics up, and then not propagate them down in the read-only mount case, but do propagate them down in the read/write mount case. It's not a lot of work, IMO, and would be good practice for any junior FS hacker. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C33DB43.AC29E161>