tux3: crash upon writing data with bs=1M

[OGAWA Hirofumi]

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

>> On Wednesday, January 02, 2013 03:27:38 PM Dongsu Park wrote:
>>>   # insmod ./user/kernel/tux3.ko
>>>   # ./user/tux3 mkfs -b 4096 /dev/vdb
>>>   # mount -t tux3 /dev/vdb /mnt/tux3
>>>   # dd if=/dev/zero of=/mnt/tux3/test1 bs=1M count=256
>
> Thanks for the report. This is known issue what I'm trying to fix now.
> Current balloc() supports only limited length of blocks (maximum is
> blocksize * 8 blocks for now).
>
> But, the inode of this delta is trying to allocate 46390 blocks
> (limitation is 32768 on blocksize==4096). So, it exceeds current
> limitation.
>
> Workaround for this is, write data separately, and sync for each write. 
>
> Well, I'll fix this. But I'm going to rewrite balloc() more or less, not
> just fix, so it may take a time than usual.

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

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