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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
