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
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.
> 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?
> 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.
IBM Linux Technology Center