mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Pavel Machek <pavel@ucw.cz>
Cc: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
	linux-kernel@vger.kernel.org, Jamie Lokier <jamie@shareable.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [ANNOUNCEMENT PATCH COW] proof of concept impementation of cowlinks
Date: Mon, 10 May 2004 17:44:50 +0200	[thread overview]
Message-ID: <20040510154450.GA16182@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <20040509215351.GA15307@atrey.karlin.mff.cuni.cz>

On Sun, 9 May 2004 23:53:51 +0200, Pavel Machek wrote:
> 
> I do not see how this matters. cowlinks are already non-POSIX. If
> is_hardlinked() always returns 1, but is_cowlinked() sometimes returns
> something else, you are still "as much POSIX as possible".

Assuming that POSIX is generally pretty sane, "as sane as possible" is
good enough for me.  If POSIX is insane in one way or another,
breaking POSIX is actually a feature, imho.

> > I don't know how to handle this now. Introducing cow-inode number
> > with semantic "cowino1==cowino2 => files are cowlinked" is
> > ugly and won't deal with per-block cow. Sooner or later someone
> > will want to have per block cow. Think about cow'ing multi-gigabyte
> > database files for checkpointing/backup purposes...
> 
> Well, if only block 17 is cowlink-shared between two files, I guess
> userspace does not want to know... And I think that cow-inode number
> *can* handle all other cases.

Correct.

> Oh, get_cow_inode() should really be allowed to fail in some usefull
> way, so that filesystems do not have to implement it if its hard for
> them.

Also correct.

And while we're at it, I need a brain extention again.  Pavel? ;)

The real cowlink patch (too ugly to show it yet) is something like
this:

inode 1: real file
inode 2: cow->inode 1
inode 3: cow->inode 1

Stat() on inode 2 is implemented here:

static void cowlink_fillattr(struct inode *link, struct kstat *stat)
{
	struct super_block *sb = link->i_sb;
	ino_t ino = link->i_op->readcow(link);
	struct inode *inode = iget(sb, ino);

	stat->dev       = link->i_sb->s_dev;
	stat->ino       = ino;
	stat->mode      = link->i_mode - S_IFCOW + S_IFREG;
	stat->nlink     = link->i_nlink;
	stat->uid       = link->i_uid;
	stat->gid       = link->i_gid;
	stat->rdev      = 0;
	stat->atime     = link->i_atime;
	stat->mtime     = link->i_mtime;
	stat->ctime     = link->i_ctime;
	stat->size      = i_size_read(inode);
	stat->blocks    = inode->i_blocks;
	stat->blksize   = inode->i_blksize;
}

size, blocks and blksize has to be taken from inode 1, sure.  uid,
gid, mode and *time are from inode 2, also obvious.  dev doesn't
matter yet, but we might do cross-filesystem cowlinks someday.  nlink
should be from inode 2, so several hard links on it work, also agreed.

What about ino?  I currently return 1, so diff remains fast without
any changes.  If someone really needs the difference between inode 2
and 3, I would introduce a cstat() system call similar to lstat(),
which would return ino=2.

Is this sane?  Should it be reversed and cstat() return ino=1, while
stat returns ino=2?  I can imagine that "tar -x" would create hard
links for every cowlink that "tar -c" saw, but I'm not sure yet.

Jörn

-- 
They laughed at Galileo.  They laughed at Copernicus.  They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
-- unknown

  reply	other threads:[~2004-05-10 15:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-06 13:17 Jörn Engel
2004-05-06 13:18 ` [PATCH COW] generic_sendpage Jörn Engel
2004-05-06 13:19 ` [PATCH COW] sendfile Jörn Engel
2004-05-06 13:19 ` [PATCH COW] copyfile Jörn Engel
2004-05-06 13:20 ` [PATCH COW] lock_flags Jörn Engel
2004-05-06 13:21 ` [PATCH COW] MAD COW Jörn Engel
2004-05-08 13:45 ` [ANNOUNCEMENT PATCH COW] proof of concept impementation of cowlinks Denis Vlasenko
2004-05-08 22:10   ` Pavel Machek
2004-05-09 14:09     ` Denis Vlasenko
2004-05-09 21:53       ` Pavel Machek
2004-05-10 15:44         ` Jörn Engel [this message]
2004-05-10 15:51           ` Pavel Machek
2004-05-10 15:56             ` Jörn Engel
2004-05-12  0:26           ` Jamie Lokier
2004-05-13 10:56             ` Jörn Engel
2004-05-12 20:29         ` Rob Landley
2004-05-08 22:48 ` Pavel Machek
2004-05-10 15:53   ` Jörn Engel
2004-05-10 19:26     ` Jan Harkes
2004-05-11 10:02       ` Jörn Engel
2004-05-11 14:08         ` Jan Harkes
2004-05-11 14:18           ` Jan Harkes
2004-05-11 14:33           ` Jörn Engel
2004-05-21 23:23           ` Rob Landley
2004-05-25 22:46             ` Jan Harkes
2004-05-11 15:40         ` Steve French
2004-05-11 15:58           ` Jörn Engel
2004-05-10  5:15 ` Eric W. Biederman
2004-05-10 15:59   ` Jörn Engel
2004-05-12 16:39 ` Rob Landley
2004-05-20 13:49   ` Pavel Machek
2004-05-25 21:55     ` Rob Landley
2004-05-25 22:08       ` Pavel Machek
2004-05-25 23:16         ` Rob Landley
2004-05-26  0:16           ` Ian Stirling
2004-05-26  9:52           ` Jörn Engel

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=20040510154450.GA16182@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=ebiederm@xmission.com \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /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®