Typically double mounts are done via bind mounts (not really double mounted just the device showing someplace else). Or one would do a mount -o remount,rw <originaldir> and remount it rw so you could write to it. A real double mount where the kernel fs modules manages both mounts as if it was a separate device won't work reliably, as the filesystem module/caching assumes it has total control. So writing to a read-write device that has a separate read-only mount with some data in the read cache will not return the true data in all cases. 2 read-write (done any way--except with a clustering fs modules) are going to cause corruption of the underlying filesystem. Given that the use case for the module is dangerous and the use case is of questionable usefulness I would think that is no point of the module. The module's intent seems to be to get around the exclusive locks that the filesystem (for good reason) is putting on the device. On Wed, Feb 15, 2023 at 3:33 AM Ganapathi Kamath <hgkamath@xxxxxxxxxxx> wrote: > > I am just an ordinary user of Linux and ventoy . > Q) > https://github.com/ventoy/Ventoy/issues/2234 > Is what I have suggested here, meaningful? > Is there contra-indications to not do it or an alternative suggestions? > thoughts? > > Ventoy, a GPL software, uses a small kernel patch to achieve a small remountability feature. > It seemed to me, that patching the kernel per distribution is sub-optimal. > I couldn't find a previous relevant discussion on this on dm-devel, but it seems like a requirement would've been well known and this would have already been discussed. What does the actually patch do? > > Thx > -Gana > > -- > dm-devel mailing list > dm-devel@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/dm-devel > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
