[haiku-development] Re: Q: Modifying InstallSourceArchive behavior
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 27 Apr 2010 19:55:00 +0200
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.
> 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... :-)
Bye,
Axel.
Other related posts:
