On Ter, 2009-04-07 at 00:40 -0700, Andreas Dilger wrote: > > 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. Yes, that should be relatively safe :) Where should I be sending patches for this? e2fsprogs, util-linux-ng, libvolume_id in udev, ... all of them? > > 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. Not if the pool is exported :) > 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). What about '--force-overwrite' or something similar? It wasn't scripts that I was so concerned about. I think this filesystem detection would be more useful when running mkfs in a shell, where it is more likely for the user to make mistakes (e.g. mistype /dev/sdd1 as /dev/sde1 or /dev/sda1 as /dev/sda2). Thanks, Ricardo -- 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
