add loop device backing file in udev database

add loop device backing file in udev database

[quidame]

Hi,

Since kernel 2.6.37, some infos are available in /sys for associated 
loop devices, especially the backing file. Is it poosible to introduce 
the BACKING_FILE variable for associated loop devices ?

This sample

ACTION="add|change", \
         KERNEL="loop?*", \
         SUBSYSTEM="block", \
         TEST="%S/block/%k/loop/backing_file", \
         PROGRAM="/bin/cat %S/block/%k/loop/backing_file", \
         ENV{BACKING_FILE}="%c"

works fine.

I have already send a bug report to the Debian maintainer 
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bugg1546) who has 
recommended me to directly propose this change to the upstream 
maintainer.

Thanks
quidame

Re: add loop device backing file in udev database

[Kay Sievers]

On Thu, Jun 28, 2012 at 12:39 PM,  <quidame@poivron.org> wrote:
> Since kernel 2.6.37, some infos are available in /sys for associated loop
> devices, especially the backing file. Is it poosible to introduce the
> BACKING_FILE variable for associated loop devices ?

Why would you *ever* want to mirror easily in /sys accessible kernel variables?

That is usually the wrong thing to do, because it can get out-of-sync,
and udev would pretend something that is not true anymore.

Kay

Re: add loop device backing file in udev database

[quidame]

Hi,

Le 2012-06-28 13:11, Kay Sievers a écrit :
> On Thu, Jun 28, 2012 at 12:39 PM,  <quidame@poivron.org> wrote:
>> Since kernel 2.6.37, some infos are available in /sys for associated 
>> loop
>> devices, especially the backing file. Is it poosible to introduce 
>> the
>> BACKING_FILE variable for associated loop devices ?
>
> Why would you *ever* want to mirror easily in /sys accessible kernel
> variables?

Because it reflects the status of a block device. If I run
# losetup /dev/loop0 /dev/sda1
# udevadm info --attribute-walk --name loop0
[...]
      ATTR{removable}="0"
      ATTR{ro}="0"
      ATTR{size}="4096512"
[...]
Nothing about the backing file, except we know the loop device is 
associated because its size is not "0". Its a poor and unusable 
information. And yes, the backing file name is easily accessible in 
/sys; but it is also the case for "removable", "ro" and "size". (OK, 
this is not about "ENV{BACKING_FILE}", but "ATTR{backing_file}". The 
first one was a suggestion, the second one is another.)

> That is usually the wrong thing to do, because it can get 
> out-of-sync,
> and udev would pretend something that is not true anymore.

Not sure:

# losetup -d /dev/loop0
# losetup /dev/loop0 /dev/sdc1  # sdc is USB stick
# udevadm info --export --query property --name loop0
BACKING_FILE='/dev/sdc1'
DEVLINKS='/dev/disk/by-label/mini /dev/disk/by-uuid/7B55-DC7E'
DEVNAME='/dev/loop0'
DEVPATH='/devices/virtual/block/loop0'
DEVTYPE='disk'
ID_FS_LABEL='mini'
ID_FS_LABEL_ENC='mini'
ID_FS_TYPE='vfat'
ID_FS_USAGE='filesystem'
ID_FS_UUID='7B55-DC7E'
ID_FS_UUID_ENC='7B55-DC7E'
ID_FS_VERSION='FAT32'
MAJOR='7'
MINOR='0'
SUBSYSTEM='block'
UDEV_LOG='3'
UDISKS_PRESENTATION_NOPOLICY='1'
USEC_INITIALIZED='96227881'

I wildly remove the usb stick, and the same command leads to the same 
results. This means BACKING_FILE, DEVLINKS and ID_FS_* variables are 
'out-of-sync'.
But:
# udevadm trigger --sysname-match=loop0
# udevadm info --export --query=property --name=loop0
BACKING_FILE='/dev/sdc1 _deleted_'
DEVNAME='/dev/loop0'
DEVPATH='/devices/virtual/block/loop0'
DEVTYPE='disk'
MAJOR='7'
MINOR='0'
SUBSYSTEM='block'
UDEV_LOG='3'
UDISKS_PRESENTATION_NOPOLICY='1'
USEC_INITIALIZED='96227881'

And:
# losetup /dev/loop0
/dev/loop0: [0005]:39712 (/dev/sdc1)

Here you can see that the only one relevant information is
BACKING_FILE='/dev/sdc1 _deleted_'

But, really I don't care: if 'udevadm info --attribute-walk --name 
loop0' can provide something as
[...]
      ATTR{removable}="0"
      ATTR{ro}="0"
      ATTR{size}="7813120"
      ATTR{backing_file}="/dev/sdc1 (deleted)"
[...]
it' s the same for me. What do you think about that ?

Cheers,
quidame

Re: add loop device backing file in udev database

[Karel Zak]

On Thu, Jun 28, 2012 at 04:38:46PM +0200, quidame@poivron.org wrote:
> >That is usually the wrong thing to do, because it can get out-of-sync,
> >and udev would pretend something that is not true anymore.

Right, /sys is always better place than udev db.

> # losetup -d /dev/loop0
> # losetup /dev/loop0 /dev/sdc1  # sdc is USB stick

There is also LOOP_CHANGE_FD ioctl, I have doubts that kernel informs
userspace about this change. (but standard userspace utils does not
use this ioctl)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com