On Sun, Nov 06, 2016 at 12:38:01PM +0100, Andreas Henriksson wrote: > > FWIW, I think it is much tidier to have all loop devices in a sub > > directory of /dev/ , but my personal scripts need their own directory > > anyway, and I think that /dev/loop/ should contain all "default" / > > "auto generated"/ system loop devices - but that's just appearance > > and would probably require changes to many packages, just guessing.
> The loop nodes > are usually dynamically created these days so you don't need to > mess with them yourself. The automatic way will DTRT.) I think I was not clear - yes, they are (now) "automatic" from the admin setup perspective, but I'm pretty sure there is still a fixed upper limit, e.g. of 64 or something, which can be raised, but I think up to a maximum of 255 or something - but I last checked the kernel's loop module code only in March/April this year, and then it had that "max" hard coded kernel side limit that was existing up until that point at least. Perhaps it's been updated in more recent kernels to be fully dynamic in the kernel, to overcome this "max loop devices" limit? > The losetup utility supports both /dev/loopN and /dev/loop/N layout > (the latter likely for compatibility with older kernels/usecases). > > Atleast in my testing the attached patch should fix your particular > example, but I'm at the same time not sure how much else it breaks. > > I'm inclided to "wontfix" this because as far as I can tell the > problem only exists when you're /mixing/ both new and old way. Thank you for the old/new clarification. > That's something I'd just call not supported. I'd refer to using > either or. Either put your loop nodes in a the subdirectory or > don't. (I'd suggest don't.... and don't mess around with setting > things up more manually than you absolutely need. > Any comments to convince me to reconsider closing this as wontfix? All I can add is that I have no preference for which way (old/new) that loop nodes are represented in the filesystem, but that, for control in my script, and certainty of closing correct loop nodes (optionally crypted), I needed to determine the exact loop node name for notation outside the startup script, and subsequent pull down of the node on shutdown. I recall having trouble obtaining the loop node name when relying on automatic allocation/creation - perhaps this is no longer a problem. I can always reopen the bug if needed in the future, and there are other infrastructure projects nowadays anyway, rather than the old roll your own that I used up until I originally filed this bug report (containers, systemd and plenty more), which I should probably investigate and build on. > Regards, > Andreas Henriksson Thank you for the patch, appreciated. Kind regards, Zenaan
