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

Reply via email to