tux3: crash upon writing data with bs=1M

[OGAWA Hirofumi]

Dongsu Park <advance38 at gmail.com> writes:

> Hi OGAWA,

Hi,

> On 10.01.2013 04:32, OGAWA Hirofumi wrote:
>> Now, this issue was fixed, not fully though. (To fix fully, we have to
>> change core and have to implement allocation policy)
>> 
>> Current limitation is 4G blocks, because log size of block allocation is
>> u32. This limitation should not be trigger usually. To trigger this
>> limitation, need to have more than 512GB memory even if 512B blocksize.
>> 
>> Anyway, the limitation of current temp-atomic-commit branch should be
>> much less than before.
>> 
>> Tested by
>> 
>> 	$ dd if=/dev/zero of=file bs=1M count=1024
>
> 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.

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