linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <mszeredi@inf.bme.hu>
To: serue@us.ibm.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: unionfs
Date: Tue, 16 Mar 2004 14:43:54 +0100 (MET)	[thread overview]
Message-ID: <200403161343.i2GDhsV12878@kempelen.iit.bme.hu> (raw)
In-Reply-To: <20040315214207.GA26615@escher.cs.wm.edu> (serue@us.ibm.com)


> I was just re-reading the linux-fsdevel archives from june of 2000.
> I'm guessing the reason you're not getting a response from Al is that
> he never did unionfs.  He did union mounts, and made clear that they
> are not related.  Union mounts would only work at the top level, the
> union would not recurse down the (union-)mounted trees.

(Reading that thread...)

OK, now I understand better.  Although I can't find any code/patch for
union mount either.

> Performance-wise this could become very, very slow very quickly, but
> if we replace the vfsmount which is found by using
> mount_hashtable + hash(vfsmnt, dentry) to find what is mounted on top
> of a particular dentry with a vfsmount_stackable struct, which contains,
> say,
> 
> struct vfsmount_stackable {
> 	  struct vfsmount *vfsmnt;
> 	  int mount_flags;  /* 1 = read, 2 = write, 3 = hide */
> 	  struct vfsmount_stackable *next;
> };
> 
> then perhaps it might be reasonably simple to have __follow_down and
> follow_mount make use of this structure.  We make sure to keep the
> vfsmount_stackable list in order mounted priority, so that when we
> come to one of these lists, we can just do something like
> 
> while (vfsmount_stacked) {
> 	  ret = stacked_lookup(vfsmount_stacked->vfsmnt, vfsmnt_stacked->dentry,
> 			  remaining_pathname);
> 	  if (ret)
> 		  return ret;
> 	  vfsmnt_stacked = vfsmnt_stacked->next;
> }
> 
> return NULL;
> 
> Thoughts?

Yes, this sounds like a good way to implement a unionfs-like
functionality.  Something a bit more general would be to have a
path_walk(const char *remaining_path, struct nameidata *nd) operation
of vfsmount, which if non-null would be used to perform the rest of
the lookup.  This could then perform the looped lookup trials you
describe, but could be used for other special lookup methods.

Thanks for your comments,
Miklos


  parent reply	other threads:[~2004-03-16 13:44 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-08  9:52 unionfs Miklos Szeredi
2004-03-08 16:10 ` unionfs Bernd Schubert
2004-03-09  9:38   ` unionfs Miklos Szeredi
     [not found] ` <20040311151343.GA943@escher.cs.wm.edu>
2004-03-11 15:44   ` unionfs Miklos Szeredi
2004-03-14  2:33     ` unionfs Ian Kent
2004-03-14  4:20       ` unionfs Horst von Brand
2004-03-16 12:42       ` unionfs Miklos Szeredi
     [not found]     ` <20040315214207.GA26615@escher.cs.wm.edu>
2004-03-16 13:43       ` Miklos Szeredi [this message]
2004-03-12 23:37 ` unionfs Herbert Poetzl
2004-03-15 11:35 unionfs Carsten Otte
2004-03-15 12:19 ` unionfs Jörn Engel
2004-03-15 12:47   ` unionfs Ian Kent
2004-03-15 13:16     ` unionfs Jörn Engel
2004-03-15 14:35       ` unionfs Ian Kent
2004-03-15 16:13         ` unionfs Jörn Engel
2004-03-15 17:09           ` unionfs Claudio Martins
2004-03-15 19:22           ` unionfs Horst von Brand
2004-03-15 23:20             ` unionfs Chris Friesen
2004-03-16 16:04               ` unionfs Horst von Brand
2004-03-16 17:31                 ` unionfs Jörn Engel
2004-03-16 18:04                   ` unionfs Jörn Engel
2004-03-16 19:40                     ` unionfs Horst von Brand
2004-03-16 20:45                       ` unionfs Jörn Engel
2004-03-16 19:19                   ` unionfs Horst von Brand
2004-03-16 20:00                     ` unionfs Chris Friesen
2004-03-23  2:38                   ` unionfs Robert White
2004-03-15 23:52             ` unionfs Jörn Engel
2004-03-16 16:18               ` unionfs Horst von Brand
2004-03-16 17:10                 ` unionfs Jörn Engel
2004-03-19  9:11                   ` unionfs Jamie Lokier
2004-03-19  9:42                     ` unionfs Jörn Engel
2004-03-19  9:04                 ` unionfs Jamie Lokier
2004-03-16 19:03             ` unionfs Andy Isaacson
2004-03-15 14:37       ` unionfs Ian Kent
2004-03-15 16:15       ` unionfs Jörn Engel

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=200403161343.i2GDhsV12878@kempelen.iit.bme.hu \
    --to=mszeredi@inf.bme.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serue@us.ibm.com \
    /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).