From: Neil Brown <neilb@suse.de>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
linux-mtd@lists.infradead.org
Subject: Re: [RFC] Reinstate NFS exportability for JFFS2.
Date: Fri, 2 May 2008 11:38:41 +1000 [thread overview]
Message-ID: <18458.28833.539314.455215@notabene.brown> (raw)
In-Reply-To: message from David Woodhouse on Thursday May 1
On Thursday May 1, dwmw2@infradead.org wrote:
> On Thu, 2008-05-01 at 16:48 -0400, Christoph Hellwig wrote:
> > Yes, and get_fsid would be extremly useful, especially for those
> > filesystems that already have an uuid in the superblock
> > (*cough*, XFS, *cough*), but it'll need some co-operations with
> > nfs-utils on when to use it.
>
> Why do you need to co-operate with userspace? Userspace shouldn't need
> to do anything -- we'll just generate a suitable fsid/uuid for
> ourselves, unless userspace deliberately overrides it for the export in
> question.
Actually it is the kernel that doesn't need to do anything....
Mapping between the filesystem and the filesystem part of the
filehandle is done entirely in user space.
The kernel says "Here is a filehandle fragement, what filesystem
should I be accessing".
So what you really want is to teach nfs-utils to recognise JFFS2 and
extract an appropriate uuid.
It already uses libblkid to get uuids for ext3 and XFS and others.
Extending that to handle JFFS2 should be much of a drama.
>
> > Patch looks good for me except for the few introduced overlong lines.
>
> Bah, don't you start. A less onanistic problem with it is the deadlock
> with NFS readdirplus (->readdir->encode_entry->compose_entry_fh->lookup)
>
> I wonder if we should postpone the calls to compose_entry_fh() until
> _after_ readdir() has completed. Leave space in the response for the
> filehandles, but only walk through it again calling compose_entry_fh()
> once we're done in readdir. That would allow us to get rid of the
> various icky hacks that file systems have to avoid that deadlock.
Why is there a deadlock here?
Both readdir and lookup are called with i_mutex held on the directory
so there should need to do any extra locking (he said, naively). In
the readdirplus cases, i_mutex is held across both the readdir and the
lookup....
One problem with your proposed solution is that filehandles aren't all
the same length, so you cannot reliably leave space for them.
Awkward.
NeilBrown
next prev parent reply other threads:[~2008-05-02 1:38 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-01 19:42 [RFC] Reinstate NFS exportability for JFFS2 David Woodhouse
2008-05-01 20:48 ` Christoph Hellwig
2008-05-01 22:44 ` David Woodhouse
2008-05-02 1:38 ` Neil Brown [this message]
2008-05-02 11:37 ` David Woodhouse
2008-05-02 14:08 ` J. Bruce Fields
2008-07-31 21:54 ` David Woodhouse
2008-08-01 0:16 ` Neil Brown
2008-08-01 0:40 ` David Woodhouse
2008-08-01 0:52 ` David Woodhouse
2008-08-01 0:53 ` Chuck Lever
2008-08-01 1:00 ` David Woodhouse
2008-08-01 1:31 ` Chuck Lever
2008-08-01 8:13 ` David Woodhouse
2008-08-01 13:35 ` David Woodhouse
2008-08-01 13:56 ` David Woodhouse
2008-08-01 16:05 ` Chuck Lever
2008-08-01 16:19 ` David Woodhouse
2008-08-01 17:47 ` Chuck Lever
2008-08-02 18:26 ` J. Bruce Fields
2008-08-02 20:42 ` David Woodhouse
2008-08-02 21:33 ` J. Bruce Fields
2008-08-03 8:39 ` David Woodhouse
2008-08-03 11:56 ` Neil Brown
2008-08-03 17:15 ` Chuck Lever
2008-08-04 1:03 ` Neil Brown
2008-08-04 6:19 ` Chuck Lever
2008-08-05 8:51 ` Dave Chinner
2008-08-05 8:59 ` David Woodhouse
2008-08-05 9:47 ` Dave Chinner
2008-08-05 23:06 ` Neil Brown
2008-08-06 0:08 ` Dave Chinner
2008-08-06 19:56 ` J. Bruce Fields
2008-08-06 20:10 ` David Woodhouse
2008-08-09 16:47 ` David Woodhouse
2008-08-09 19:55 ` David Woodhouse
2008-08-09 20:01 ` [PATCH 1/4] Factor out nfsd_do_readdir() into its own function David Woodhouse
2008-08-09 20:07 ` Christoph Hellwig
2008-08-09 20:02 ` [PATCH 2/4] Copy XFS readdir hack into nfsd code David Woodhouse
2008-08-09 20:08 ` Christoph Hellwig
2008-08-09 20:03 ` [PATCH 3/4] Remove XFS buffered readdir hack David Woodhouse
2008-08-09 20:09 ` Christoph Hellwig
2008-08-09 20:03 ` [PATCH 4/4] Reinstate NFS exportability David Woodhouse
2008-08-09 20:10 ` Christoph Hellwig
2008-08-04 18:41 ` [RFC] Reinstate NFS exportability for JFFS2 J. Bruce Fields
2008-08-04 22:37 ` Neil Brown
2008-08-17 18:22 ` Andreas Dilger
2008-08-01 2:14 ` Neil Brown
2008-08-01 8:50 ` David Woodhouse
2008-08-01 10:03 ` Al Viro
2008-08-01 23:11 ` Neil Brown
2008-07-31 21:54 ` [PATCH 1/4] Factor out nfsd_do_readdir() into its own function David Woodhouse
2008-07-31 21:54 ` [PATCH 2/4] Copy XFS readdir hack into nfsd code, introduce FS_NO_LOOKUP_IN_READDIR flag David Woodhouse
2008-07-31 21:55 ` [PATCH 3/4] Switch XFS to using FS_NO_LOOKUP_IN_READDIR, remove local readdir hack David Woodhouse
2008-07-31 21:55 ` [PATCH 4/4] [JFFS2] Reinstate NFS exportability David Woodhouse
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=18458.28833.539314.455215@notabene.brown \
--to=neilb@suse.de \
--cc=dwmw2@infradead.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
/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