On Sun, Nov 06, 2016 at 03:27:00PM +0100, Andreas Henriksson wrote:
> > > 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.

Yes that's the issue.

Anyway, the interesting thing I found (at least as of a few years ago now), is 
that the
name is entirely arbitrary - can use any (currently unused) name.

So because I had a bunch of debootstrap chroots I used to spin up and
down automatically, I made sure that the loop dev name, matched the
crypt dev name, matched the filename that stored this loop instance.

Actually what I really did :), was take the container's basename,
add a random string to that, and use this name as a dot file name to
contain any other info I needed about the container instance, such as
the loop dev name/num, so I could later determinstically unwind cleanly.

This basename, a semi-randomized name (container basename + rand) became the
unique, but somewhat recognizable, crypt dev name, and is stored in the
dot file so I can cleanly locate the loop dev file. But given that the
crypt subsystem (cryptsetup command at least) takes an arbitrary name,
why not also the loop dev?


So ultimately, what my scripts need to do, for very practical reasons,
is allocate a new loop dev with a name predetermined by my script.

And someone else's auto loop mounting lightweight container system,
may have a different naming scheme you see, so someone using my scripts,
may well want the loop devs created by it to be in a common directory,
and those from some other lightweight container system to be contained
in a different directory.


And why not have such flexibility? Sure makes for quick determination of
which vm (/ lightweight chroot etc) is related to which loop dev, which
you're debugging or just wanting to investigate. The crypt devs already
support this.

Nowadays we have the -j option to losetup, along with -P and other
goodies in other places, so things are steadily getting easier for the
home-spun lightweight container buffs. Not to mention systemd :) - which
reminds me, I need to go learn systemd :)

Thanks again :)
Zenaan

Reply via email to