Messages in this thread | | | Date | Sun, 11 Nov 2007 06:33:57 +0100 (CET) | From | Mikulas Patocka <> | Subject | Re: Temporary lockup on loopback block device |
| |
> > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |