Re: RELEASE discs & ISO images (for future)

From: Vadim Goncharov <vadim_nuclight_at_mail.ru>
Date: Mon, 24 Mar 2008 05:12:18 +0000 (UTC)
Hi Oliver Fromme! 

On Tue, 18 Mar 2008 14:59:51 +0100 (CET); Oliver Fromme wrote about 'Re: RELEASE discs & ISO images (for future)':

>>>>>    224655360   7.0-RELEASE-i386-livefs.iso
>>>>>     94493696   7.0-RELEASE-i386-livefs.iso.uzip (16k cluster)
>>>>>    110188032   7.0-RELEASE-i386-livefs.iso.uzip (2K cluster)
>>>>> 
>>>>> So the difference is 124 MB for 16K cluster size, and
>>>>> 109 MB for 2K cluster size (which is noticably faster
>>>>> during access).  Actually the space savings will be a
>>>>> bit less, because the /boot directory (about 30 MB)
>>>>> won't be compressed.  So the real gain is probably a
>>>>> little less than 100 MB in the 2K case.
>>>> 
>>>> By the way, the maxmum cluster size is 127k or 130048 with uzip,
>>>> if you want to maximize the compression ratio.
>>> That would make the live FS painfully slow, and it wouldn't
>>> make a big difference from the default (16K).
>>> It is already noticeably slow with the default cluster size
>>> of 16K on my test machine (a 1 GHz VIA C3), so would rather
>>> prefer to use 2K cluster size, even though compression will
>>> be not quite as good.  (2K is the minimum, less than that
>>> doesn't make sense for CD9660 media because the physical
>>> sector size is 2K.)
>> 
>> How much is slowdown from 2K to 16K ?
> It's very noticeable.  I haven't done benchmarks, but
> you can clearly feel the difference.  A find(1) takes
> more time.  Also man(1) takes longer until the page
> comes up.  Any kind of random access is slower, unless
> all data is already cached.

A find(1) on livefs is useless most of time. But man(1) is more valuable,
though.

> Interestingly there doesn't seem to be a difference
> between 2K and 4K, and the difference to 8K is only
> very small.  But there is a noticeable difference
> between 8K and 16K.  I don't know why, maybe it's
> related to FreeBSD's handling of FS buffers.  So
> maybe the "optimal" cluster size for an acceptable
> performance/compression ratio would be 8K.

Agreed.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight_at_mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Received on Mon Mar 24 2008 - 04:12:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:29 UTC