All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>,
	xfs@oss.sgi.com, sandeen@redhat.com,
	Zach Brown <zabrown@redhat.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
Date: Wed, 13 Feb 2013 13:16:55 +0100	[thread overview]
Message-ID: <20130213121655.GA7799@x2.net.home> (raw)
In-Reply-To: <alpine.LFD.2.00.1302131127070.2315@(none)>

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@vger.kernel.org/msg20957.html

 and I don't see a reply "yep, this is btrfs-progs bug" :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

WARNING: multiple messages have this Message-ID (diff)
From: Karel Zak <kzak@redhat.com>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: Zach Brown <zabrown@redhat.com>,
	sandeen@redhat.com, linux-btrfs@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs_mkfs: wipe old signatures from the device
Date: Wed, 13 Feb 2013 13:16:55 +0100	[thread overview]
Message-ID: <20130213121655.GA7799@x2.net.home> (raw)
In-Reply-To: <alpine.LFD.2.00.1302131127070.2315@(none)>

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@vger.kernel.org/msg20957.html

 and I don't see a reply "yep, this is btrfs-progs bug" :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-02-13 12:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 11:06 [PATCH] xfs_mkfs: wipe old signatures from the device Lukas Czerner
2013-02-12 11:31 ` Karel Zak
2013-02-12 11:58   ` Lukáš Czerner
2013-02-12 20:27 ` Dave Chinner
2013-02-13  8:01   ` Karel Zak
2013-02-13 10:41     ` Lukáš Czerner
2013-02-13 12:16       ` Karel Zak [this message]
2013-02-13 12:16         ` Karel Zak
2013-02-13 22:17         ` Dave Chinner
2013-02-13 22:17           ` Dave Chinner
2013-02-14  7:29           ` Chris Murphy
2013-02-14  7:29             ` Chris Murphy
2013-02-14  8:36             ` Lukáš Czerner
2013-02-14 11:04               ` Dave Chinner
2013-02-14 11:04                 ` Dave Chinner
2013-02-14 12:28                 ` Lukáš Czerner
2013-02-14 14:48                 ` Martin Steigerwald
2013-02-14 14:48                   ` Martin Steigerwald
2013-02-14 18:35                   ` Eric Sandeen
2013-02-14 18:35                     ` Eric Sandeen
2013-02-14 14:54                 ` Hugo Mills
2013-02-14 14:54                   ` Hugo Mills
2013-02-14 17:25               ` Eric Sandeen
2013-02-14 17:25                 ` Eric Sandeen
2013-02-14 19:08                 ` Chris Murphy
2013-02-14 11:45           ` Dave Howorth
2013-02-14 19:17             ` Eric Sandeen

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=20130213121655.GA7799@x2.net.home \
    --to=kzak@redhat.com \
    --cc=david@fromorbit.com \
    --cc=lczerner@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=xfs@oss.sgi.com \
    --cc=zabrown@redhat.com \
    /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.