From: Goswin von Brederlow <goswin-v-b@web.de>
To: Bernd Schubert <bs_lists@aakef.fastmail.fm>
Cc: fuse-devel@lists.sourceforge.net,
Goswin von Brederlow <goswin-v-b@web.de>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel@vger.kernel.org
Subject: Re: [fuse-devel] delta filesystem prototype
Date: Sun, 01 Mar 2009 11:17:09 +0100 [thread overview]
Message-ID: <87eixhfsyi.fsf@frosties.localdomain> (raw)
In-Reply-To: <200903010138.39329.bs_lists@aakef.fastmail.fm> (Bernd Schubert's message of "Sun, 1 Mar 2009 01:38:38 +0100")
Bernd Schubert <bs_lists@aakef.fastmail.fm> writes:
> On Saturday 28 February 2009, Goswin von Brederlow wrote:
>> Miklos Szeredi <miklos@szeredi.hu> writes:
>> > Here is my first try at a "delta" filesystem. It takes two
>> > directories, one of which is a read-only base, and the other is where
>> > the differences are stored. It stores data, metadata and directory
>> > modifications without copying up whole files from the read-only
>> > branch.
>> >
>> > The layout of the delta store may look similar to the writable branch
>> > of a union fs, but this is basically just coincidence (it was easier
>> > to start out this way).
>> >
>> > Currently it's implemented with fuse and it's not optimized at all, so
>> > performance may suck in some cases. But I think this is a useful
>> > concept and a better model, than trying to fit writable branches into
>> > a union filesystem.
>> >
>> > Comments, bug reports are welcome.
>> >
>> > Thanks,
>> > Miklos
>>
>> Wouldn't it make more sense to start with unionfs-fuse and add a delta
>> feature to it? unionfs-fuse already has all you need except that it
>> will copy the whole file (if on a read-only branch) on write.
>
> Well yes, but it would need to be configurable by the user. IMMHO, the 'delta'
> ansatz has a big problem - what happens if the admin decides to modify the
> underlying ro-branch, which is a distribution chroot seen by all clients as
> their '/'? Any time files may be modified or even deleted on this branch when
> the admin does an update.
> This is also the exactly the problem why none of the kernel unionfs
> implementation fits my needs and why I started to work on unionfs-fuse. Only,
> the delta approach makes it even worse ;)
>
>
> Cheers,
> Bernd
Obviously with delta storage the underlying branches really MUST be
read-only. As for configuration I see no problem in clasifying a
branch as RO, RW or D. If the user wants a modifiable RO branch then
he can not have any D branch. Easy enough.
MfG
Goswin
next prev parent reply other threads:[~2009-03-01 10:17 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-28 14:42 delta filesystem prototype Miklos Szeredi
2009-02-28 17:22 ` [fuse-devel] " Goswin von Brederlow
2009-03-01 0:38 ` Bernd Schubert
2009-03-01 10:17 ` Goswin von Brederlow [this message]
2009-03-04 11:21 ` Miklos Szeredi
2009-03-04 14:12 ` Goswin von Brederlow
2009-03-05 13:06 ` Miklos Szeredi
2009-03-05 19:58 ` Goswin von Brederlow
2009-03-06 4:10 ` hooanon05
2009-03-06 12:37 ` Goswin von Brederlow
2009-03-07 1:16 ` hooanon05
2009-03-07 9:01 ` Goswin von Brederlow
2009-03-07 9:12 ` hooanon05
2009-03-09 12:21 ` Goswin von Brederlow
2009-03-09 13:35 ` hooanon05
2009-03-09 14:22 ` Goswin von Brederlow
2009-03-09 15:25 ` hooanon05
2009-03-10 8:14 ` Goswin von Brederlow
2009-03-09 16:36 ` Miklos Szeredi
2009-03-06 11:35 ` Miklos Szeredi
2009-03-06 12:50 ` Goswin von Brederlow
2009-03-06 13:21 ` Miklos Szeredi
2009-03-07 8:56 ` Goswin von Brederlow
2009-03-07 1:19 ` hooanon05
2009-03-07 9:03 ` Goswin von Brederlow
2009-03-07 9:16 ` hooanon05
2009-03-09 12:28 ` Goswin von Brederlow
2009-03-09 13:36 ` hooanon05
2009-03-09 14:25 ` Goswin von Brederlow
2009-03-09 15:20 ` hooanon05
2009-03-10 8:06 ` Goswin von Brederlow
2009-03-10 8:44 ` hooanon05
2009-03-12 9:22 ` Tomas M
2009-03-12 9:40 ` Goswin von Brederlow
2009-03-12 9:19 ` Tomas M
2009-03-09 14:13 ` Nikolaus Rath
2009-03-03 8:31 ` hooanon05
2009-03-03 10:59 ` [fuse-devel] " Goswin von Brederlow
2009-03-03 13:11 ` hooanon05
2009-03-03 15:27 ` Dave Kleikamp
2009-03-03 15:50 ` hooanon05
2009-03-03 15:54 ` Dave Kleikamp
2009-03-03 16:02 ` hooanon05
2009-03-03 16:14 ` Dave Kleikamp
2009-03-03 16:19 ` hooanon05
2009-03-03 16:46 ` Dave Kleikamp
2009-03-03 17:13 ` hooanon05
2009-03-04 11:52 ` Goswin von Brederlow
2009-03-04 14:10 ` Dave Kleikamp
2009-03-04 16:23 ` hooanon05
2009-03-04 11:49 ` Goswin von Brederlow
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=87eixhfsyi.fsf@frosties.localdomain \
--to=goswin-v-b@web.de \
--cc=bs_lists@aakef.fastmail.fm \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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).