bugfindutils - Bugs: bug #50859, fstype btrfs isn't supported

 
 

bug #50859: fstype btrfs isn't supported

Submitted by:  Tavian Barnes <tavianator>
Submitted on:  Sun 23 Apr 2017 02:44:50 PM UTC  
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  None
Privacy:  Public Assigned to:  Bernhard Voelker <berny>
Originator Name:  Open/Closed:  Open
Release:  4.6.0 Fixed Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 08 Apr 2021 11:30:30 AM UTC, comment #4: 

find exhibits the same behavior for me as @tavianator.

I've tracked it to fstype.c:250
if (entry->me_dev == statp->st_dev)

It appears the predicate is never true for me in my test setup and `best` is never assigned.

~/$ stat -c "%d %n" /mnt/btrfs-test /mnt/btrfs-test/asdfsdaf/subvol/
1048804 /mnt/btrfs-test
1048805 /mnt/btrfs-test/asdfsdaf/subvol/

~/$ df --output=fstype,target /mnt/btrfs-test /mnt/btrfs-test/asdfsdaf/subvol/
Type  Mounted on
btrfs /mnt/btrfs-test
-     /mnt/btrfs-test/asdfsdaf/subvol

~/$ find /mnt/btrfs-test -printf '%F %p\n'
unknown /mnt/btrfs-test
unknown /mnt/btrfs-test/thing
unknown /mnt/btrfs-test/asdfsdaf
unknown /mnt/btrfs-test/asdfsdaf/asdf
unknown /mnt/btrfs-test/asdfsdaf/subvol

Breakpoint 7, file_system_type_uncached (fstype_known=0x5555555a32b0 <fstype_known>, path=0x7fffffffde80 <incomplete sequence \344>, statp=0x7fffffffde80) at fstype.c:245
245     in fstype.c
(gdb) p *entry
$14 = {me_devname = 0x5555555af940 "/dev/loop98p1", me_mountdir = 0x5555555af960 "/mnt/btrfs-test", me_mntroot = 0x5555555af980 "/", me_type = 0x5555555af9a0 "btrfs",
  me_dev = 1048793, me_dummy = 0, me_remote = 0, me_type_malloced = 1, me_next = 0x0}
(gdb) p *statp
$15 = {st_dev = 1048804, st_ino = 260, st_nlink = 1, st_mode = 33204, st_uid = 1000, st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 0, st_blksize = 4096, st_blocks = 0,
  st_atim = {tv_sec = 1617846997, tv_nsec = 768596091}, st_mtim = {tv_sec = 1617846997, tv_nsec = 768596091}, st_ctim = {tv_sec = 1617846997, tv_nsec = 768596091},
  __glibc_reserved = {0, 0, 0}}
(gdb) c
Continuing.
unknown

Breakpoint 7, file_system_type_uncached (fstype_known=0x5555555a32b0 <fstype_known>, path=0x7fffffffde80 <incomplete sequence \345>, statp=0x7fffffffde80) at fstype.c:245
245     in fstype.c
(gdb) p *entry
$16 = {me_devname = 0x5555555af940 "/dev/loop98p1", me_mountdir = 0x5555555af960 "/mnt/btrfs-test", me_mntroot = 0x5555555af980 "/", me_type = 0x5555555af9a0 "btrfs",
  me_dev = 1048793, me_dummy = 0, me_remote = 0, me_type_malloced = 1, me_next = 0x0}
(gdb) p *statp
$17 = {st_dev = 1048805, st_ino = 256, st_nlink = 1, st_mode = 16893, st_uid = 1000, st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 0, st_blksize = 4096, st_blocks = 0,
  st_atim = {tv_sec = 1617847022, tv_nsec = 444810726}, st_mtim = {tv_sec = 1617847018, tv_nsec = 344774790}, st_ctim = {tv_sec = 1617847018, tv_nsec = 344774790},
  __glibc_reserved = {0, 0, 0}}

As @berny points out this is likely because of the discussion in https://savannah.gnu.org/bugs/?50326 ; But I'd like to understand why df can make this distinction where find can't.

Brett Milford <bcm>
Mon 20 Jul 2020 04:23:34 PM UTC, comment #3: 

Hello,

Today tools like "df" are able to display the file system type, but "find" isn't.

At the same time, "find -fstype btrfs" doesn't seem to work for me even on btrfs root.

Do you think it would be possible to cherry-pick how "df" does this and do the same in "find"?

The workaround that Bernhard mentioned back in 2017 sounds like it could work as well.

I would be happy to test and provide more information if necessary!

$ df --output=fstype,target /mnt/btrfs-root / /etc /.snapshots
Type  Mounted on
btrfs /mnt/btrfs-root
btrfs /
btrfs /
btrfs /.snapshots

$ findmnt -T /mnt/btrfs-root/
TARGET          SOURCE           FSTYPE OPTIONS
/mnt/btrfs-root /dev/mapper/luks btrfs  rw,noatime,nodiratime,compress=zstd:3,ssd,space_cache,subvolid=5,subvol=/

$ findmnt -T /
TARGET SOURCE                  FSTYPE OPTIONS
/      /dev/mapper/luks[/root] btrfs  rw,noatime,nodiratime,compress=zstd:3,ssd,space_cache,subvolid=696,subvol=/root

$ findmnt -T /etc
TARGET SOURCE                  FSTYPE OPTIONS
/      /dev/mapper/luks[/root] btrfs  rw,noatime,nodiratime,compress=zstd:3,ssd,space_cache,subvolid=696,subvol=/root

$ findmnt -T /.snapshots/
TARGET      SOURCE                       FSTYPE OPTIONS
/.snapshots /dev/mapper/luks[/snapshots] btrfs  rw,noatime,nodiratime,compress=zstd:3,ssd,space_cache,subvolid=261,subvol=/snapshots

$ find /mnt/btrfs-root / /etc /.snapshots -maxdepth 0 -printf '%F\n'
unknown
unknown
unknown
unknown

--
Maxim Baz

Maxim Baz <maximbaz>
Sun 23 Apr 2017 09:48:39 PM UTC, comment #2: 

Ah okay, you're actually parsing the device number out of /proc/self/mountinfo?  When I implemented -fstype for bfs, I didn't bother getting it from there, as it's not returned by getmntent().  I just stat() the mount point itself, which obviously works.

Tavian Barnes <tavianator>
Sun 23 Apr 2017 09:34:23 PM UTC, 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?

Bernhard Voelker <berny>
Project AdministratorIn charge of this item.
Sun 23 Apr 2017 02:44:50 PM UTC, original submission:  

On a btrfs file system, find -fstype btrfs doesn't find any files, and find -printf '%p %F\n' prints

. unknown
./.git unknown
./.git/refs unknown
...

Tavian Barnes <tavianator>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bcm (Posted a comment)
  • -email is unavailable- added by maximbaz (Posted a comment)
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by tavianator (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-04-23 berny Assigned toNone => berny

    Back to the top


    Powered by Savane 3.6