Messages in this thread | | | Date | Tue, 19 Aug 2008 17:43:39 -0400 | Subject | Re: [malware-list] TALPA - a threat model? well sorta. | From | "J. Bruce Fields" <> |
| |
On Thu, Aug 14, 2008 at 07:34:30PM -0400, Theodore Tso wrote: > On Thu, Aug 14, 2008 at 05:21:09PM -0400, J. Bruce Fields wrote: > > > I have not yet seen code actually using it at all, neither in mainline > > > nor on one of the many nfs development lists. > > > > Oops, I'd love to, and it should be very easy. How do I find out if > > i_version is supported on a given superblock? > > We don't have a way of exporting this fact at the moment. I assume > the best way would be to add a flag in struct super. > > > There's nothing particularly "advanced" about this, by the way--this is > > a very minor variation on the caching model that nfs has always had, and > > our nfsv4 server is currently pretty broken without it. > > Well, if you're willing to try it out, as I've mentioned on my > blog[1][2], ext4 is working pretty well on my laptop --- I'm running > it as my primary filesystem. There are a few problems with ext3 > filesystems converted to use ext4, as opposed to starting afresh via > "mke2fs -t ext4dev /dev/hdXX" that we've just found in the past week > (and fixed within a day or two, although they haven't been pushed to > Linus yet), but overall, it's been pretty stable. > > So this would be a good time for someone who is familiar wiht NFSv4 to > try it out and let us know if the i_version support is as you would > like in ext4 --- we're in the bugfixing/stablization phase right now, > so this would be an ideal time to get that feedback. For more > information, on how to get started, please see: > > http://ext4.wiki.kernel.org/index.php/Ext4_Howto > > for instructions, and mount the filesystem with the "-o i_version" > mount option.
Neato, thanks. I set up a toy ext4 filesystem (just a 512 meg sparse file loopback mounted) on one of my test machines--so I just need to add the superblock flag and a bit of nfsd code and then I should be able to try it out.
> > Actually, it's pretty broken even on nfsv2/v3 for filesystems with poor > > time resolution. > > And that's fixed in ext4 as well....
That's an improvement, yes. Of course the time is still updated only every jiffy, so there's still a race:
file updated client checks ctime file updated again within a jiffy client checks ctime again, concludes file hasn't changed.
--b.
| |