[Top][All Lists]

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

[bug #50859] fstype btrfs isn't supported

From: Bernhard Voelker
Subject: [bug #50859] fstype btrfs isn't supported
Date: Sun, 23 Apr 2017 17:34:23 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0

Update of bug #50859 (project findutils):

             Assigned to:                    None => berny                  


Follow-up Comment #1:

find(1) supports BTRFS like any other file system type: there
is nothing special implemented in the code.  Instead, it looks
at the entries in "/proc/self/mountinfo" to find the device id.

Thus, "find -fstype btrfs" works ... as long as you search in
the root of an BTRFS file system: the underlying stat() system
call returns a different device number for BTRFS snaphots and
BTRFS subvolumes, and these can not be found in the above
mentioned mountinfo file:

  $ stat -c "%d %n" /mnt /mnt/_subvol /mnt/.snapshot
  38 /mnt
  40 /mnt/_subvol
  41 /mnt/.snapshot

See also https://savannah.gnu.org/bugs/?50326
Also other tools like "df -T" are not able to display the
file system type.

  $ df --output=fstype,target /mnt /mnt/_subvol /mnt/.snapshot
  Type  Mounted on
  btrfs /mnt
  -     /mnt/_subvol
  -     /mnt/.snapshot

Now, we could only add a workaround for this BTRFS - let's
call it - "anomaly" to find(1): if it doesn't find a file system
type for a given path, and the next one higher in the hierarchy
is a BTRFS, then it could assume that the current entry is on a
BTRFS snapshot or BTRFS subvolume.
I have such a hack in my local git tree, but didn't publish it
yet (as I usually do not use BTRFS at all, thus lacking tests).
What do others think about such a (hacky?) workaround?


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]