(Sorry for the broken "Subject:" btw in the first mail.) On Tue, Oct 24, 2023 at 12:03:25AM -0700, Christoph Hellwig wrote: > On Mon, Oct 23, 2023 at 05:35:25PM +0200, Christian Brauner wrote: > > I just realized that if we're able to deprecate LOOP_CHANGE_FD we remove > > one of the most problematic/weird cases for partitions and filesystems. > > > change fd event on the first partition: > > > > sudo ./loop_change_fd /dev/loop0p1 img2 > > > > we call disk_force_media_change() but that only works on disk->part0 > > which means that we don't even cleanly shutdown the filesystem on the > > partition we're trying to mess around with. > > Yes, disk_force_media_change has that general problem back from the > early Linux days (it had a different name back then, though). I think > it is because traditionally removable media in Linux never had > partitions, e.g. the CDROM drivers typically only allocated a single > minor number so they could not be scanned. But that has changed because > the interfaces got used for different use cases, and we also had > dynamic majors for a long time that now allow partitions. And there > are real use cases even for traditional removable media, e.g. MacOS > CDROMs traditionally did have partitions. > > > For now, we should give up any pretense that disk_force_media_change() > > does anything useful for loop change fd and simply remove it completely. > > It's either useless, or it breaks the original semantics of loop change > > fd although I don't think anyone's ever used it the way I described > > above. > > Maybe we can just drop the CHANGE_FD ioctl and see if anyone screams? Yes, I suggested that in the prior mail. I think we should do that. We'd need changes to LTP and blktests but there are no active users in either codesearch.debian, cs.github, or cs.android.
