Hi all, I've been trying out reiserfs as a replacement for ext2 in an application we have that suffers from a significant performance degradation due to searching fragmented files. I have a test system P133/32M running 2.2.19 with a HDD split into two identical partitions, one ext2, one reiserfs (ver 3.5.29). On these partitions I have been using a test script (100 dirs each with 100 files slowly growing) to generate badly fragmented filesystems on both the ext2 (e2fsck showed 98.9% non-contiguous) and reiserfs partitions in parallel. Using using "time grep -r string *" to parse the files in each partition (the string is not present) showed an unexpected result. The ext2 partition took a 3x performance hit when compared to the same files unfragmented (3m47s v's 1m6s). This was expected as this is what has been observed on the live system. However the result I wasn't expecting was that the Reiserfs partition took a 6x read performance hit compared to the same files unfragmented (6m38s v's 1m4.5s). This was worse than ext2 under the same conditions. BTW: To create an unfragmented copy for the comparisions I performed a copy off / make filesystem / copy back. First up is there likely to be any serious (and embarrasingly well known) flaws in my methodology that could be causing this result? Secondly has a better way been put forward to recover from fragmentation other than the copy off - format - copy back approach? If not could I suggest that it may be worth considering either a defrag utility or a task that performs a defrag continuously in the background? I dont see how it would be possible to attack this problem at write time as the final file size and growth characteristics are not known beforehand. I've browsed the archives and although there is some discussion on filesystem ageing and containing fragmentation at write time I havent seen anything that addresses this problem. Have I missed something? Cheers -Rod
