On Mon, Jan 09, 2017 at 03:22:00PM +0100, Zdenek Kabelac wrote: > lvm2 will initiate lazy umount of ALL thin devices from a thin-pool > when it gets about 95% fullness (so it's a bit sooner then 100% > with still some 5% 'free-space'. Yes, and we want this not to be done. Not for XFS and not for any other file system. umounting is something neither lvm nor the filesystem should do, but instead the administrator. > So it should get into EXACT same state as is advocated here - do nothing > case - without invoking 'lazy umount' but significantly later > (so IMHO causing possibly more damage to a user). The lazy unmount does not help. If LVM want to give the fs a headups about running out of space please do so, this would be useful as we could then do sensible things, like doing a discard of all free blocks or an explicit, early fs shutdown. But don't just lazy unmount the fs which only creates lots of problems. > But could anyone from XFS specify - why umount is causing some 'more' > damage, then no umount at all ? It is causing damage because unmount cause additional I/O, at a point where we possibly might not want more I/O. It also doesn't let the file system to do useful things. And last but not least it changes the namespace (aka mount topology) in an absolutely unexpected way, which might even introduce security issues because now users could write into otherwise hidden directories in the parent mountpoint. > Also please note - since its mentioned namespaces here - if this is > something Docker related - be aware for Docker thins - lvm2 for awhile is > leaving such volumes intact already (-> no umount for docker thins volume). The filesystem namespace has nothing to do with docker at all. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
