bug in ufs?
amarat at ksu.ru
Mon Jul 6 22:08:27 UTC 2009
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
> You experiment confirms my hypothesis.
is there any way to change this behavior? and i wonder why even if i can
create a reasonable number of small files i cannot create a slightly
larger file joining two unallocated parts of different blocks even if no
fully free block exists? ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3221 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090706/5e0af2ec/smime.bin
More information about the freebsd-stable