> Because for writing _datablock_ on loopfs you need to write
> _indirectblock_ on hosting filesystem. Something that could not have
> happened before. And now imagine writing _indirectblock_ on loop,
> which results into write of _indirectblock_ on hosting fs. I am not
> telling you I understand those issues. I just see it is not easy.
Performing a loop block translation has always been able to invoke IO
to indirect blocks on the host fs --- it's just that traditionally
this has involved read, not write. Read is actually the harder case
in some ways, because (a) it can never be deferred in the block buffer
cache, and (b) there is less protection against filling the whole
request table and deadlocking --- writes are throttled to occupy only
the first 2/3rds of the request table.
I _think_ that there's some problem with fs superblock lock or something like
that. It is not just block layer that can daedlock - you've fs layer out there,
too.
To write datablock on loop device you need to write indirectblock on host
fs. So for datablock write on loop you need superblock lock on host or
something like that. (These are wild guesses.)
So, a great deal of deadlock protection is already in the loop support
for ll_rw_block.c. You'll need to do more than hand-waving to
demonstrate that sparse loopbacks won't work!
I've definitely seen deadlocks on 2.3.early. This is not plain hand-waving.
I'm not close to linux station now (writing mails in Delphi under Win95 :-(((( )
I can mail script to reproduce deadlocks if you are interested. But it does just
what I said: > /tmp/emptyfile ; mke2fs /tmp/emptyfile; mount /tmp/emptyfile
-oloop /somewhere; write to both /somewhere/XXX and /tmp/YYY. Deadlock.
When I made sure emptyfile does not contain holes deadlocks went away.
>> Swapping, of course, is a different issue. Do we have any flags at
>> the moment which prevent people from trying to swap to
>> inappropriate block devices (nbd, certain raid levels with md,
>> etc.)?
> No and I'd like to see such patch.
Why? 2.2 should work fine over those devices.
You are trying to tell me that swapping on nbd device works in 2.2?
Pavel
PS: Of course swapping over nbd does not work. When someone eats all
atomic memory (which almost never happens) you don't have enough memory
to receive ack for packet you send, and you deadlock. It is reproducible
with mem=8M and heavy pingflood, but artifical all-atomicram-eater works
much better.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/