Tux3 Report: Initial fsck has landed

[David Lang]

On Sun, 27 Jan 2013, Daniel Phillips wrote:

> Compared to Ext2/3/4, Tux3 has a big disadvantage in terms of fsck: it does
> not confine inode table blocks to fixed regions of the volume. Tux3 may store
> any metadata block anywhere, and tends to stir things around to new locations
> during normal operation. To overcome this disadvantage, we have the concept of
> uptags:
>
>    http://phunq.net/pipermail/tux3/2013-January/001973.html
>    "What are uptags?"
>
> With uptags we should be able to fall back to a full scan of a damaged volume
> and get a pretty good idea of which blocks are actually lost metadata blocks,
> and to which filesystem objects they might belong.

The thing that jumps out at me with this is the question of how you will avoid 
the 'filesystem image in a file' disaster that reiserfs had (where it's fsck 
could mix up metadata chunks from the main filesystem with metadata chunks from 
any filesystem images that it happened to stumble across when scanning the disk)

many people with dd if=/dev/sda2 of=filesystem.image, and if you are doing 
virtualization, you may be running out of one of these filesystem images. With 
virtualization, it's very likely that you will have many copies of a single 
image that are all identical.

have you thought of how to deal with this problem?

David Lang