Re: [OT] Microsoft invents symbolic links

From: yoann@mandrakesoft.com
Date: Sat Mar 04 2000 - 09:32:32 EST


Ville Herva <vherva@niksula.hut.fi> writes:

> > From: Pavel Machek <pavel@suse.cz>
> > Date: Thu, 2 Mar 2000 23:40:32 +0100
> > Subject: Re: [OT] Microsoft invents symbolic links
> >
> > Actually, 40% of my disk capacity is wasted in duplicates. Why? I do cp
> > -a linux linux.backup before major changes. Automagicall ways to get
>
> I can't even guess what the ratio is on a small companys (like ours) file
> server filled with old source versions and documents copies.

ever tryed cvs ?

>
> > space back would be nice. (I also cp -a package ofic.package, so that I
> > can diff -ur later... Hardlinks are not enough because I do not want to
> > accidentaly trash ofic.)
> >
> > So, I'd actually like cow-link. cp -a --cow-link mc ofic.mc would be
> > very usefull for me.
>
> I second that. We do incremantal backups with
>
> cp -al yesterdays-backup/ todays-backup/
> rsync --archive --hard-links --whole-file --delete /backed-up-dir todays-backup
>
> Of course, that works just fine (with very good disk space usage, since we
> also use e2compr). But with cow-links, you could backup your working
> (source, document, image) directory and not worry about disk space usage
> or your editor creating new inode on save.
>
> On file servers there definetely are a lot of duplicates. Text documents,
> source, images tend to be duplicated - people have their personal copies.
> People hacking on source have multiple copies of it.
>
> You could have a cowlinkd running nightly on file server and finding and
> cow-linking those duplicates. (It could e2compr less used files as well).
>

yes, and introduce overhead in the kernel because each time you copy /
modify a file, it would have to verify if it is a 'cow link';
and if it is it'll end up moving from a "cow link" to a normal file.

> Of course, to get the most out of the redundancy in, say, document or
> source tree, the cow-scheme would have to be on block level rather than
> inode level (as it is page level in vm). I suppose that just wouldn't even
> theoretically be affortable, since it would propably take per-block
> reference counting.

-- 
		-- Yoann http://prelude.sourceforge.net
 It is well known that M$ product don't make a free() after a malloc(),
the unix community wish them good luck for their future developement.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:16 EST