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.