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

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 27 Apr 2010 20:16:25 +0200

On 2010-04-27 at 19:55:00 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
wrote:
> Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > On 2010-04-27 at 16:52:03 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > > > 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).
> 
> The more problems come up, the more I want this file cache/block cache
> VMCache solution which would solve all this neatly, including taking
> the block size of the underlying device into account.

I certainly won't stop you. :-)

> > 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.
> 
> We could add a tarfs layer on top of BFS... :-)

Or a gzip partitioning system below. No real solution for anyboot, though, 
since while it would help with the CD space issue, there should also be 
write support when the image is dd'ed to an USB stick.

CU, Ingo

Other related posts: