From: Hubert Kario <hka@qbs.com.pl>
To: dave@jikos.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 1/5] btrfs: add command to zero out superblock
Date: Wed, 02 May 2012 18:42:16 +0200 [thread overview]
Message-ID: <2913005.FpWZk4H159@bursa01> (raw)
In-Reply-To: <20120502142843.GD6740@twin.jikos.cz>
On Wednesday 02 of May 2012 16:28:43 David Sterba wrote:
> On Tue, May 01, 2012 at 02:40:29PM +0200, Hubert Kario wrote:
> > +static const char * const cmd_zero_dev_usage[] =3D {
> > + "btrfs device zero-superblock <device> [<device> ...]",
>=20
> FYI, this step is named 'clear superblock' in kernel code as done aft=
er the
> device is removed, and I suggest to consider to name the command like
> 'clear-superblock' or 'clear-sb'.
A similar function in mdadm is called zero superblock so I just re used=
the=20
name (according to the principle of least surprise). Users, even admins=
,=20
generally don't read kernel code...
=20
> Also, kernel clears only the "superblock magic" string, ie. the
> "_BHRfS_M" bytes. This leaves the rest of the superblock intact, for
> possible recovery when it's cleared accidentally.
That's when a device is removed from the filesystem, not when a filesys=
tem is=20
just not used any more and you want to re-purpose the devices.
> I had prototyped a similar utility (in perl, so nothing for progs
> inclusion for now) and rewrote the magic string with _BHRf$_M ie. the
> S -> $ for visual similarity with the action performed. This allows t=
o
> detect cleared superblocks and activate them back eventually.
>=20
> I'm not sure if this is useful and sensible usecase, clearing superbl=
ock
> 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 per=
formed=20
just before formatting the partition with some other fs or physical vol=
ume for=20
LVM. IMHO recoverability of "cleared" superblock is a function hardly a=
nyone=20
would use.
=20
> To your implementation: I think adding a function doing the superbloc=
k
> reset would be enough here. Something like this (in pseudocode):
>=20
> for (i =3D 0 ; i < BTRFS_SUPER_MIRROR_MAX; i++) {
> bytenr =3D 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=20
just before btrfs dev add and by mkfs. Duplicating its code would be a =
bad=20
idea.
Regards,
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-05-02 16:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-01 12:40 [PATCH v2 1/5] btrfs: add command to zero out superblock Hubert Kario
2012-05-01 12:40 ` [PATCH v2 2/5] handle null pointers in btrfs_prepare_device Hubert Kario
2012-05-01 12:40 ` [PATCH v2 3/5] Remove unused option " Hubert Kario
2012-05-02 14:28 ` [PATCH v2 1/5] btrfs: add command to zero out superblock David Sterba
2012-05-02 14:48 ` David Sterba
2012-05-02 16:42 ` Hubert Kario [this message]
2012-05-02 17:36 ` David Sterba
2012-05-03 13:11 ` Hubert Kario
2012-05-09 17:18 ` David Sterba
2012-05-09 17:23 ` Hubert Kario
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2913005.FpWZk4H159@bursa01 \
--to=hka@qbs.com.pl \
--cc=dave@jikos.cz \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.