On Thu, Oct 17, 2013 at 12:09:00PM -0700, Linus Torvalds wrote: > All it needs is a non-unixy filesystem getting nfs-exported. Like FAT. > > Now, I actually think that FAT is fine with unlinking a file that is > in use, but my whole argument was "unintended consequences". It is > *not* obvious that keeping a reference is valid. > > Look at rmdir() instead of unlink(), for example. Even POSIX allows > EBUSY for a directory entry that is still in use, and requires it for > a non-empty one. So even with a Unix filesystem, I can imagine > somebody (and by somebody, I mean "knfsd, as response to normal NFS > client traffic") doing: > > - read file (delayed fput) > - unlink file > - rmdir directory that file used to be in and that *should* be empty > - delayed fput happens now. > > and even a posix-compliant filesystem could have issues with this > (again, the *example* for a filesystem with issues would be NFS, and I > realize you don't re-export it, but the point is, filesystem semantics > can make this problematic). Sure, I agree that such a scenario might happen; the question was "which fs would have to be exported to step on that?" and AFAICS none of the exportable filesystems have any problems of that sort. > Again, the above is an *example* of subtle issues with delaying the fput. And we have a tool for dealing with those, if they turn out to be real - flush_delayed_fput(), doing all pending delayed ones. I would rather avoid using it unless we have a case where it's really needed, though; it can have interesting consequences wrt locking order, etc. Frankly, in case of knfsd I'm a lot more concerned about the amount of struct file (all for the same few disk files) sitting around opened and waiting to be closed, just because there's a client saturating a 10G link with read requests... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
