From: bfields@fieldses.org (J. Bruce Fields)
To: Fabian Frederick <fabf@skynet.be>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, neilb@suse.com
Subject: Re: [PATCH 3/6 linux-next] fs/affs: make affs exportable
Date: Fri, 13 Jan 2017 12:39:12 -0500 [thread overview]
Message-ID: <20170113173912.GH24709@fieldses.org> (raw)
In-Reply-To: <736635494.1055379.1483509211858.open-xchange@webmail.nmp.proximus.be>
On Wed, Jan 04, 2017 at 06:53:31AM +0100, Fabian Frederick wrote:
>
>
> > On 03 January 2017 at 23:29 Al Viro <viro@ZenIV.linux.org.uk> wrote:
> >
> >
> > On Tue, Jan 03, 2017 at 10:30:39PM +0100, Fabian Frederick wrote:
> > > Add standard functions making AFFS work with NFS.
> > >
> > > Functions based on ext4 implementation.
> > > Tested on loop device.
> >
> > How the hell is that supposed to work with cold dcache? You don't have
> > ->get_parent() there at all...
> >
> > There *IS* a reference to parent directory in those suckers - not the same
> > kind as in normal unix filesystems (".." is not a directory entry there -
> > it's all fake), but it's doable. be32_to_cpu(AFFS_TAIL(sb, bh)->parent)
> > would be the inumber you need, where bh is the inode block of directory.
> >
> > So it can be done, but not in this form. NAK for the time being...
>
> I worked on that function declared optional in
> Documentation/filesystems/nfs/Exporting
> but was unable to test it.
If we're going to reject patches that don't implement get_parent (and I
think we should), then we should replace "optional but strongly
recommended" there by just "mandatory". Any objections?
--b.
next prev parent reply other threads:[~2017-01-13 17:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-03 21:30 [PATCH 3/6 linux-next] fs/affs: make affs exportable Fabian Frederick
2017-01-03 22:29 ` Al Viro
2017-01-04 5:53 ` Fabian Frederick
2017-01-13 17:39 ` J. Bruce Fields [this message]
2017-01-13 18:52 ` Christoph Hellwig
2017-01-13 19:03 ` J. Bruce Fields
2017-01-13 19:57 ` Al Viro
2017-01-13 20:02 ` J. Bruce Fields
2017-01-04 17:51 ` Fabian Frederick
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=20170113173912.GH24709@fieldses.org \
--to=bfields@fieldses.org \
--cc=akpm@linux-foundation.org \
--cc=fabf@skynet.be \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.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.