[systemd-devel] tentative state and unmount on mapper

[Lennart Poettering]

On Mon, 18.05.15 15:59, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:

> Hi,
> 
> There have been few discussions about tentative state and unmounting
> and I am experiencing different problem in the same device logic.
> 
> I am at 219 + 628c89cc + 496068a8 + 5259bcf6
> 
> I have 2 mounts (one is bind mount) on mapper device.
> 
> /proc/self/mountinfo:
> 47 37 254:0 / /var/spool/storage/SD_DISK
> rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
> /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
> 49 37 254:0 / /var/spool/storage/areas/SD_DISK/root
> rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4
> /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered
> 
> systemctl -t device --all | grep map:
> dev-mapper-mmcblk0p1.device   loaded activating tentative /dev/mapper/mmcblk0p1
> 
> As soon as I unmount the bind mount, systemd picks up the change in
> /proc/self/mountinfo and changes the "tentative" device to "dead" and
> due to that all file systems BindsTo to the device are being
> unmounted. Application which mounted the partitions is not getting a
> chance to unmount the fs.
> 
> Should I enumerate available mount units to see if anyone else has
> been mounted on the device that is about to be set as DEVICE_DEAD in
> device_update_found_one()?

The right fix is to ensure you ship the right udev rules for your DM
setup, so that the devices are properly announced by udev. Note that
DM/LVM/... might require compile switches to be specified to enable
proper udev support.

The "tentative" state is nothing the system should continously leave
devices in. It's a state only used for very short time windows, before
udev is up, or when a pseudo device (like a loopback block device) is
created and immediately mounted. If you have booted up and see a
device in "tentative" state, then something is really *wrong*.

Lennart

-- 
Lennart Poettering, Red Hat