linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Horst von Brand <vonbrand@inf.utfsm.cl>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: unionfs
Date: Tue, 16 Mar 2004 19:04:13 +0100	[thread overview]
Message-ID: <20040316180413.GA22482@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <20040316173146.GB27046@wohnheim.fh-wedel.de>

On Tue, 16 March 2004 18:31:47 +0100, Jörn Engel wrote:
> On Tue, 16 March 2004 12:04:30 -0400, Horst von Brand wrote:
> > 
> > What happens if I mount the live 2.6.4 kernel source over a CD containing
> > 2.5.30? What happens to identical files, files that moved, changed files,
> > deleted files? Pray tell, how does the kernel find out which is which?
> 
> What happens if I write to /dev/hda while having my rootfs /dev/hda1?
> Bad things, damn right.  But why would anyone do that?

There is really no point to this discussion, as it looks like a big
misunderstanding.  Maybe you object less if you see the design:

Variant 1 (just a single filesystem):

- Introduce a new variant of links, which I call COW.
- COWs can only link to hidden inodes.
- Hidden inodes cannot be accessed directly.
- COWs look like regular files to userspace.
- Read access to COWs goes to the hidden inode.
- Write access to COWs copies the hidden inode before writing to it.
- Copying file1 to file2 does four things:
  - Create a new hidden inode.
  - Move data from file1 to hidden inode.
  - Turn file1 into COW and link to hidden inode.
  - Create COW for file2 and link to hidden inode.

There are some more special cases, but this is basically it.  So let's
use the stuff a little:

$ cp -cr dir1 dir2

Behaves similar to 'cp -lr', but creates COWs instead of hard links.
Can take a few seconds to create the directories, but not minutes.

$ vi dir2/bunch*of*files

Writing to those files makes a real copy for each.  dir1/* remains
unaffected, no matter how careless you are.  We've made it foolproof,
so the universe has to create greater fools again, right?

$ rm -rf dir2

Scraps one of the copies along with all modifications.  dir1/* remains
unaffected gain.

$ cp -cr /fs1/dir1 /fs2/dir2

Fails, since links between different filesystems don't work.


Variant 2 (across multiple filesystems now):

- COWs contain a filesystem identifier as well.
- Accessing COWs linking to unavaillable filesystems returns -E...
Alternatively:
- Mounting such an fs fails, unless all links work.

Usage is as above.

$ mkfs /dev/fs2
$ mount /dev/fs2 /fs2
$ cp -cr /fs1 /fs2

Creates an identical copy of one filesystem on another one.  fs2 has
to support COWs and fs2 has to be RO or support COWs.  A rw-fs mounted
ro means trouble, as you know.


Maybe I'm just stupid and missed some important detail, but this
design looks like it can solve a bunch of problems.  Do you still
think, it is useless?

Jörn

-- 
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories

  reply	other threads:[~2004-03-16 18:04 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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                   ` Jörn Engel [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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       ` unionfs Miklos Szeredi
2004-03-12 23:37 ` unionfs Herbert Poetzl

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=20040316180413.GA22482@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vonbrand@inf.utfsm.cl \
    /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).