Messages in this thread | | | Subject | Re: [OT] Microsoft invents symbolic links | From | yoann@mandrake ... | Date | 04 Mar 2000 15:32:32 +0100 |
| |
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/
| |