On Wed, Feb 13, 2013 at 01:16:55PM +0100, Karel Zak wrote: > On Wed, Feb 13, 2013 at 11:41:08AM +0100, Lukáš Czerner wrote: > > 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 ? > > This is bug in libmount. Fixed in upstream tree. The libmount in some > cases ignores the ambivalent probing result from libblkid and tries > stuff from /etc/filesystems (where is for example ext4). > > > So I think that liblkid _and_ btrfs tools has to be fixed not to treat > > backup superblocks as primary! > > The problem with additional btrfs superblocks has been already reported > to btrfs guys: > > http://www.mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg20957.html > > and I don't see a reply "yep, this is btrfs-progs bug" :-) Oh, it's most definitely a btrfs-progs bug. Using stale metadata data on the block device in preference to current, primary metadata identifying the device to belong to a different filesystem is, well, rather unfriendly. In the above case, mkfs.ext4 overwrites the btrfs magic block field so that it is not zero (as it is after wipefs runs), and hence the btrfs tools see it as a broken superblock and continue to the next location for recovery rather than see the device as containing a valid but foreign filesystem. None of the filesystem tools from ext4, btrfs and XFS handle this sort of thing consistently, even though it is their responsibility to do so. XFS is probably the best of them, in that *some* of the tools will refuse to run unless you provide a force flag when the device appears to contain primary identifiers for a different filesystem. e.g. mkfs.xfs won't overwrite existing filesystems without a force flag, but mkfs.ext4 and mkfs.btrfs will: $ sudo mkfs.xfs /dev/vdb mkfs.xfs: /dev/vdb appears to contain an existing filesystem (btrfs). mkfs.xfs: Use the -f option to force overwrite. $ sudo mkfs.xfs -f /dev/vdb meta-data=/dev/vdb isize=256 agcount=4, agsize=720896 blks = sectsz=512 attr=2, projid32bit=0 = crc=0 data = bsize=4096 blocks=2883584, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 $ sudo mkfs.xfs /dev/vdb mkfs.xfs: /dev/vdb appears to contain an existing filesystem (xfs). mkfs.xfs: Use the -f option to force overwrite. $ sudo mkfs.btrfs /dev/vdb WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using fs created label (null) on /dev/vdb nodesize 4096 leafsize 4096 sectorsize 4096 size 11.00GB Btrfs Btrfs v0.19 $ sudo mkfs.ext4 /dev/vdb mke2fs 1.42.5 (29-Jul-2012) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 720896 inodes, 2883584 blocks 144179 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2952790016 88 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done $ sudo mkfs.xfs /dev/vdb mkfs.xfs: /dev/vdb appears to contain an existing filesystem (ext4). mkfs.xfs: Use the -f option to force overwrite. $ IOWs, it is the responsibility of the filesystem tools to correctly identify the filesystem being operated on, and not to modify/trash/recover anything unless specifically directed by the user. When a filesystem tool gets it wrong, then that specific tool needs to be fixed. i.e. it is the responsibility of filesystem tools to behave sanely, not for the rest of the world to have to work around the dangerous behaviour of a specific filesystems' toolset. And that makes it a btrfs-progs bug that needs to be fixed. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
