From: ebiederm@xmission.com (Eric W. Biederman)
To: Jamie Lokier <jamie@shareable.org>
Cc: "Jörn Engel" <joern@wohnheim.fh-wedel.de>,
"Davide Libenzi" <davidel@xmailserver.org>,
"Patrick J. LoPresti" <patl@users.sourceforge.net>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cowlinks v2
Date: 27 Mar 2004 14:00:45 -0700 [thread overview]
Message-ID: <m1vfkq80oy.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20040327102828.GA21884@mail.shareable.org>
Jamie Lokier <jamie@shareable.org> writes:
> Eric W. Biederman wrote:
> > It is easy to add something like a cowstat or a readcowlink and teach
> > the few programs that care (i.e. diff, tar,...) how to use it. So I
> > would rather concentrate on making cow links look like a separate copy
> > than early optimizations.
>
> I agree, having each cowlink look like a separate copy, with separate
> inode numbers, is best. That _is_ POSIX compatible -- the sharing is
> just a storage optimisation, and programs which only use the POSIX API
> won't see the difference.
>
> I have no problem with adding cowstat() to diff, and I'm sure other
> people will eventually extend rsync and tar to use it, if it becomes
> widely used.
>
> It's not the simplest solution, though. The filesystem changes are
> non-trivial. (The simplest solution is just an ext2 attribute which
> says you can't write to the file if it has >1 links).
There are two possible implementations strategies for implementing
cow files. You can either start as Jörn did with hardlinks, or you
can start with symlinks.
The set of tradeoffs is interesting. When using hardlinks the only
sane thing to do is to change the inode number when you do a copy.
You are limited to normal files, no directories, no symlinks, and the
original must resided on the same filesystem as the copy. In addition
a copy will always have a link count of one. So on that score I
see a hard time getting POSIX semantics out of the a hard link based
cow.
When you start with symlinks the tradeoffs are different. You only
trigger a copy on write when you go through the copy not when you
write through the original. You get distinct inodes for free. They
can be straight forwardly extended to work on symlinks and other node
types. You can have multiple links at the end of the copy, because
symlinks can be hard linked. The original can be stored on another
filesystem. If you don't change the original you get POSIX semantics.
As for simplicity I think the two approaches are roughly equal.
As my memory has it the proto implementation I saw using a stackable
fs and cow symlinks was about a 1000 lines. And it was that large
because it was complete (i.e. it did the copies including copying
directories.)
Eric
next prev parent reply other threads:[~2004-03-27 21:01 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-20 8:34 Jörn Engel
2004-03-20 8:49 ` Andrew Morton
2004-03-20 11:27 ` Jörn Engel
2004-03-20 19:28 ` Andrew Morton
2004-03-21 12:43 ` Jörn Engel
2004-03-21 18:53 ` Jörn Engel
[not found] ` <mit.lcs.mail.linux-kernel/20040320083411.GA25934@wohnheim.fh-wedel.de>
2004-03-20 15:03 ` Patrick J. LoPresti
2004-03-20 15:23 ` Jörn Engel
2004-03-29 17:12 ` Pavel Machek
2004-03-29 21:05 ` Patrick J. LoPresti
2004-03-29 23:16 ` Pavel Machek
2004-03-31 14:34 ` Jamie Lokier
2004-03-31 14:45 ` Pavel Machek
2004-03-31 15:20 ` Jamie Lokier
2004-04-02 11:44 ` Tim Connors
2004-04-02 16:54 ` Jörn Engel
2004-04-02 18:01 ` Pavel Machek
2004-04-02 18:17 ` Jörn Engel
2004-04-02 18:23 ` Pavel Machek
2004-04-02 19:28 ` Ross Biro
2004-04-02 21:35 ` Pavel Machek
2004-04-05 8:12 ` Jörn Engel
2004-04-05 8:19 ` Pavel Machek
2004-04-05 8:45 ` Jörn Engel
2004-04-02 20:09 ` Jamie Lokier
2004-04-02 21:39 ` Pavel Machek
2004-04-02 22:00 ` Chris Friesen
2004-04-03 0:49 ` Jamie Lokier
2004-04-03 8:23 ` Pavel Machek
2004-04-03 13:15 ` Jamie Lokier
2004-04-05 8:19 ` Jörn Engel
2004-04-05 8:22 ` Pavel Machek
2004-04-03 0:46 ` Jamie Lokier
2004-04-03 1:04 ` Jamie Lokier
2004-04-03 1:21 ` Erik Andersen
2004-04-03 1:59 ` Jamie Lokier
2004-04-03 3:55 ` Ross Biro
2004-04-03 9:09 ` Pavel Machek
2004-04-03 13:27 ` Jamie Lokier
2004-04-03 18:39 ` Eric W. Biederman
2004-04-03 19:43 ` Jamie Lokier
2004-04-03 20:30 ` Eric W. Biederman
2004-04-03 21:59 ` Jamie Lokier
2004-04-04 8:15 ` Eric W. Biederman
2004-04-05 8:35 ` Jörn Engel
2004-04-05 9:15 ` Eric W. Biederman
2004-04-05 9:18 ` Jörn Engel
2004-04-05 11:43 ` Pavel Machek
2004-04-05 12:17 ` Jamie Lokier
2004-04-05 12:39 ` Jamie Lokier
2004-04-05 12:41 ` Jamie Lokier
2004-04-05 18:03 ` Jörn Engel
2004-04-05 11:10 ` jlnance
2004-04-05 11:46 ` Pavel Machek
2004-04-05 12:35 ` Jamie Lokier
2004-04-05 8:43 ` Jörn Engel
2004-04-03 19:47 ` Eric W. Biederman
2004-04-05 8:54 ` Jörn Engel
2004-04-05 9:07 ` Eric W. Biederman
2004-03-20 16:48 ` Davide Libenzi
2004-03-21 12:57 ` Jörn Engel
2004-03-21 17:59 ` Davide Libenzi
2004-03-21 18:14 ` Jörn Engel
2004-03-21 20:26 ` Davide Libenzi
2004-03-21 20:35 ` Jörn Engel
2004-03-22 0:18 ` Eric W. Biederman
2004-03-22 0:25 ` Davide Libenzi
2004-03-22 5:07 ` Eric W. Biederman
2004-03-22 5:11 ` Davide Libenzi
2004-03-22 11:20 ` Eric W. Biederman
2004-03-22 16:02 ` Davide Libenzi
2004-03-25 17:49 ` Jamie Lokier
2004-03-25 18:06 ` Eric W. Biederman
2004-03-25 19:43 ` Jamie Lokier
2004-03-25 20:38 ` Linus Torvalds
2004-03-25 22:16 ` Eric W. Biederman
2004-04-01 14:53 ` Jörn Engel
2004-04-02 11:54 ` Tim Connors
2004-03-25 21:46 ` Eric W. Biederman
2004-03-27 10:28 ` Jamie Lokier
2004-03-27 21:00 ` Eric W. Biederman [this message]
2004-03-27 21:42 ` Jamie Lokier
2004-03-27 23:45 ` Eric W. Biederman
2004-03-28 0:43 ` Eric W. Biederman
2004-03-28 12:22 ` Jamie Lokier
2004-03-28 20:07 ` Eric W. Biederman
2004-03-28 23:55 ` Jamie Lokier
2004-03-29 1:31 ` Eric W. Biederman
2004-03-29 12:36 ` Jamie Lokier
2004-03-29 19:36 ` Eric W. Biederman
2004-03-29 23:05 ` Jamie Lokier
2004-03-29 23:58 ` Eric W. Biederman
2004-03-29 7:45 ` Denis Vlasenko
2004-03-29 9:28 ` Pavel Machek
2004-03-29 12:40 ` Jamie Lokier
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=m1vfkq80oy.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=davidel@xmailserver.org \
--cc=jamie@shareable.org \
--cc=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.org \
--cc=patl@users.sourceforge.net \
/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®