On Mon, Oct 16, 2017 at 12:44:33PM -0500, Eric W. Biederman wrote: > Dave Chinner <david@xxxxxxxxxxxxx> writes: > > On Sun, Oct 15, 2017 at 05:14:41PM -0500, Eric W. Biederman wrote: > >> So my suggestions for this case are two fold. > >> > >> - Tweak Docker and friends to not be sloppy and hold onto extra > >> resources that they don't need. That is just bad form. > >> > >> - Generalize what ext4, f2fs, xfs and possibly the network filesystems > >> with umount_begin are doing into a general disconnect this filesystem > >> from it's backing store operation. > >> > >> That operation should be enough to drop the reference to the backing > >> device so that device mapper doesn't care. > > > > Define the semantics of a forced filesystem unmount are supposed to > > be first, then decide whether an existing shutdown operation can be > > used. It may be we just need a new flag to the existing API to > > implement slightly different semantics (e.g to silence unnecessary > > warnings), but at minimum I think we've need the ->unmount_begin op > > name to change to indicate it's function, not document the calling > > context... > > Definite the expected semantics of a forced filesystem umount is the > same process as defining the semantics of a forced filesytem shutdown. > Look at the code and see what it does and document it. > > That said, a quick skim through the umount_begin methods on network > filesystems (the only filesystems that implement umount_begin) it > appears they drop the network connection. Which is pretty much the same > as dropping the connection to the bdev. Sure. But what do they do to incoming attempts to read from the filesystem, or modify/write it in some way? That behaviour really isn't defined in any way and what we need to do that so *all filesystems behave the same way*. As I've already pointed out, ext4 implements different shutdown semantics to XFS even though it copied the user API to trigger shutdowns. That's not an acceptible situation for a generic shutdown operation.... > So I think there is good reason > to believe these two cases can be unified. They may not be exactly the > same but they are close enough that the should be able to share common > infrastructure. You're making it sound so much simpler than it really is... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
