On Wed, 13 Feb 2013, Karel Zak wrote:
> Date: Wed, 13 Feb 2013 09:01:54 +0100
> From: Karel Zak <kzak@xxxxxxxxxx>
> To: Dave Chinner <david@xxxxxxxxxxxxx>
> Cc: Lukas Czerner <lczerner@xxxxxxxxxx>, xfs@xxxxxxxxxxx, sandeen@xxxxxxxxxx
> Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
> On Wed, Feb 13, 2013 at 07:27:53AM +1100, Dave Chinner wrote:
> > Isn't 128k of zeroing enough to kill existing filesystem signatures?
> Really no.
> > If not how much is, and why can't we just change WHACK_SIZE to
> > reflect the size that will kill those signatures that are further
> > offset into the device?
> btrfs: first superblock at 64KB, second at 64MB, third at 256GB.
We've been discussing this with Dave and others and it seems really
odd that blkid would detect file system signature from backup
superblock. It seems that it's doing this only for btrfs, ignoring
backup superblocks for any other file system.
I know that btrfs user space is broken in a way that it would
unconditionally use backup superblock, but it has to be fixed!
Also I think that the bug in btrfs is not a reason for blkid to
treat btrfs backup superblocks as primary (which is what you're
essentially doing). We should fix that first and then we can discuss
whether fs utilities should be using blkid to wipe all the
signatures from the device I think.
It seem to me that this is real problem and also nasty regression
mkfs.xfs -f /dev/sda
and the device is unmountable, even though it contains valid xfs
mkfs.ext4 -F /dev/sda
works well, however I am not sure why that is. Is that some kind of
mount(8) magic ?
So I think that liblkid _and_ btrfs tools has to be fixed not to treat
backup superblocks as primary!
> zfs has at least 4 blocks at the begin and end of the device.
> GPT has the backup table at the end of the device.
> RAIDs have signatures also at the end of the device, etc.