On Fri, 2006-03-10 at 15:42 +0100, boyer wrote: > I would like to mention another symptom: some directory show odd > statistics in the size field (too field) although their content in > number of objects is rather small.
The size of a directory will continue to increase whenever files are added to it, and will not shrink when they are removed. The directory size reflects the size of a table embedded in the directory that keeps track of a unique position for each entry that is necessary to make readdir always continue from the right place, even as entries are deleted. The table will be truncated to a zero size only if everything is deleted from a directory. > By the way, is it possible to see the filesystem getting disorganized > due an intensive destruction/creation activity. Are there tools to > measure it? Are there tool to reorganize? No. There aren't any defragmentation tools in existence for jfs. > Thanks. > Original message: > We are experiencing a serious problem with a 1TB filesystem under RH3 > kernel 2.4.21-27 on a Bi-xeon DELL PE1750. The disks are HDS 9570V > with Qlogic 2312 FC attach. > > After slowdown due to excessive IOWAIT and enless ls commands in a > 560000 inode directory (I know this may sound not reasonable!) , > > we have done a jfs_fsck who simply destroyed the directory to put it > in lost+found. > > We are currently restoring it from backups. > > Do you think that a bug in JFS could be in cause? Possibly > The file system was created in jfs 1.1.2 and we are currently running > jfs 1.1.10 There have been some fixes since 1.1.10. Richard Allen has created a jfs rpm for the 2.4.21-37 kernel (SMP) as well as source rpm on http://www.ra.is/jfs/rhel3/ This is based on the 2.4.32 jfs source. I am attaching some more recent patches that haven't made it into the 2.4 mainline if you want to be even more up to date. > Any hint would help. -- David Kleikamp IBM Linux Technology Center
jfs-patches-2.4.31.tar.gz
Description: application/compressed-tar
