On Feb 11 2016 at 14:47 Stanislav Brabec wrote:
There are missing umount commands in the middle of the test, which trigger following problem: truncate -s10M source.img mkdir -p /source/subdir mkdir -p /dest /sbin/mkfs.ext4 source.img losetup /dev/loop0 $PWD/source.img mount -text4 /dev/loop0 /source mkdir -p /source/subdir mount -o bind /source /dest mount -o bind /source/subdir /dest Mounting a bind mount over a root of existing bind mount causes mounting over the bind mount source. I expected mounting over the target directory I specified. I am not sure, whether it is correct behavior, but for sure it is surprising.
We discussed it with David and considered that it is an unexpected but correct behavior, that is a consequence of systemd introducing new default behavior for mounts. All bind mounts are shared by default, which causes propagation of a mount inside a target (including the target root) into a source.
Additionally, I am working on a reproducer of an invalid "mount -a" behavior triggered by kernel bug reporting false subvol.
I already have a possible fix for it, but I want to confirm that it is correct before sending it upstream.
I finally found a reproducer. It is a negative reproducer, i. e. fstab that should cause error, but it does not. I am still not sure, whether positive reproducer exists. I will send a fix and testcase in a separate thread. After that, all discovered btrfs mount issues will be finally fixed. There is another known problem with non intuitive output of lsblk with btrfs, but it is above the scope of this thread. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@xxxxxxxx Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
