tux3: crash upon writing data with bs=1M

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi at mail.parknet.co.jp> writes:

>> I tested with the most recent commit 57d9ca67.
>> It looks like ok, until I started testing with fio.
>>
>> # fio --name=tux3test --filename=/mnt/tux3/tfile1 --size=2G --bs=1G \
>> --rw=rw --ioengine=sync
>
> Thanks for testing.
>
>> The kernel crashes with the following log:
>>
>> [   65.262978] tux3_fill_super: s_blocksize 4096
>> [  185.839006] balloc: couldn't balloc: blocks 71224
>
> This is also ENOSPC. Hm, it is trying to allocate about 278MB extent.  I
> guess, fio issued so many writes. And storage used for tux3 is small
> relatively if compared with total write size? I don't know above fio
> options what do actually.
>
> My guess is the FS was fragmented by many writes, and there is no
> contiguous region for 71224 blocks in the storage anymore. Current git
> doesn't support this condition.
>
> 	tux3graph -v /dev/foo > dump.dot
>
> This command will dump the on-disk structures. And we may be able to see
> if my guess is true.
>
> To fix this, we need to start allocation policy more or less. If tux3
> can't find contiguous region, we have to choose smaller region.

I couldn't reproduce and confirm though, I think now this problem was
fixed. :) Although, we don't still implement allocation policy, now
current "hirofumi" branch allow partial allocation if it couldn't
allocate contiguous blocks.

Thanks.
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>