Re: Temporary lockup on loopback block device

[Mikulas Patocka]

> > > Arguably we just have the wrong backing-device here, and what we 
> > > should do is to propagate the real backing device's pointer through 
> > > up into the filesystem.  There's machinery for this which things 
> > > like DM stacks use.

Just thinking about the new implementation --- you shouldn't really 
propagate physical block device's backing_device into loopback device.

If you leave it as is (each loop device has it's own backing store), you 
can nicely avoid the long-standing loopback deadlock coming from the fact 
that flushing one page on loopback device can generate several more dirty 
pages on the filesystem.

If you let loopback device and physical device have the same backing 
store, then it can go wild creating more and more dirty pages up to a 
memory exhaustion. If you let them have different backing stores, it can't 
happen --- loopback flushing will just wait until the pages on the 
filesystem are written.

Mikulas

> So I compiled it and I don't see any more lock-ups. The writeback loop 
> doesn't depend on any global page count, so the above scenario can't 
> happen here. Good.
> 
> Mikulas
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/