LWN.net Logo

Tux3: the other next-generation filesystem

Tux3: the other next-generation filesystem

Posted Dec 2, 2008 20:33 UTC (Tue) by aigarius (subscriber, #7329)
Parent article: Tux3: the other next-generation filesystem

One other common utility that Linux filesystem developers often forget is undelete - a tool that would analyse the filesystem and report what files and what versions of files it can recover. This should be simple enough to implement in Tux3.


(Log in to post comments)

Tux3: the other next-generation filesystem

Posted Dec 2, 2008 23:01 UTC (Tue) by jmorris42 (subscriber, #2203) [Link]

> undelete - a tool that would analyse the filesystem and
> report what files and what versions of files it can recover.

Sounds like you are stuck in DOS mode. For an undelete in a real OS, beyond the Windows 'trashcan' desktop GUIs implement, it should be a "Do or Do Not, there is no try." deal. Either have real file versioning, snapshots, etc. or don't bother. Snuffling around on the platters for raw blocks and just blanking out the first letter of file names are bad ideas best left in the dustbin of history.

Tux3: the other next-generation filesystem

Posted Dec 2, 2008 23:26 UTC (Tue) by Ze (guest, #54182) [Link]

Sounds like you are stuck in DOS mode. For an undelete in a real OS, beyond the Windows 'trashcan' desktop GUIs implement, it should be a "Do or Do Not, there is no try." deal. Either have real file versioning, snapshots, etc. or don't bother. Snuffling around on the platters for raw blocks and just blanking out the first letter of file names are bad ideas best left in the dustbin of history.

undelete through versioning is bloody useful. However it's no substitute for a tool that tries to recover data when there has been a failure. When people are writing filesystems they often don't think about how they could make it easier for themselves or others to write a tool to recover corrupted data in the event of various failures (both software and hardware). Personally I don't see the loss of logical volumes as a big deal. I've never understood the point of them when you could just have a fast index in the first place.

Tux3: the other next-generation filesystem

Posted Dec 3, 2008 9:48 UTC (Wed) by niner (subscriber, #26151) [Link]

Hardware failures and accidental deletion is what we have backups for.

Tux3: the other next-generation filesystem

Posted Dec 4, 2008 3:54 UTC (Thu) by Ze (guest, #54182) [Link]

>Hardware failures and accidental deletion is what we have backups for I would argue that accidental deletion is one of the things that versioning should handle. Unfortunately backups offer only limited granularity along with people failing to use or test them. When you combine all that you can see why people a clear need for data recovery tools. People clearly feel a need for recovery tools since there are quite a few tools on the market both free and commercial. It makes sense to consider that use case when designing a file system. It can only lead to better documented and designed file system.

Tux3: the other next-generation filesystem

Posted Dec 4, 2008 17:40 UTC (Thu) by lysse (guest, #3190) [Link]

Yes, and you'll still have backups for it in the future. But wouldn't it be nice to have a way out of your last backup having gone up in flames at a really inconvenient time? Is there some reason why it would be desirable to limit the number of ways of thwarting Murphy we permit ourselves? Because honestly, I can't think of one...

Tux3: the other next-generation filesystem

Posted Dec 4, 2008 12:15 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

As a side effect, consider that you could end up making real deletion of information (say, credit card numbers) harder.
Amdist all the great work (which is well above my skill level, kudos to all) there are ramifications.

Tux3: the other next-generation filesystem

Posted Dec 2, 2008 23:04 UTC (Tue) by daniel (subscriber, #3181) [Link]

One other common utility that Linux filesystem developers often forget is undelete - a tool that would analyse the filesystem and report what files and what versions of files it can recover. This should be simple enough to implement in Tux3.

It's on the to.do list. The standard argument against undelete is that it can be implemented at a higher level, as a move to a Trash folder in place of a delete. In practice, there is often not a gui around, and it doesn't help when you are running a shell under the gui. So if it turns out to be easy to do as part of the versioning, Tux3 will have it.

Regards, Daniel

Tux3: the other next-generation filesystem

Posted Dec 3, 2008 2:55 UTC (Wed) by rsidd (subscriber, #2582) [Link]

Doesn't Tux3 support snapshots (or won't it, in the future)? With snapshots you don't need undelete.

Tux3: the other next-generation filesystem

Posted Dec 3, 2008 7:23 UTC (Wed) by daniel (subscriber, #3181) [Link]

Snapshots do not take care of all undelete cases - you might not have taken a snapshot before deleting something important. But I am thinking in terms of using the snapshot mechanism to support undelete, essentially creating an "anonymous snapshot" just for the directory where the delete happened. This could be done without wasting a lot of space by using Tux3's versioned attribute model, which would avoid having to use a full disk block just to remember a single undeleted name.

Tux3: the other next-generation filesystem

Posted Dec 3, 2008 8:05 UTC (Wed) by rsidd (subscriber, #2582) [Link]

I've seen your email exchange with Matt Dillon on tux3 and hammer on the dragonfly lists some time back. Hammer can take snapshots at very fine-grained interval -- say every few minutes -- via a cron job and it is not very expensive (supposedly -- I haven't used it myself, yet). That would be incredibly useful. Undelete doesn't take care of all recovery requirements either -- you may have deleted text in a document that you later want back, for example. With hammer, just look at the snapshot from 2 minutes before you deleted it.

I suppose if you have a filesystem where many bulky files are being altered frequently, this is not a great idea, but you can tune the frequency of the snapshot and pruning (or disable snapshotting entirely, if need be...)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds