Messages in this thread | | | Date | Tue, 4 Sep 2012 15:25:09 -0400 | From | "J. Bruce Fields" <> | Subject | Re: [PATCH v2 4/5] fat: eliminate orphaned inode number allocation |
| |
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.
| |