From: "J. Bruce Fields" <bfields@fieldses.org>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Namjae Jeon <linkinjeon@gmail.com>,
akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org,
Namjae Jeon <namjae.jeon@samsung.com>,
Ravishankar N <ravi.n1@samsung.com>,
Amit Sahrawat <a.sahrawat@samsung.com>, NeilBrown <neilb@suse.de>
Subject: Re: [PATCH v2 4/5] fat: eliminate orphaned inode number allocation
Date: Tue, 4 Sep 2012 15:25:09 -0400 [thread overview]
Message-ID: <20120904192509.GD29369@fieldses.org> (raw)
In-Reply-To: <87y5kp7gsq.fsf@devron.myhome.or.jp>
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.
next prev parent reply other threads:[~2012-09-04 19:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 15:58 [PATCH v2 4/5] fat: eliminate orphaned inode number allocation Namjae Jeon
2012-09-04 17:00 ` OGAWA Hirofumi
2012-09-04 17:07 ` OGAWA Hirofumi
2012-09-04 18:38 ` J. Bruce Fields
2012-09-04 19:02 ` OGAWA Hirofumi
2012-09-04 19:25 ` J. Bruce Fields [this message]
2012-09-04 20:45 ` NeilBrown
2012-09-05 13:37 ` Namjae Jeon
2012-09-05 13:56 ` OGAWA Hirofumi
2012-09-06 6:30 ` Namjae Jeon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120904192509.GD29369@fieldses.org \
--to=bfields@fieldses.org \
--cc=a.sahrawat@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linkinjeon@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=neilb@suse.de \
--cc=ravi.n1@samsung.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.