linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).