From: Lubos Kolouch <lubos.kolouch@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: mkfs.btrfs - error checking /dev/sda5 mount status
Date: Thu, 10 Feb 2011 18:35:10 +0000 (UTC) [thread overview]
Message-ID: <ij1b4u$tsh$1@dough.gmane.org> (raw)
In-Reply-To: 4D542D79.9070402@libero.it
Goffredo Baroncelli, Thu, 10 Feb 2011 19:24:57 +0100:
> On 02/09/2011 09:12 PM, Lubos Kolouch wrote:
>> Goffredo Baroncelli, Wed, 09 Feb 2011 19:25:34 +0100:
>>
>>> On 02/08/2011 10:26 PM, Lubos Kolouch wrote:
>>>> Goffredo Baroncelli, Tue, 08 Feb 2011 21:00:25 +0100:
>>>>
>>>>> On 02/08/2011 07:57 AM, Lubos Kolouch wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm hitting this issue - sda5 is a normal device, nothing to do
>>>>>> with loop, encryption etc.
>>>>>>
>>>>>> # mkfs.btrfs /dev/sda5
>>>>>>
>>>>>> WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! -
>>>>>> see http://btrfs.wiki.kernel.org before using
>>>>>>
>>>>>> error checking /dev/sda5 mount status
>>>>>>
>>>>>> Is there something I can do to resolve this?
>>>>>
>>>>> Some months ago I posted a patch [*] which allows to create a
>>>>> filesystem even if an integrity tests fail. Anyway it would be
>>>>> interesting understand why mkfs.btrfs fails. It is possible to have
>>>>> a strace of the command ?
>>>>>
>>>>>
>>>> here ... http://paste.pocoo.org/show/334638/ but it is not in chroot,
>>>> it is in "normal" system
>>>>
>>>> Lubos
>>>>
>>>>
>>> Hi Lubos,
>>>
>>> Could you post also the output of "cat /proc/mounts" command and the
>>> output of "btrfs filesystem show" command. I cannot understand what
>>> should be the problem.
>>
>> Hi Goffredo,
>>
>> Sure,
>> # cat /proc/mounts
>>
>> rootfs / rootfs rw 0 0
>> /dev/root / btrfs rw,noatime,compress,ssd 0 0 proc /proc proc
>> rw,nosuid,nodev,noexec,relatime 0 0 rc-svcdir /lib/rc/init.d tmpfs
>> rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys
>> sysfs rw,nosuid,nodev,noexec,relatime 0 0 securityfs
>> /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
>> debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0
>> udev /dev devtmpfs
>> rw,nosuid,relatime,size=10240k,nr_inodes=217934,mode=755 0 0 fusectl
>> /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /dev/pts devpts
>> rw,relatime,mode=600,ptmxmode=000 0 0 none /dev/shm tmpfs rw,relatime 0
>> 0
>> /dev/sda1 /boot ext2 rw,relatime,errors=continue 0 0 none
>> /var/tmp/portage tmpfs rw,relatime 0 0 binfmt_misc
>> /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0
>> 0
>> /dev/mapper/_dev_sda6 /home btrfs rw,noatime,compress,ssd 0 0
>>
>> # btrfs filesystem show
>>
>> Label: none uuid: fd070c17-e98b-4b50-9fa8-3453482aafa2
>> Total devices 1 FS bytes used 5.51GB
>> devid 1 size 18.64GB used 10.79GB path /dev/sda2
>>
>> Label: none uuid: bf9a1b00-f8bd-44d3-b140-10eea088a60e
>> Total devices 1 FS bytes used 6.73GB
>> devid 1 size 19.54GB used 19.54GB path /dev/sda5
>>
>> Label: none uuid: ae0ba016-1945-4e7a-9fb4-e9311d199727
>> Total devices 1 FS bytes used 57.50GB devid 1 size 78.91GB used
>> 78.91GB path /dev/dm-0
>>
>> # mkfs.btrfs /dev/sda5
>>
>> WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! - see
>> http://btrfs.wiki.kernel.org before using
>>
>> error checking /dev/sda5 mount status
>>
>> Also, I can mount it no problem - strange, isn't it
>
>
> Ok, I think to have track down the problem. To me it seems a bug in
> mkfs.btrfs.
>
> The first thing that should be highlighted is that you are trying to
> format an already btrfs formatted device. In this there is not anything
> wrong.
>
> However, before formatting a device mkfs.btrfs performs some sanity
> check. It checks if the device is already mounted, scanning
> /proc/mounts.
>
> In a normal case (the device which will be formatted doesn't contain a
> btrfs filesystem), mkfs.btrfs is smart enough to don't check device
> which are in /proc/mounts bat doesn't exist (like /dev/root).
>
> Instead when the device which will be formatted already contains a btrfs
> filesystem, mkfs.btrfs performs a different checks. In fact it considers
> also the case of a multi-device based btrfs filesystem. However in this
> case it doesn't skip a not existent device but it raises an error. I
> think that this is a bug.
>
> As workaround I suggest the following: make a link between the real root
> device and /dev/root.
>
> It should be sufficient to format the device.
>
Hello - you are right...
# ln -s /dev/sda2 /dev/root
# mkfs.btrfs /dev/sda5
WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
fs created label (null) on /dev/sda5
nodesize 4096 leafsize 4096 sectorsize 4096 size 19.54GB
Btrfs v0.19-35-g1b444cd-dirty
Lubos
prev parent reply other threads:[~2011-02-10 18:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 6:57 mkfs.btrfs - error checking /dev/sda5 mount status Lubos Kolouch
2011-02-08 20:00 ` Goffredo Baroncelli
2011-02-08 21:26 ` Lubos Kolouch
2011-02-09 18:25 ` Goffredo Baroncelli
2011-02-09 20:12 ` Lubos Kolouch
2011-02-10 3:09 ` Chris Samuel
2011-02-10 6:54 ` Lubos Kolouch
2011-02-10 7:49 ` Helmut Hullen
2011-02-10 7:47 ` Helmut Hullen
2011-02-10 18:24 ` Goffredo Baroncelli
2011-02-10 18:35 ` Lubos Kolouch [this message]
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='ij1b4u$tsh$1@dough.gmane.org' \
--to=lubos.kolouch@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).