Re: [OFFTOPIC] Hardlink utility - reclaim drive space

[Jeremy Jackson <jerj@coplanar.net>]

Padraig Brady wrote:

> Hmm.. useful until you actually want to modify a linked file,
> but then your modifying the file in all "merged" trees.
> Wouldn't it be cool to have an extended attribute
> for files called "Copy on Write", so then you could
> hardlink all duplicate files together, but when a file is
> modified a copy is transparently created.
> Actually should it be called "Copy On Modify"? since if
> you copied a file there would be no need to make an actual
> copy until the file was modified.
>
> The only problem I see with this is that you wouldn't have
> enough space to store a copy of a file, what would you do
> in this case, just return an error on write?
>
> Is there any way this could be extended across filesystems?
> I suppose you could add it on top of existing DFS'?
>
> I could see many uses for this, like backup systems, but perhaps
> a block level system is more appropriate in this case?
> (like the just announced SnapFS).
>
> Is there any filesystem that supports this @ present?
>
> Padraig.
>
> William Stearns wrote:
>
> > Good day, all,
> >       Sorry for the offtopic post; I sincerely believe this will be
> > useful to developers with multiple copies of, say, the linux kernel tree
> > on their drives.  I'll be brief.  Please followup to private mail -
> > thanks.
> >       Freedups scans the directories you give it for identical files and
> > hardlinks them together to save drive space.  Please see
> > ftp://ftp.stearns.org/pub/freedups .  V0.2.1 is up there; it has received
> > some testing, but may yet contain bugs.
> >       I was able to recover ~676M by running it against 8 different
> > 2.4.x kernel trees with different patches that originally contained ~948M
> > of files.  YMMV.
> >       I do understand there are better ways to handle this problem (cp
> > -av --link, cvs? Bitkeeper, deleting unneeded trees, tarring up trees,
> > etc.).  See the readme for a little discussion on this.  This is just one
> > approach that may be useful in some situations.
> >       Cheers,
> >       - Bill

snapFS might handle this - versioning, copy-on-write disk file
clones... even finer grained: only modified blocks of a file are
duplicated, not the entire file, and it does this in real-time.

in the case of kernel, why not get the whole repository?
CVS stores versions as diffs internally, saving space.