[Bug 1197796] Re: g_udev_client_query_by_device_number fails on btrfs disks

[Bug Watch Updater]

Launchpad has imported 3 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=66702.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2013-07-08T14:48:43+00:00 Jussi Pakkanen wrote:

Created attachment 82191
Source code to demonstrate the issue

Sorry if this bug is filed in the wrong place. Information on GUdev is
sparse and as far as I can tell, systemd is the upstream.

Anyway, the g_udev_client_query_by_device_number function fails on
directories that are in subvolumes. An example is a btrfs file system
with two subvolumes, @ (mounted as root) and @home (mounted as /home).
This also happens when using encrypted home directories.

Having a subvolume might not be the real reason it fails, but that is
what seems to be triggering the issue.

To replicate, download the attached source code. Compile it with "gcc
-Wall -o idnum idnum.c `pkg-config --cflags --libs glib-2.0 gio-2.0
gudev-1.0`".

When run on a plain ext4 volume, the output is this:

./idnum
Device id is 2065.

Whereas on btrfs the output is this:

./idnum
Device id is 25.
Could not get device from num.

Originally filed here:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1197796

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1197796/comments/3

------------------------------------------------------------------------
On 2013-07-08T20:48:00+00:00 Kay Sievers wrote:

Btrfs volumes are like NFS or tmpfs, a superblock without any associated
device. The behavior is expected and intentional.

Btrfs volumes might be constructed of many volumes, there cannot be the
concept of *that* device, like the "dumb" filesystems use.

There is no way for the udev API to find out which device is behind
a btrfs volume. Btrfs specific command need to be used to determine that,
no generic interface exists for that task.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1197796/comments/4

------------------------------------------------------------------------
On 2013-07-09T07:28:01+00:00 Jussi Pakkanen wrote:

Would it be possible for you to add a comment to the reference
documentation about this so other people don't have to spend time with
this issue? The page on GUdevClient does not mention subvolumes.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1197796/comments/6


** Changed in: systemd
       Status: Unknown => Invalid

** Changed in: systemd
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1197796

Title:
  g_udev_client_query_by_device_number fails on btrfs disks

Status in systemd:
  Invalid
Status in “systemd” package in Ubuntu:
  New

Bug description:
  g_udev_client_query_by_device_number works on files that are on
  regular filesystems but fails on btrfs volumes.

  To replicate, download the attached source file.

  Compile it: gcc -Wall -o idnum idnum.c `pkg-config --cflags --libs
  glib-2.0 gio-2.0 gudev-1.0`

  This happens on ext4:

  ./idnum
  Device id is 2065.

  This happens on btrfs:

  ./idnum
  Device id is 25.
  Could not get device from num.

  The file layout is the default as provided by the ubuntu installer.
  That is, the volume has two subvolumes called @ and @home.

  Filed against systemd package, because that's where ubuntu-bug
  forwarded me.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: libgudev-1.0-0 1:198-0ubuntu11.1
  ProcVersionSignature: Ubuntu 3.8.0-26.38-generic 3.8.13.2
  Uname: Linux 3.8.0-26-generic x86_64
  ApportVersion: 2.9.2-0ubuntu8.2
  Architecture: amd64
  Date: Thu Jul  4 15:34:20 2013
  InstallationDate: Installed on 2013-05-20 (45 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  MarkForUpload: True
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1197796/+subscriptions