Re: RELEASE discs & ISO images (for future)

Vadim Goncharov wrote:
 > Oliver Fromme wrote:
 > > [...]
 > > > >    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.

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.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29,
85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, 
Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister:
Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb,
Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd


"Documentation is like sex; when it's good, it's very,
very good,
and when it's bad, it's better than nothing."
        -- Dick Brandon
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

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_nuclightmail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nu
clight]

_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"