Messages in this thread | | | Date | Wed, 5 Sep 2012 06:45:43 +1000 | From | NeilBrown <> | Subject | Re: [PATCH v2 4/5] fat: eliminate orphaned inode number allocation |
| |
On Tue, 4 Sep 2012 15:25:09 -0400 "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Wed, Sep 05, 2012 at 04:02:13AM +0900, OGAWA Hirofumi wrote: > > "J. Bruce Fields" <bfields@fieldses.org> writes: > > > > > On Wed, Sep 05, 2012 at 02:07:40AM +0900, OGAWA Hirofumi wrote: > > >> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes: > > >> > > >> > Namjae Jeon <linkinjeon@gmail.com> writes: > > >> > > > >> >> From: Namjae Jeon <namjae.jeon@samsung.com> > > >> >> > > >> >> Maintain a list of inode(i_pos) numbers of orphaned inodes (i.e the > > >> >> inodes that have been unlinked but still having open file > > >> >> descriptors).At file/directory creation time, skip using such i_pos > > >> >> values.Removal of the i_pos from the list is done during inode eviction. > > >> > > > >> > What happens if the directory (has busy entries) was completely removed? > > >> > > > >> > > > >> > And Al's point is important for NFS too. If you want stable ino for NFS, > > >> > you never can't change it. > > >> > > >> s/never can't/never can/ > > > > > > If vfat exports aren't fixable, maybe we should just remove that > > > feature? > > > > > > I'm afraid that having unfixable half-working vfat exports is just an > > > attractive nuisance that causes users and developers to waste their > > > time.... > > > > In historically, it was introduced by Neil Brown, when nfs export > > interface was rewritten (I'm not sure what was intended). > > > > Personally, I'm ok to remove it though, it is really personal > > opinion. The state would be rather I don't have strong opinion to > > remove. > > Neil, any opinion? > > If we can document circumstances under which nfs exports of fat > filesystems are reliable, fine. > > Otherwise I'd rather just be clear that we don't support it. > > --b.
I think that is important to maintain support for NFS export of VFAT on a best-effort basis. We can't provide 100% guarantees of all NFS semantics but that doesn't prevent it from being of real practical benefit to people.
If the usage pattern is "open/read/close" or "open/write/close" while no other client is accessing the filesystem and while the server is not under aggressive memory pressure, then it should work quite reliably.
If you rename files while they are open, have lots of file concurrently open, allow the server to experience high memory pressure (e.g. reading/writing multiple files that are bigger than memory) etc etc then things can start to fail.
VFAT is widely used as a file-transfer protocol. If you use NFS/VFAT in that way it works fine. If you try to use it as a general file access protocol, that is when you hit problems.
The patch series tries to make inode number stable across reboot. I think this is not worth the effort as you won't make VFAT access more reliable, you'll just make it fail differently.
The only real answer to more reliable NFS access to VFAT is the NFSv4 concept of volatile file handles. Unfortunately NFSv4 hasn't yet specified these with sufficient precision to actually use them.
So if anyone wants to improve VFAT/NFS, I suggest that the first step is to work with the NFSV4-WG to get an implementable specification. Good luck with that.
NeilBrown [unhandled content-type:application/pgp-signature] | |