On Thu 2023-09-07 11:44:57, Jan Kara wrote: > On Wed 06-09-23 18:52:39, Mikulas Patocka wrote: > > On Wed, 6 Sep 2023, Christian Brauner wrote: > > > On Wed, Sep 06, 2023 at 06:01:06PM +0200, Mikulas Patocka wrote: > > > > > > BTW. what do you think that unmount of a frozen filesystem should properly > > > > > > do? Fail with -EBUSY? Or, unfreeze the filesystem and unmount it? Or > > > > > > something else? > > > > > > > > > > In my opinion we should refuse to unmount frozen filesystems and log an > > > > > error that the filesystem is frozen. Waiting forever isn't a good idea > > > > > in my opinion. > > > > > > > > But lvm may freeze filesystems anytime - so we'd get randomly returned > > > > errors then. > > > > > > So? Or you might hang at anytime. > > > > lvm doesn't keep logical volumes suspended for a prolonged amount of time. > > It will unfreeze them after it made updates to the dm table and to the > > metadata. So, it won't hang forever. > > > > I think it's better to sleep for a short time in umount than to return an > > error. > > I think we've got too deep down into "how to fix things" but I'm not 100% > sure what the "bug" actually is. In the initial posting Mikulas writes "the > kernel writes to the filesystem after unmount successfully returned" - is > that really such a big issue? Anybody else can open the device and write to > it as well. Or even mount the device again. So userspace that relies on > this is kind of flaky anyway (and always has been). Umm. No? I admin my own systems; I'm responsible for my userspace. Maybe I'm in single user mode. Noone writes to my block devices without my permissions. By mount, I give such permission to the kernel. By umount, I take such permission away. There's nothing flaky about that. Kernel is simply buggy. Fix it. [Remember that "you should umount before disconnecting USB devices to prevent data corruption"? How is that working with kernel writing to devices after umount?] Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates.
Attachment:
signature.asc
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
