tux3: crash upon writing data with bs=1M

OGAWA Hirofumi hirofumi at mail.parknet.co.jp
Fri Jan 11 18:11:04 PST 2013


Daniel Phillips <daniel.raymond.phillips at gmail.com> writes:

> Hi HIrofumi,

Hi,

> On Fri, Jan 11, 2013 at 9:15 AM, OGAWA Hirofumi
> <hirofumi at mail.parknet.co.jp> wrote:
>> 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....
>>
>> 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.
>
> Right. When balloc fails, it should return the largest extent actually
> found. Then we must call balloc again to get the remainder, and repeat
> until we finally fill the complete logical range. We do not need any
> new allocation optimization for this, however I am working on a design
> proposal for exactly that, expected to be posted soon.
>
> Just to confirm: It is correct to assert here (as in current Git)
> because we should not report ENOSPC unless the volume is actually
> full.

balloc() returns ENOSPC if there is no contiguous region even if not full.
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>




More information about the Tux3 mailing list