From: "Hans-Peter Jansen" <hpj@urpla.net>
To: Nick Piggin <npiggin@gmail.com>
Cc: "J. R. Okajima" <hooanon05@yahoo.co.jp>,
"linux-fsdevel" <linux-fsdevel@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: vfs-scale, keep the errno
Date: Fri, 14 Jan 2011 14:17:11 +0100 [thread overview]
Message-ID: <201101141417.11817.hpj@urpla.net> (raw)
In-Reply-To: <AANLkTi=jozto+CNwfSKu2_dGWXaRi5p=3dqQngMz7g24@mail.gmail.com>
On Friday 14 January 2011, 05:01:37 Nick Piggin wrote:
> On Fri, Jan 14, 2011 at 2:38 PM, J. R. Okajima <hooanon05@yahoo.co.jp>
wrote:
> > When open(2) without O_DIRECTORY opens an existing dir, it should
> > return EISDIR. In do_last(), the variable 'error' is initialized
> > EISDIR, but it is changed by d_revalidate() which returns any
> > positive to represent 'the target dir is valid.'
> > Should we keep and return the initialized 'error' in this case.
>
> Great, thank you very much. I just changed a few variable names but
> applied it. Would you please add you Signed-off-by: on patches from
> now on?
>
> Good reviewing work. Are you finding these by review or testing? I
> think ltptests on an nfs mount should find this kind of bug... which
> I should do.
Nick, Junjiro is well known as a very smart (and|but) humble guy in the
kernel niche of layered filesystems. Be assured, that almost every live
distribution (one, that is runnable from RO media directly) _relies_ on
his work: aufs (http://aufs.sourceforge.net/) to get the job done. Also
many diskless setups (as do mine) relies on aufs.
It's a real pity, that all other approaches to layered filesystems (or
filesystem unification, overlay filesystems), that are done by others,
are either
- technically inferior
- restricted in usage scenarios
- simply unfinished
but get more attention in the kernel guild. All, that Junjiro's approach
takes is exporting a handful of symbols in order to be able to build it
as a module also (and the number decreases as other lately merged
subsystems do need them as well, i.e. apparmor). That's all.
Layered filesystems are a killer feature, that could have been in the
kernel for years, but is still missing for hard to follow (e.g.
political, emotional) reasons. There are many interesting things, that
can be done with layered filesystems, hard to archive up to impossible
to be done otherwise).
Sadly,
Pete
next prev parent reply other threads:[~2011-01-14 13:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 3:38 J. R. Okajima
2011-01-14 4:01 ` Nick Piggin
2011-01-14 4:47 ` J. R. Okajima
2011-01-14 13:17 ` Hans-Peter Jansen [this message]
2011-01-14 15:26 ` Nick Piggin
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=201101141417.11817.hpj@urpla.net \
--to=hpj@urpla.net \
--cc=hooanon05@yahoo.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®