On Mon, 2005-08-29 at 10:51 -0400, Jeff Mahoney wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ming Zhang wrote: > > On Mon, 2005-08-29 at 10:26 -0400, Jeff Mahoney wrote: > > No. Block size is the declared filesystem blocksize, not the hardware > > sector size. It must be a power of 2, and 512-8192 bytes. The "standard" > > filesystem blocksize is 4k. If you've declared your block size as 512 > > bytes (using mkreiserfs -b 512), that would certainly be another source > > of performance issues. > > > >> so 1 block per bit, thus (blocksize * 8) block per block. > > Exactly. > > >> since that is a newly formatted fs, there is no journal to replay. > >> because that FS is big with 3.2TB, if bitmap is not continuous on disks, > >> then the read is like a random read to read around total ~100MB 4K piece > >> from disk. so this is why it is slow? > > I need to look into this some more, but I suspect it may be related to > congestion avoidance. The requests don't bind up in waiting for the data > to come back, but, rather, allocating the request in the first place. > > >> any way to store these bitmap together? > > The "old" reiserfs disk format did exactly that. However, the gain > realized (if any, see above) at mount time is quickly lost when the > filesystem can no longer be dynamically expanded/shrunk, and if the > bitmaps are actually read on-demand, then it causes needless seeks to > the "bitmap secion."
but anyway the bitmap will not scattered all around the disk rite? so where i could find a document about this bitmap layout? also detailed information on whole file system layout? thanks. ming > > - -Jeff > > - -- > Jeff Mahoney > SuSE Labs > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFDEyDlLPWxlyuTD7IRArjZAJoCxQCJ8Qs4AM1OQZEJIhz1BvYwDQCeIRk+ > VvRxXcyH1puW2vq1xDYygL0= > =FVcM > -----END PGP SIGNATURE-----
