Re: reiser fs slow on mksf and mount

[Jeff Mahoney <jeffm@suse.com>]

-----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."

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDEyDlLPWxlyuTD7IRArjZAJoCxQCJ8Qs4AM1OQZEJIhz1BvYwDQCeIRk+
VvRxXcyH1puW2vq1xDYygL0=
=FVcM
-----END PGP SIGNATURE-----