On Mon, 28 Jan 2013, Theodore Ts'o wrote:
On Sun, Jan 27, 2013 at 10:13:37PM -0800, Daniel Phillips wrote:
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)
Only superficially. Deep thoughts are in order. First, there needs to be a
hole in the filesystem structure, before we would even consider trying to
plug something in there. Once we know there is a hole, we want to
narrow down the list of candidates to fill it. If a candidate already lies
within a perfectly viable file, obviously we would not want to interpret
that as lost metadata. Unless the filesystem is really mess up...
That is about as far as I have got with the analysis. Clearly, much more
is required. Suggestions welcome.
The obvious answer is what resierfs4 ultimately ended up using. Drop
a file system UUID in the superblock; mix the UUID into a checksum
which protects each of the your metadata blocks. We're mixing in the
inode number as well as the fs uuid in in ext4's new metadata checksum
feature to protect against an inode table block getting written to the
wrong location on disk. It will also mean that e2fsck won't mistake
an inode table from an earlier mkfs with the current file system.
This will allow us to avoid needing to zero the inode table for newly
initialized file systems.
The situation I'm thinking of is when dealing with VMs, you make a filesystem
image once and clone it multiple times. Won't that end up with the same UUID in
the superblock?
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
