Hello Zenaan Harkness. Thanks for quick followup
On Mon, Nov 07, 2016 at 12:33:10AM +1100, Zenaan Harkness wrote: > 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'd suggest using the output from 'losetup -f' if you need to know the name. Ofcourse obtaining a name and then later allocating it is racy, but oh well.... There's probably a good way to mount first and then look up which loopdev was allocated to solve that if needed. > > 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. Regards, Andreas Henriksson
