On 01/14/2013 06:23 PM, Stefan Hajnoczi wrote:
> On Mon, Jan 14, 2013 at 04:16:34PM +0800, Liu Yuan wrote:
>> Hi List,
>> This problem can be reproduced by:
>> 1. start a sheepdog cluster and create a volume 'test'*
>> 2. attach 'test' to a bootable image like
>> $ qemu -hda image -drive if=virtio,file=sheepdog:test
>> 3. pkill sheep # create a half-closed situation
>>
>> I have straced it that QEMU is busy doing nonsense read/write() after
>> select() in os_host_main_loop_wait(). I have no knowledge of
>> glib_select_xxx, so someone please help fix it.
>
> You mentioned a nonsense read(). What is the return value?
>
> If you get a read with return value 0, this tells you the socket has
> been closed. Can you handle these cases in block/sheepdog.c?
>
This is what I saw repeatedly:
select(25, [3 4 5 8 9 10 13 18 19 24], [], [], {1, 0}) = 2 (in [5 13],
left {0, 999994})
read(5, "\6\0\0\0\0\0\0\0", 16) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
....
5 isn't a sockfd that sheepdog uses.
I don't know if I can handle it in sheepdog.c because I noticed that
there isn't any function called when this happens. So I suspect this
should be handle at upper block core.
Thanks,
Yuan
