On Apr 06, 2009 20:22 +0100, Ricardo Correia wrote: > On Sáb, 2009-04-04 at 15:25 -0600, Andreas Dilger wrote: > > I _suppose_ there is no hard requirement that the ub_magic is present in > > the first überblock slot at 128kB, but that does make it harder to find. > > In theory we would need to add 256 magic value checks, which seems > > unreasonable. Ricardo, do you know why the zfs.img.bz2 has bad überblocks > > for the first 4 slots? > > Your supposition is correct - there's no requirement that the first > uberblock that gets written to the uberblock array has to be in the > first slot. > > The reason that this image has bad uberblocks in the first 4 slots is > that, in the current ZFS implementation, when you create a ZFS pool, the > first uberblock that gets written to disk has txg number 4, and the slot > that gets chosen for each uberblock is "txg_nr % nr_of_uberblock_slots". > > So in fact, it's not that the first 4 uberblocks are bad, it's just that > the first 4 slots don't have any uberblocks in them yet. > > However, even though currently it's txg nr 4 that gets written first, > this is an implementation-specific detail that we cannot (or should not) > rely upon. So my proposal to check the 0th, 4th, and 8th überblock in both the first and second VDEV label should be pretty safe. > BTW, I also agree that it would be useful for ext3's mkfs to zero-out > the first and last 512 KB of the partition, to get rid of the ZFS labels > and magic values, although if it detects these magic values, it would be > quite useful for mkfs to refuse to format the partition, forcing the > user to specify some "--force" flag (like "zpool create" does), or at > least ask the user for confirmation (if mkfs is being used in > interactive mode), to avoid accidental data destruction. > > If this is not done, then maybe leaving the ZFS labels intact could be > better, so that the user has a chance to recover (some/most) of it's > data, in case he made a mistake. Well, if ZFS is currently using this filesystem, then the kernel will have the block device open O_EXCL, which will prevent the mkfs from happening. Whether it will be a feature to "--force" mkfs to overwrite an ext3 superblock or ZFS superblock is questionable. The problem with needing "--force" is that people tend to hard-code this into their scripts (so that their script always works) and then due to only having a single "--force" flag it also forces other, possibly more destructive, behaviour (e.g. --force is needed to mke2fs on a file so that it can be mounted via loopback, but will also force mke2fs on a filesystem that actually IS in use, etc). Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
