Re: Versioning File Systems?

[Jeremy Jackson]

For the RPM case, where the RPM db can be out of sync
with the filesystem if the rpm command is interrupted
(not to mention db corruption), simply use LVM or EVMS
snapshot of fs before doing anything.  Haven't tried yet, but
working towards this:

eg:

init 1 ; go to single user mode
; initiate snapshot of /, /usr, /var etc - everything rpm touches
rpm -Fvh * ;
; oops power cable came out in middle
; restore snapshot to be live version (how?)
init 3 ; go back about your business, nothing to see here.

Jeremy

----- Original Message -----
From: "Kent Borg" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, April 18, 2002 8:05 AM
Subject: Versioning File Systems?

> I just read an article mentioned on Slashdot,
> <http://www.sigmaxi.org/amsci/Issues/Comsci02/Compsci2002-05.html>.
>
> It is a fascinating short summary of the history of hard disks (they
> still use the same fundamental design as the very first one) and an
> update on current technology (disks are no longer aluminum).  It also
> looks at today's 120 gigabyte disk and muses over the question of how
> we might ever put an imagined 120 terabyte disk to use.  And the got
> me thinking various thoughts, one turns into a question for this list:
> It there any work going on to make a versioning file system?
>
> I remember in VMS that I could accumulate "myfile.txt;1",
> "myfilw.txt;2", etc., until the local admin got pissed at me for using
> up all the disk space with my several megabytes of redundant files.
>
> It is time for Linux to start figuring out ways to use all the disk
> space that is on the horizon!  In a few weeks the sweet spot will be
> to buy a pair of 80 GB disks.  Disks are outpacing even Red Hat's
> "everything" install.
>
> Seriously, I have a server in the basement with a pair of 60 GB RAID 1
> disks the protect me against likely hardware failure, but they don't
> protect me against: "# rm rf /*".  They don't even let me easily back
> out a bad RPM from Red Hat.
>
> I guess I am suggesting the (more constructive) discussions over
> desirable Bitkeeper and CVS features consider what it would mean for a
> filesystem to absorb some of the key underlying features of each.
>
> As a first crack, I am imagining a file system that records every (or
> nearly every) change to every file with time stamps and sequence
> numbering.  I don't know what all the primitives would be.  It
> obviously seems much of making sense of it all would have to happen in
> userland.  Making this too powerful almost brings up some science
> fiction problems of time travel through parallel universes, but I
> think it could be kept grounded by looking at it as a powerful version
> of existing backup systems: they don't have such problems because they
> are too cumbersome for them to arise very often.
>
>
> -kb, the Kent who thinks his journaled filesystem on redundant disks
> next needs a better memory.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>