Hi, just a "heads up" to prevent inclusion of LU u8 aka 121430-42/121431-43 bugs. The ludo bug wrt. the vfstab is probably already known. However there is another bug, which prevents proper BE umounts. I.e. luumount and friends will fail, if a dataset is mounted in the global zone and inherited to a non-global zone. E.g. for a "lumount $BE /mnt":
pool1/web/foo/sites - /pool1/web/foo/sites zfs - no rw,devices,setuid,nonbmand,exec,xattr,noatime /pool1/web/foo/sites - /pool1/zones/foo/root/data/sites lofs - no rw,nodevices /pool1/web/foo/sites - /pool1/zones/foo/root/mnt/data/sites lofs - no rw,nodevices /pool1/zones/foo-s10u8/root - /pool1/zones/foo/root/mnt lofs - no The root cause is, that lumount_zones uses "lulib_unmount_pathname $mntpoint" instead of /sbin/umount $mntpoint. Because "lulib::lulib_get_zfs_dataset_from_mntpt $mntpoint" now (since the mentioned patches) returns the corresponding dataset indeed, this results into a "/sbin/zfs umount $dataset" or wrt. example "zfs umount pool1/web/foo/sites"! zfs seems not to return an error code != 0 - however it isn't checked anyway. The consequence is, that the zonepath can not be umounted (in the example /pool1/zones/foo/root/mnt) and thus can not be removed. This leads to a break and umounting pathes from other non-global zones is skipped completely, which leaves a lot of lofs mounted FS and finally breaks luumount and friends. So, please fix before including the changes into Nevada. Proposed fix: http://iws.cs.uni-magdeburg.de/~elkner/luc/lumount_zones-5.10u8.patch Regards, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768
