From: Valerie Aurora <vaurora@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: viro@zeniv.linux.org.uk, hch@infradead.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
jblunck@suse.de
Subject: Re: [PATCH 1/6] union-mount: Introduce union_mount structure and basic operations
Date: Wed, 3 Mar 2010 15:45:13 -0500 [thread overview]
Message-ID: <20100303204513.GC19689@shell> (raw)
In-Reply-To: <E1NmsRk-0003tE-BO@pomaz-ex.szeredi.hu>
On Wed, Mar 03, 2010 at 06:33:20PM +0100, Miklos Szeredi wrote:
> On Tue, 2 Mar 2010, Valerie Aurora wrote:
> > +struct union_mount *union_alloc(struct dentry *this, struct vfsmount *this_mnt,
> > + struct dentry *next, struct vfsmount *next_mnt)
>
>
> Why doesn't union_alloc, append_to_union, union_lookup,
> union_down_one, etc use "struct path *" arg instead of separate
> vfsmount and dentry pointers?
I'd prefer that too, but it isn't a clear win. For append_to_union(),
the reason is that we call it when a file system is mounted, using mnt
and mnt->mnt_root as the first args:
int attach_mnt_union(struct vfsmount *mnt, struct vfsmount *dest_mnt,
struct dentry *dest_dentry)
{
if (!IS_MNT_UNION(mnt))
return 0;
return append_to_union(mnt, mnt->mnt_root, dest_mnt, dest_dentry);
}
Same thing happens in detach_mnt_union() with union_lookup(). That
trickles down into the rest. I suppose I could create a temporary
path variable for those two functions and then we'd be paths
everywhere else. What do you think?
> > + um = kmem_cache_alloc(union_cache, GFP_ATOMIC);
> > + if (!um)
> > + return NULL;
> > +
> > + atomic_set(&um->u_count, 1);
>
> Why is u_count not a "struct kref"?
We stole this from the inode cache code, so for the same reason inodes
have i_count as atomic_t instead of a kref (whatever that is). :)
> > > +/*
> > + * WARNING! Confusing terminology alert.
> > + *
> > + * Note that the directions "up" and "down" in union mounts are the
> > + * opposite of "up" and "down" in normal VFS operation terminology.
> > + * "up" in the rest of the VFS means "towards the root of the mount
> > + * tree." If you mount B on top of A, following B "up" will get you
> > + * A. In union mounts, "up" means "towards the most recently mounted
> > + * layer of the union stack." If you union mount B on top of A,
> > + * following A "up" will get you to B. Another way to put it is that
> > + * "up" in the VFS means going from this mount towards the direction
> > + * of its mnt->mnt_parent pointer, but "up" in union mounts means
> > + * going in the opposite direction (until you run out of union
> > + * layers).
> > + */
>
> So if this is confusing, why not use a different terminology for union
> layers? Like "next" and "prev" like it is already used in the
> structures.
Unfortunately, "upper" and "lower" are fairly well established
concepts in layering file systems and seem to be the most natural way
for programmers to think about unioned file systems. It's only the
VFS (which most people never touch) that uses "up" and "down" in the
opposite sense. I think the better path is to replace "next" and
"prev" in the structure.
-VAL
next prev parent reply other threads:[~2010-03-03 20:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 22:11 [RFC PATCH 0/6] Union mount core rewrite v1 Valerie Aurora
2010-03-02 22:11 ` [PATCH 1/6] union-mount: Introduce union_mount structure and basic operations Valerie Aurora
2010-03-02 22:11 ` [PATCH 2/6] union-mount: Drive the union cache via dcache Valerie Aurora
2010-03-02 22:11 ` [PATCH 3/6] union-mount: Implement union lookup Valerie Aurora
2010-03-02 22:11 ` [PATCH 4/6] union-mount: Support for mounting union mount file systems Valerie Aurora
2010-03-02 22:11 ` [PATCH 5/6] union-mount: Call do_whiteout() on unlink and rmdir in unions Valerie Aurora
2010-03-02 22:11 ` [PATCH 6/6] union-mount: Copy up directory entries on first readdir() Valerie Aurora
2010-03-03 21:53 ` Multiple read-only layers in union mounts (was Re: [PATCH 6/6] union-mount: Copy up directory entries on first readdir()) Valerie Aurora
2010-03-03 17:35 ` [PATCH 2/6] union-mount: Drive the union cache via dcache Miklos Szeredi
2010-03-03 21:49 ` Valerie Aurora
2010-03-04 16:34 ` Miklos Szeredi
2010-03-09 19:22 ` Valerie Aurora
2010-03-03 17:33 ` [PATCH 1/6] union-mount: Introduce union_mount structure and basic operations Miklos Szeredi
2010-03-03 20:45 ` Valerie Aurora [this message]
2010-03-04 16:24 ` Miklos Szeredi
2010-03-09 19:49 ` Valerie Aurora
2010-03-03 17:28 ` [RFC PATCH 0/6] Union mount core rewrite v1 Miklos Szeredi
2010-03-03 20:31 ` Valerie Aurora
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=20100303204513.GC19689@shell \
--to=vaurora@redhat.com \
--cc=hch@infradead.org \
--cc=jblunck@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).