All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valerie Aurora <vaurora@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: agruen@suse.de, linuxram@us.ibm.com,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	neilb@suse.de, viro@zeniv.linux.org.uk
Subject: Re: [PATCH 6/7 v3] overlay: hybrid overlay filesystem prototype
Date: Mon, 27 Sep 2010 14:47:47 -0400	[thread overview]
Message-ID: <20100927184747.GC8089@shell> (raw)
In-Reply-To: <E1P08oT-0004C7-3O@pomaz-ex.szeredi.hu>

On Mon, Sep 27, 2010 at 10:11:53AM +0200, Miklos Szeredi wrote:
> On Fri, 24 Sep 2010, Valerie Aurora wrote:
> > On Mon, Sep 20, 2010 at 08:04:10PM +0200, Miklos Szeredi wrote:
> > > From: Miklos Szeredi <mszeredi@suse.cz>
> > > 
> > > This overlay filesystem is a hybrid of entirely filesystem based
> > > (unionfs, aufs) and entierly VFS based (union mounts) solutions.
> > 
> > [...]
> > 
> > > +static int ovl_create_object(struct dentry *dentry, int mode, dev_t rdev,
> > > +			     const char *link)
> > > +{
> > > +	int err;
> > > +	struct dentry *newdentry;
> > > +	struct dentry *upperdir;
> > > +	struct inode *inode;
> > > +	struct kstat stat = {
> > > +		.mode = mode,
> > > +		.rdev = rdev,
> > > +	};
> > > +
> > > +	err = -ENOMEM;
> > > +	inode = ovl_new_inode(dentry->d_sb, mode);
> > > +	if (!inode)
> > > +		goto out;
> > > +
> > > +	err = ovl_copy_up(dentry->d_parent);
> > > +	if (err)
> > > +		goto out_iput;
> > > +
> > > +	upperdir = ovl_dentry_upper(dentry->d_parent);
> > > +	mutex_lock_nested(&upperdir->d_inode->i_mutex, I_MUTEX_PARENT);
> > > +
> > > +	newdentry = ovl_upper_create(upperdir, dentry, &stat, link);
> > > +	err = PTR_ERR(newdentry);
> > > +	if (IS_ERR(newdentry))
> > > +		goto out_unlock;
> > > +
> > > +	if (ovl_dentry_is_opaque(dentry) && S_ISDIR(mode)) {
> > > +		err = ovl_set_opaque(newdentry);
> > > +		if (err)
> > > +			goto out_dput;
> > > +	}
> > 
> > Andreas Gruenbacher just convinced me that every single new directory
> > created in the unioned file system should be marked opaque.  "New"
> > means either it replaces a whiteout or has no matching directory on
> > the lower layer.  The theory is that the topmost file system changes
> > should take precedence and override any changes (off-line) in the
> > lower file system.
> 
> That's logical.  However marking new directories opaque is only a half
> solution.  E.g. consider the case when we have /a/b/c/ on the lower fs
> and /a/b/ on the upper, which is not opaque.  Then /a/b/c/ is created
> on the upper fs off-line.  The union logic can't notice that "c"
> should really be opaque and will merge with the contents of the lower
> layer.

Maybe I don't understand.  It seems like directories created when the
file system is *not* union mounted should definitely be merged with
matching directories on the lower layer.

Take the case of /etc/fstab.  The first union mount never touches /etc
and it doesn't exist on the topmost layer.  Then we unmount the upper
layer, mount it somewhere else as a plain mount, and create /etc/ and
/etc/fstab.  When we union mount it back over the lower layer again,
we still want the lower layer /etc/ to be merged with the topmost
/etc/, or else init.d will disappear.

However, if while the file system is union mounted, /etc/ doesn't
exist, and /etc/ is created, a later mount shouldn't merge a newly
created /etc/ on the lower layer.

> The real solution to this problem is to make opaque the default and
> only mark *non* opaque directories.  These are only created on copy-up
> or by explicit admin action on the upper fs.

Again, maybe I'm misunderstanding, but this doesn't make much sense to
me.  Say I create:

/upper/a_dir/upper_file
/lower/a_dir/lower_file

Then when I union mount them, I want a_dir/ to be transparent
automatically and show both upper_file and lower_file, without marking
it manually.

-VAL

  parent reply	other threads:[~2010-09-27 18:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-20 18:04 [PATCH 0/7 v3] overlay filesystem prototype Miklos Szeredi
2010-09-20 18:04 ` [PATCH 1/7 v3] vfs: implement open "forwarding" Miklos Szeredi
2010-09-20 18:04 ` [PATCH 2/7 v3] vfs: make i_op->permission take a dentry instead of an inode Miklos Szeredi
2010-09-20 18:04 ` [PATCH 3/7 v3] vfs: add flag to allow rename to same inode Miklos Szeredi
2010-09-23 22:04   ` Valerie Aurora
2010-09-20 18:04 ` [PATCH 4/7 v3] vfs: export do_splice_direct() to modules Miklos Szeredi
2010-09-20 18:04 ` [PATCH 5/7 v3] vfs: fix possible use after free in finish_open() Miklos Szeredi
2010-09-23 20:19   ` Valerie Aurora
2010-09-20 18:04 ` [PATCH 6/7 v3] overlay: hybrid overlay filesystem prototype Miklos Szeredi
2010-09-22 23:21   ` Valerie Aurora
2010-09-24 14:33     ` Jens Axboe
2010-09-24 17:16       ` Valerie Aurora
2010-09-24 17:56   ` Valerie Aurora
2010-09-27  8:11     ` Miklos Szeredi
2010-09-27 11:49       ` Andreas Gruenbacher
2010-09-27 12:15         ` J. R. Okajima
2010-09-27 18:47       ` Valerie Aurora [this message]
2010-09-28  8:24         ` Andreas Gruenbacher
2010-09-30 21:51           ` Valerie Aurora
2010-10-01  9:34             ` Andreas Gruenbacher
2010-10-06 17:31               ` Valerie Aurora
2010-10-06 17:31                 ` Valerie Aurora
2010-10-11  9:41                 ` Michal Suchanek
2010-10-11  9:41                   ` Michal Suchanek
2010-10-11 13:51                 ` Scott James Remnant
2010-09-20 18:04 ` [PATCH 7/7 v3] overlay: overlay filesystem documentation Miklos Szeredi
2010-09-21  1:31 ` [PATCH 0/7 v3] overlay filesystem prototype Neil Brown
2010-09-22  9:50   ` Miklos Szeredi

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=20100927184747.GC8089@shell \
    --to=vaurora@redhat.com \
    --cc=agruen@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=miklos@szeredi.hu \
    --cc=neilb@suse.de \
    --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.