From: Dave Chinner <david@fromorbit.com>
To: Eryu Guan <eguan@redhat.com>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] common: get fs type again using device canonical name in _fs_type
Date: Fri, 1 Aug 2014 14:49:10 +1000 [thread overview]
Message-ID: <20140801044910.GV26465@dastard> (raw)
In-Reply-To: <20140801040240.GK7382@dhcp-13-216.nay.redhat.com>
On Fri, Aug 01, 2014 at 12:02:41PM +0800, Eryu Guan wrote:
> On Fri, Aug 01, 2014 at 10:21:59AM +1000, Dave Chinner wrote:
> > On Thu, Jul 31, 2014 at 06:52:37PM +0800, Eryu Guan wrote:
> > > When testing with lvm, a previous btrfsck run could change df output
> > > from something like
> > >
> > > /dev/mapper/rhel_hp--dl388eg8--01-testlv1 btrfs 15728640 900 13602172 1% /mnt/btrfs
> > >
> > > to
> > >
> > > /dev/dm-3 btrfs 15728640 900 13602172 1% /mnt/btrfs
> >
> > I don't follow you. Why would running btrfsck change the name of the
> > device? If the filesystem is umounted and mounted again, then the
> > device could change, but btrfsck should not be not doing the
> > unmount/mount, and so unless the TEST_DEV/SCRATCH_DEV is changing
> > the output of df should be identical...
> >
> > So before we change the _fs_type() code, can you explain exactly
> > how, when and why the device name is changing to me?
>
> Assume that we have two btrfs filesystems, kernel is 3.16.0-rc4+
>
> [root@hp-dl388eg8-01 btrfs-progs]# btrfs fi show
> Label: none uuid: 1aba7da5-ce2b-4af0-a716-db732abc60b2
> Total devices 1 FS bytes used 384.00KiB
> devid 1 size 15.00GiB used 2.04GiB path /dev/mapper/rhel_hp--dl388eg8--01-testlv1
>
> Label: none uuid: 26ff4f12-f6d9-4cbc-aae2-57febeefde37
> Total devices 2 FS bytes used 112.00KiB
> devid 1 size 15.00GiB used 2.03GiB path /dev/mapper/rhel_hp--dl388eg8--01-testlv2
> devid 2 size 15.00GiB used 2.01GiB path /dev/mapper/rhel_hp--dl388eg8--01-testlv3
>
> Btrfs v3.14.2
>
> And testlv1 was mounted at /mnt/btrfs
>
> [root@hp-dl388eg8-01 btrfs-progs]# df -TP /mnt/btrfs
> Filesystem Type 1024-blocks Used Available Capacity Mounted on
> /dev/mapper/rhel_hp--dl388eg8--01-testlv1 btrfs 15728640 512 13602560 1% /mnt/btrfs
>
> Now run btrfsck on testlv2, btrfsck will scan all btrfs devices and
> somehow change the device name.
>
> [root@hp-dl388eg8-01 btrfs-progs]# btrfsck /dev/mapper/rhel_hp--dl388eg8--01-testlv2 >/dev/null 2>&1
>
> # device name changed in df output and btrfs fi show output
> [root@hp-dl388eg8-01 btrfs-progs]# df -TP /mnt/btrfs
> Filesystem Type 1024-blocks Used Available Capacity Mounted on
> /dev/dm-3 btrfs 15728640 512 13602560 1% /mnt/btrfs
> [root@hp-dl388eg8-01 btrfs-progs]# btrfs fi show
> Label: none uuid: 1aba7da5-ce2b-4af0-a716-db732abc60b2
> Total devices 1 FS bytes used 384.00KiB
> devid 1 size 15.00GiB used 2.04GiB path /dev/dm-3
>
> Label: none uuid: 26ff4f12-f6d9-4cbc-aae2-57febeefde37
> Total devices 2 FS bytes used 112.00KiB
> devid 1 size 15.00GiB used 2.03GiB path /dev/mapper/rhel_hp--dl388eg8--01-testlv2
> devid 2 size 15.00GiB used 2.01GiB path /dev/mapper/rhel_hp--dl388eg8--01-testlv3
>
> Btrfs v3.14.2
>
> This only happens when btrfsck a btrfs with multiple devices, so this
> only affects xfstests run on btrfs with SCRATCH_DEV_POOL set to lvm
> lvs.
>
> Maybe this is a bug of btrfs-progs and we should fix it there?
Yes, that smells of a btrfs-progs bug. If your /etc/mtab a link to
/proc/mounts? If not, does the contents change when you run btrfsck,
and does the problem go away when you replace /etc/mtab with a link
to /proc/mounts?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2014-08-01 4:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-27 16:37 [PATCH] common: get fs type again using device canonical name in _fs_type Eryu Guan
2014-07-31 10:52 ` [PATCH v2] " Eryu Guan
2014-08-01 0:21 ` Dave Chinner
2014-08-01 4:02 ` Eryu Guan
2014-08-01 4:49 ` Dave Chinner [this message]
2014-08-01 5:02 ` Eryu Guan
2014-08-01 8:48 ` Dave Chinner
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=20140801044910.GV26465@dastard \
--to=david@fromorbit.com \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
--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.