lkml.org 
[lkml]   [1996]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Drawbacks of implementing undelete entirely in user
	      space
X-Submitted-Via: news@ratatosk.yggdrasil.com (linux.* gateway)

I've only been partially following this discussion, so if this is off-topic
just delete the message and go on... ;-)

I have a couple of file servers here made by a company called Network Appliance.
They have a feature called "snapshot" which seems to do everything about
undelete and more.

(I'm not a ext2 guru, so the following may not be quite accurate.) It appears
that, to make a snapshot, they make backups of the inode tables and block
allocation tables. The snapshot is then accessable through a directory called
".snapshot" in the root of the file system. The entries in /.snapshot are
directories named after the snapshots (automatically generated ones are called
{hourly,nightly,weekly}.n and automatically cycled); looking in those directories
yields a view of the root of the file system when the snapshot was taken. (As
an example, if snapshot nightly.0 was taken at midnight last night then the
contents of /etc at midnight could be found in /.snapshot/nightly.0/etc.)

Deleting a file (or changing it) only deletes it from the active file system,
not from the snapshots (which are read-only and inherit the file attributes of
the file (owner, permissions, ...) when the snapshot was taken). Undeleting a
file consists of copying back from the snapshot. A portion of the file system
can be reserved for the snapshots so that deleting a file frees active space.

I'm not really sure of the kernel/user separation of this idea, but I think the
only kernel support that would be needed would be to not deallocate blocks until
all files in all snapshots are no longer referencing the block. Creating and
deleting snapshots could probably be done in user space from a cron job.

(BTW, making a snapshot of my 32GB file system (all drives form a single RAID
array) takes about 15-30 seconds.)

Just my US$0.002 (or less).
--
To contact me (in order of decreasing reliability):
E-Mail: bob.allison@scitexdpi.com
Phone Mail: +1 513 259 3629 (I'm often out helping users)
FAX "Mail": +1 513 259 3291
Snail Mail: Bob Allison
SCITEX Digital Printing, Inc.
3100 Research Blvd.
Dayton, OH 45420-4099




\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.031 / U:3.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site