Re: Tux3 Report: Initial fsck has landed

From: David Lang
Date: Mon Jan 28 2013 - 01:15:57 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/