bug in ufs?

[pluknet]

2009/7/7 Marat N.Afanasyev <amarat at ksu.ru>:
> Kostik Belousov wrote:
>>
>> On Tue, Jul 07, 2009 at 12:15:46AM +0400, Marat N.Afanasyev wrote:
>>>
>>> Kostik Belousov wrote:
>>>>
>>>> On Mon, Jul 06, 2009 at 09:45:45PM +0400, Marat N.Afanasyev wrote:
>>>>>
>>>>> i have a huge amount of small files on the source systems, as you can
>>>>> see they have about 20 million files and almost each of them is jpeg or gif.
>>>>> afaik, there are no sparse files at all.
>>>>>
>>>>> i still cannot figure out what is it: a free space leak in ufs2+su or
>>>>> bug in statfs(3), that is used in df, or something else.
>>>>
>>>> My guess that it is due to fragmentation.
>>>> As an experiment, try to create 1-byte file. Does it work on the
>>>> filesystem
>>>> in described state ?
>>>
>>> I can create small files, as many as i have patience, maximum size of
>>> such "small file" is 14336, so. it seems that if file is no greater than
>>> (block_size-2048) it can be created. larger file cannot be created.
>>>
>>> imho, fragmentation on filesystem should be very low, there were no
>>> deletions on it, just creations.
>>
>> The fragmentation on UFS usually means using fragments for the file tails,
>> not having file sequential blocks allocated in the non-sequential disk
>> blocks.
>>
>> You experiment confirms my hypothesis.
>
> i cannot create a slightly larger
> file joining two unallocated parts of different blocks even if no fully free
> block exists? ;)

You can't.

As far as I remember, ffs_alloc() tries to populate a number of whole blocks
and then only packs a remain data tail into a partially allocated block (one,
two, .. seven fragments), thus creating a block fragmentation.
In other words, it's impossible to partially allocate several blocks
for a one file.
Can you show your dumpfs output (superblock part)?

-- 
wbr,
pluknet