From: David Woodhouse <dwmw2@infradead.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [RFC] Reinstate NFS exportability for JFFS2.
Date: Thu, 01 May 2008 23:44:58 +0100 [thread overview]
Message-ID: <1209681898.25560.613.camel@pmac.infradead.org> (raw)
In-Reply-To: <20080501204820.GA5951@infradead.org>
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.
> 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.
--
dwmw2
next prev parent reply other threads:[~2008-05-01 22:44 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 [this message]
2008-05-02 1:38 ` Neil Brown
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=1209681898.25560.613.camel@pmac.infradead.org \
--to=dwmw2@infradead.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.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