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 because: mkfs.btrfs /dev/sda mkfs.xfs -f /dev/sda and the device is unmountable, even though it contains valid xfs file system. However mkfs.btrfs /dev/sda 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! Thanks! -Lukas > > 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. > > > Karel > > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
