On Wed, Sep 05, 2012 at 04:02:13AM +0900, OGAWA Hirofumi wrote: > "J. Bruce Fields" <bfie...@fieldses.org> writes: > > > On Wed, Sep 05, 2012 at 02:07:40AM +0900, OGAWA Hirofumi wrote: > >> OGAWA Hirofumi <hirof...@mail.parknet.co.jp> writes: > >> > >> > Namjae Jeon <linkinj...@gmail.com> writes: > >> > > >> >> From: Namjae Jeon <namjae.j...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
