On Wednesday 02 of May 2012 19:36:29 David Sterba wrote: > On Wed, May 02, 2012 at 06:42:16PM +0200, Hubert Kario wrote: > > > I'm not sure if this is useful and sensible usecase, clearing superblock > > > is a one-time action anyway, so it's more for the sake of tool > > > flexibility. > > > > Clearing superblock is not a light decision and should generally be > > performed just before formatting the partition with some other fs or > > physical volume for LVM. IMHO recoverability of "cleared" superblock is a > > function hardly anyone would use. > > googled, a few users asking about recovering from md zero-superblock, and > the solution was to recreate the array, md is said to be smart and > recognize traces of previous array and will not destroy it if the > parameters are same. Point for md, btrfs does not do this.
nice, didn't know about this. Such functionality would be nice to have. But then I don't think that a "recreate the array if the parameters are the same" is actually a good idea, lots of space for error. A pair of functions: btrfs dev zero-superblock btrfs dev restore-superblock would be a better solution IMO > > > To your implementation: I think adding a function doing the superblock > > > reset would be enough here. Something like this (in pseudocode): > > > > > > for (i = 0 ; i < BTRFS_SUPER_MIRROR_MAX; i++) { > > > > > > bytenr = btrfs_sb_offset(i); > > > "break if bytenr > device size" > > > memset(superblock buffer, CLEARPATTERN, sizeof(...)) > > > > > > } > > > write_all_supers(root); > > > > That's exactly what btrfs_prepare_device does. And it's a function run by > > btfs just before btrfs dev add and by mkfs. Duplicating its code would be > > a bad idea. > > Not 'exactly' IMO: > > * calls TRIM/discard on the device > * zeroes first 2 megabytes > * zeroes all reachable superblocks > * zeroes last 2 megabytes > > Too many undocumented and unobvious side-efects. True. But close enough ;) > Code duplication can be avoided by factoring the 'zero superblock' into > a function and calling it from btrfs_prepare_device(). Then there's also the "actually zero" vs "reversibly destroy" difference but it's trivial to fix using a single option. Regards -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html