add loop device backing file in udev database

[q***@poivron.org]

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?bug=671546) who has
recommended me to directly propose this change to the upstream
maintainer.

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

[Kay Sievers]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[q***@poivron.org]

Hi,

Post by Kay Sievers

Since kernel 2.6.37, some infos are available in /sys for associated=

=20

Post by Kay Sievers

loop
devices, especially the backing file. Is it poosible to introduce=20
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}=3D=3D"0"
ATTR{ro}=3D=3D"0"
ATTR{size}=3D=3D"4096512"
[...]
Nothing about the backing file, except we know the loop device is=20
associated because its size is not "0". Its a poor and unusable=20
information. And yes, the backing file name is easily accessible in=20
/sys; but it is also the case for "removable", "ro" and "size". (OK,=20
this is not about "ENV{BACKING_FILE}", but "ATTR{backing_file}". The=20
first one was a suggestion, the second one is another.)

Post by Kay Sievers
That is usually the wrong thing to do, because it can get=20
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=3D'/dev/sdc1'
DEVLINKS=3D'/dev/disk/by-label/mini /dev/disk/by-uuid/7B55-DC7E'
DEVNAME=3D'/dev/loop0'
DEVPATH=3D'/devices/virtual/block/loop0'
DEVTYPE=3D'disk'
ID_FS_LABEL=3D'mini'
ID_FS_LABEL_ENC=3D'mini'
ID_FS_TYPE=3D'vfat'
ID_FS_USAGE=3D'filesystem'
ID_FS_UUID=3D'7B55-DC7E'
ID_FS_UUID_ENC=3D'7B55-DC7E'
ID_FS_VERSION=3D'FAT32'
MAJOR=3D'7'
MINOR=3D'0'
SUBSYSTEM=3D'block'
UDEV_LOG=3D'3'
UDISKS_PRESENTATION_NOPOLICY=3D'1'
USEC_INITIALIZED=3D'96227881'

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

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

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

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

Cheers,
quidame
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug=
" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Karel Zak]

Post by q***@poivron.org

Post by Kay Sievers
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.

Post by q***@poivron.org
# 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