Messages in this thread | | | Date | Tue, 25 Jun 1996 07:22:09 -0400 | From | Bob Allison <> | Subject | Re: 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
| |