mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kyle Moffett <mrmacman_g4@mac.com>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: Markus Klotzbuecher <mk@creamnet.de>, linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] mini_fo-0.6.0 overlay file system
Date: Fri, 13 May 2005 07:26:14 -0400	[thread overview]
Message-ID: <7E4FD3AB-54F6-43D5-9340-ECEEA2E55C0B@mac.com> (raw)
In-Reply-To: <20050513080137.GA9255@wohnheim.fh-wedel.de>

On May 13, 2005, at 04:01:37, Jörn Engel wrote:
> Doesn't even have to be interruptable.

Well, I wrote in my first mail:

> On Thu, 12 May 2005 23:18:36 -0400, Kyle Moffett wrote:
>> 1) This system should be a first-class VFS element, IE: -o union  
>> should
>> work on all filesystems, regardless of feature support.

I'd like to have -o union work not just on ext2/3.  It could  
potentially be
very _slow_ on other filesystems, until they get nonresident file  
support,
but it would definitely need to be an interruptible page copy in that  
case.

> Your trick, if I understand it correctly, is to copy data up on a  
> block
> level, not on a file level.

Precisely.

>> That way, if I later unmounted the unioned ext3 fs and remounted it
>> elsewhere without the underlying storage, I would be able to  
>> access the
>> parts of the directory structure and files that are resident, and the
>> rest would fail with a new error code ENONRESIDENT or similar.
>
> ENONRESIDENT bugs me somehow.  I guess EIO would be quite sufficient.

Hmm.  Ideally a program like tar would be able to determine which  
pages of
a file are resident in memory and only store those.  How does this  
currently
work for sparse files?

> Maybe you also want a new incompatible fs flag, just to make sure old
> kernels without proper understanding don't mess up the fs.

Definitely.  You'd only need to set this if there were any  
nonresident files,
however, and those would probably only be created if you union  
mounted with
"-o nonres" or similar.

>> If they deleted /dev/hdb1, but still wanted whatever changes they had
>> made on /dev/hdb2, they could always get at them by remounting / 
>> dev/hdb2
>> somewhere _without_ "-o union", and use a modified tar to package  
>> up the
>> resident portions of files the same way it does for sparse files.
>> Naturally there would need to be a way to mark a sparse file's empty
>> spaces as nonresident if so desired when untarring.
>
> That's the old well-known (to some people) union-mount behaviour.

I'm just describing the whole idea in totality, so that everybody can  
get an
idea of what's going on.

> Really, your idea of a block (page, whatever) level granularity for
> copying data is nice.

I liked the idea of the existing linux sparse file support, so I  
based it off
that.

> It solves the biggest concern I had left for union mount.  Actually
> implementing it, though, depends on quite a bit of infrastructure  
> that just
> doesn't exist yet.  Still, a very interesting idea.

For ext2/ext3, the sparse-file-support _does_ exist, so the only  
major parts
that need to be added are:
     o An extra ext2/ext3 flag that indicates nonresidence (For both  
sparse
       files, normal files, and directories).
     o VFS-level support for the union operation with hooks to let each
       filesystem do something special.





Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$  
r  !y?(-)
------END GEEK CODE BLOCK------




  reply	other threads:[~2005-05-13 11:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-09 18:40 Markus Klotzbuecher
2005-05-10  6:07 ` Eric Lammerts
2005-05-10 15:29   ` Lee Revell
2005-05-10 15:42     ` Arjan van de Ven
2005-05-10 17:01   ` Markus Klotzbuecher
2005-05-12 12:18 ` Jörn Engel
2005-05-12 16:44   ` Markus Klotzbuecher
2005-05-13  3:18     ` Kyle Moffett
2005-05-13  8:01       ` Jörn Engel
2005-05-13 11:26         ` Kyle Moffett [this message]
2005-05-13 12:24           ` Jörn Engel
2005-05-13 20:57             ` Kyle Moffett
2005-05-13 12:49       ` Jan Blunck
2005-05-13 20:18       ` Markus Klotzbuecher

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=7E4FD3AB-54F6-43D5-9340-ECEEA2E55C0B@mac.com \
    --to=mrmacman_g4@mac.com \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mk@creamnet.de \
    /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

all inboxes | Powered by JetHome®