[haiku-development] Re: Q: Modifying InstallSourceArchive behavior

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 27 Apr 2010 17:44:49 +0200

On 2010-04-27 at 16:52:03 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
wrote:
> Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > On 2010-04-27 at 12:34:54 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > > wrote:
> > > Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > > > Do we already have estimates what the sources will weigh
> > > > altogether?
> > > > If it
> > > > isn't way beyond the 700 MB mark, we could get away with kicking
> > > > some
> > > > stuff
> > > > off the image. Also, switching to 1 KB BFS block size could save
> > > > some
> > > > MB.
> > > But this would hurt performance even more for a CD without the
> > > IOCache.
> > Even then, if my assumption is correct that for most files all
> > attributes
> > would fit even in the small data section of 1 KB blocks, there'll be
> > no
> > performance difference in those cases. Due to the greater data density
> > we
> > might even reduce seeking overhead.
> 
> Not sure if I understand you. The problem is that CDs actually have a
> 2048 byte block size natively, so unless you cache things, you cause
> more seeks with a 1K block size.

Assuming that the block cache doesn't do any kind of pre-caching or 
detection of contiguous read, I suppose more reads are to be expected when 
reading in individual blocks of e.g. large directory. Whether a 1 KB or a 2 
KB block is read for an inode is really irrelevant as in both cases the I/O 
scheduler will read 2 KB. With 1 KB blocks the inodes will lie closer 
together -- no clue how CD-ROM drives work, but I guess it doesn't harm at 
least, if both have to be read (maybe even reducing seeking).

BTW, building an anyboot alpha2 image with 1 KB block size saves only about 
28 MB (571 MB used) which probably won't be enough, anyway.

CU, Ingo

Other related posts: