Ovirt devel - Jul 2008 - [herrold@owlriver.com: Re: OLPC & package dependency growth]

The idea of 4k -> 512 byte sectors probably won't help our size
because the wasted space from files smaller than 4k will compress
nicely with squashfs - but would killing the journal gain us any
significant space ?

Daniel

----- Forwarded message from R P Herrold <herrold at owlriver.com> -----
> Date: Wed, 9 Jul 2008 17:16:01 -0400 (EDT)
> From: R P Herrold <herrold at owlriver.com>
> To: "Daniel P. Berrange" <berrange at redhat.com>
> Subject: Re: OLPC & package dependency growth
> 
> On Wed, 9 Jul 2008, Daniel P. Berrange wrote:
> 
> >> On Wed, 2008-07-09 at 16:10 +0100, Daniel P. Berrange wrote:
> >>> We could sure use some scripts to anaylse RPM deps on a
nightly basis
> >>> and produces reports on interesting stats. eg disk footprint
of the
> >>> chain starting from package 'X'   ... We
> >>> are fighting a similar battle to OLPC with the oVirt project
which
> >>> has a live CD we're trying to keep under 64 MB in size.
> 
> > Extra points if you round up the sizes to 4k to take account of the
> > typical ext3 blocksize which adds extra storage overhead for small
> > files.
> 
> With a known 64M cap, why not force the target empty image 
> into 512 byte blocks to get the minimum of wastage?  AND as it 
> is a live CD, why pay the ext3 journal penalty -- make it ext2 
> and be done with it (this may also permit a smaller kernel 
> footprint)?
> 
> I ask offlist as it is not really in scope on the main thread 
> about stats.
> 
> thanks --
> 
> -- Russ herrold
> 
----- End forwarded message -----

-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Daniel P. Berrange wrote:
> The idea of 4k -> 512 byte sectors probably won't help our size
> because the wasted space from files smaller than 4k will compress
> nicely with squashfs - but would killing the journal gain us any
> significant space ?
re: ext2 vs ext3...  I ran a quick test and on the Managed Node it saves 
about 800K on the compressed image size.  So it dropped from 57064392 to 
56211019.

Probably worth doing since we're not getting anything out of ext3 in this 
environment anyhow.

Perry