Re: bug in 2.6.22-rc2: loop mount limited to one single iso image

["Ray Lee" <ray-lk@madrabbit.org>]

On 5/20/07, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On 5/20/07, Ray Lee <ray-lk@madrabbit.org> wrote:
> > On 5/19/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> > > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > > Ken? Ball's in your court. As the patch isn't providing a killer
> > > > feature for 2.6.22, I'd suggest just reverting it for now until the
> > > > issues are ironed out.
> > >
> > > Hold it.  The real question here is which logics do we want there.
> > > IOW, and how many device nodes do we want to appear and _when_ do
> > > we want them to appear?
> >
> > The when part is what looks to make it racy. I'm guessing that we're
> > relying on udev to create those loop nodes. If so, I think any scheme
> > that creates more on demand would give transient mount errors while
> > it's waiting on udev to create more nodes.
> >
> > Perhaps if we were to start with 8 loop nodes at init (as we have in
> > 2.6.21), and then always maintain a margin of 8 (or 4, or...) when
> > they start being used or detached?
>
> Until the tools can request dynamic loop device allocation from the
> kernel before they want to use the device, you can create as many as
> needed "static" loop* nodes in /lib/udev/devices/, which will be
> copied to /dev/ early on every bootup.

Except that's different than current behavior presented to userspace.
IOW, we broke userspace for anyone using udev. Which is, y'know, a lot
of us.

We're at -rc2 right now. Given that, it looks like we have two
options. First is to revert all this for now and try again when the
patch has had more testing and agreement (as this isn't a major
feature we're talking about here; it's effectively just a cleanup that
happened to have unfortunate side-effects).

The second option is that we could have the loop device start with 8
nodes populated, which would match current behavior.

A third option of requiring new userspace for 2.6.22 is a non-starter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/