Re: [PATCH e2fsprogs] Add ZFS detection to libblkid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux