On Thu, Dec 18, 2003 at 08:18:45AM +1100, Adam Cassar wrote: > Being maildir I presumed that the htree patch would improve performance > - but I was wrong. It depends on the workload. Things which do readdir scans of directories followed by a stat or a open of all of the files in the directory actually do worse with htree, because readdir() no longer returns files in the order they were created. This means the inodes get opened in random order, which means inode lookups that don't make the cache will on average require reading in a new inode table block, where as if you read inode 1000, 1001, 1002, 1003, etc., they will all be from the same inode table block. This can be fixed if you modify your application to pull all of the filenames using readdir, and then sort the files by inode number before trying to open or stat them. This has to be done in userspace because a directory can be arbitrarily big, so we can't do it in the kernel. However, for people who don't want to modify their application, I do have an LD_PRELOAD module which you can try using that should also do the trick (see attached). > After a reboot of the server filesystem corruption occured: > > EXT3-fs error (device blah): ext3_readdir: directory #3375965 contains a > hole at offset 4294967295 > > Also weird errors on partitions _not_ htree enabled: > kernel: attempt to access beyond end of device > kernel: 03:01: rw=0, want=1074108103, limit=489951 > > The above errors only occured on the htree enabled kernel. Switching > back to vanilla 2.4.23 resolved the issue (after an e2fsck which > reported no errors?) on the htree ext3 device. OK, this is weird. Was the reboot a clean reboot, or an unclean shutdown? The fact that e2fsck didn't report any errors is very curious, since normally both of these errors would be instantly picked up by e2fsck. The weird errors on non-htree enabled partitions are normally caused by unexpected crap in an indirect block or in the inode table, again, e2fsck finds those sorts of problems, so if e2fsck didn't find it, the corruption was in the cached copy in memory only. Normally this points to hardware problems, but if it was only happening with the htree kernel, that is very curious. I don't see how the htree patches could have caused such an effect. > Theodore, is the patch-ext3-dxdir-2.4.21rc5 the latest and greatest? Yup, it's the latest that is released. I have some patches internally against 2.4.23, but they don't have any additional changes or bugfixes over what was in 2.4.21rc5. There may have been some additional patches that went into 2.6, but I do keep an eye for them and push them into the 2.4 backport patches that I maintain. - Ted _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
