Hi, I have been runing this along with the preemption patch on -pre12 without problems. Reiserfsck(ing) a snapshot shows no corruptions. The fs in question is fairly active - a 1G snapshot fills in about 12-18hours... I am keeping a couple of good backups just in case... Thanks, Ed Tomlinson On September 19, 2001 05:15 pm, Jeff Mahoney wrote: > Greetings all. > > I've been working on the bitmap performance improvement stuff for a > little while, and here's what I've come up with. I've been beating on this > patch for quite some time, and it's been solid so far. Basically what this > patch does is cache commonly calculated bitmap data, such as the first zero > bit and the free count. The patch then uses the calculated data to make > quicker decisions on whether or not a bitmap is worth searching. I've tried > to make the patch as unintrusive as possible. > > Please note, however, that it does depend on my endian safe patches > (available at > ftp://ftp.suse.com/pub/people/jeffm/reiserfs/kernel-v2.4), or as part of > -ac. The Bitmap Hinting patches haven't been applied to or tested with -ac > kernels. > > The bitmap hinting patch itself is attached. > > A more detailed rundown: > > With "stock" ReiserFS the bitmap blocks are read in during filesystem > mount. The patch extends this to read each block and calculate the > number of free bits, and also which bit is the first zero. During > execution, the first zero "hint" is kept up-to-date with the approximate > value of the first zero. The hint may be inaccurate and point to a used > block, but it should _never_ point to a bit beyond the first zero. This is > accomplished by pointing the first zero hint to newly freed blocks if they > are earlier than the current zero hint, and incrementing the zero hint > during allocation if the allocations takes the block marked by the current > zero hint. The zero hint may end up being quite a bit off the mark when the > callers are specifying a "target" block, but performance will never be lost > by it - just "gained less", since the search won't be starting from bit 0. > The "free count" is also kept up-to-date during free/allocation. > > Further, block distribution is normalized on full filesystems by > avoiding filling bitmaps past a certain percentage. This is currently > hard-coded at 90%, but could easily be changed to a #define or even a mount > option. The algorithm then searches for a bitmap containing the number of > free blocks over the threshold. If no bitmaps match the threshold, the > threshold is cut in half, and the cycle repeats. Under "normal" (< 90%) > usage, the loop will not even complete one iteration. Once the filesystem > becomes more populated (> 90%), the cycles will be invoked. Compared to the > current practice of searching every (even full) bitmaps, this is quite > fast. Leaving space free in the bitmaps should make it less susceptible to > fragmentation, since there should always be a few blocks close to the > requested area, especially if the fs is full. However, according to fibmap > results, the impact on fragmentation (again on a full fs) seems to be > negligible. > > Here are some performance numbers, on filling an empty 4.3GB filesystem > to 97% full. > > The test pool is spawning 18 "cp -a <src> <dest>/#" of a 240 MB > directory in parallel. > > Stock block allocation: > total sys: 835s > avg sys: 46.38s > > Stock block allocation, with hashing: > total sys: 836s > avg sys: 46.44s > > Bitmap hinted allocation: > total sys: 687s > avg sys: 38.16s > Advantage over stock, without hashing: 17.72% (!) > > Bitmap hinted allocation, with hashing: > total sys: 689s > avg sys: 38.27s > Advantage over stock, with hashing: 17.60% (!) > > Same scenario, less data, 46% full: > > Stock block allocation: > total sys: 321s > avg sys: 16.89s > > Stock block allocation, with hashing: > total sys: 336s > avg sys: 17.68s > > Bitmap hinted allocation: > total sys: 289s > avg sys: 15.21s > Advantage over stock, without hashing: 10% > > Bitmap hinted allocation, with hashing: > total sys: 310s > avg sys: 16.31s > Advantage over stock, with hashing: 8% > > -Jeff
