Re: How to identify if a partition containing a btrfs volume is mounted and where

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Mike,

On 27/02/2014 05:50, Mike Fleetwood wrote:
On 25 February 2014 10:28, Mike Fleetwood <mike.fleetwood@xxxxxxxxxxxxxx> wrote:
On 25 February 2014 03:01, Anand Jain <Anand.Jain@xxxxxxxxxx> wrote:

# mkfs.btrfs /dev/sdb2 /dev/sdb3 /dev/sdb4
# mount /dev/sdb2 /mnt/1
# btrfs device delete /dev/sdb2 /mnt/1

So /dev/sdb2 is no longer part of the file system, but it's still
mounted using it.

# grep btrfs /proc/mounts
/dev/sdb2 /mnt/1 btrfs rw,seclabel,relatime,ssd,space_cache 0 0


  This bug isn't there is the current btrfs-next. I couldn't
  reproduce.

I've tested this again.  With linux 3.12.10 on Fedora 20 it is still
reproducible, but after upgrading to linux 3.13.3 /proc/mounts
automatically changes to show another device when the initial mounting
one is removed from the btrfs.

Hi Anand,

I've done some more testing and stracing and would appreciate you
confirming the following understanding is correct:

1) btrfs-tools >= 3.12 (possibly earlier) will always display correct
results from btrfs fs show because it uses ioctls to get information
from the kernel for each mounted btrfs, and reads the disks for
non-mounted ones.

 it would scan kernel first to pick fsid which are opened
 and then reads disks directly to pick rest of the fsids.

2) Old btrfs tools (tested with 0.20-rc1) only reads the disk and so
may get out of date information for mounted file systems,

 yes.

3) Using btrfs fs sync /mnt makes the cached changes to device
membership get flushed to disk, thus avoiding seeing stale data i
(2).

 nope this does not work. Calling flush not for the application
 purpose is not a good idea. it would alter the application
 performance when you run btrfs fi show that's unacceptable at
 a lot of data centers.

 further, if you delete the missing disk and if that disk reappears,
 just by user land read would make the wrong judgement on its mount
 status, thats the current bug which I am working on.

So as such I plan to use /proc/mounts to determine FS busy status and
btrfs fs show to determine btrfs device membership.

 I don't understand in full. but the toughest test case will
 be to test the theory with seed disk in place. /proc/mounts
 show the seed disk whose fsid is different from sprout fsid.

 IMO /proc/mounts should not show seed disk in theory.
 If there is a practical need, pls do let me know
 as I am planning to write a RFC on it.

As per my
previous and the above details this will be correct for linux >= 3.13
and current btrfs-tools, but for older kernel using /proc/mounts will
be wrong if the original mounting device has been removed from the
btrfs.

 btrfs-kernel has no idea about the disk disappeared. Its WIP
 at my end.

Thanks,  Anand

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux