On Fri, 2007-10-05 at 15:51 -0600, Poul Petersen wrote: > I have a 100G JFS filesystem running inside LVM on a hardware > RAID5 volume. The space is being used for a postgres database which is > using about 43GB. The backup process (which writes to a separate volume) > used to run in a mere hour or two, but is now running for 16 hours or > more, even though the DB has not increased much in size and the DB > "load" stays constant. The only reason I'm thinking about JFS being > involved in the slowdown is that a read-only fsck is showing some errors > that look like: > > **Phase 7 - Verify File/Directory Allocation Maps > Errors detected in the Fileset File/Directory Allocation Map control > information. (F) > Errors detected in the Fileset File/Directory Allocation Map. (F) > **Phase 8 - Verify Disk Allocation Maps > Incorrect data detected in disk allocation structures. > Incorrect data detected in disk allocation control structures. > > Specificially: > > Inode Allocation Group F99 is inconsistent. > The Inode Allocation Map has an incorrect number of backed inodes value > (F). > The Inode Allocation Map has an incorrect number of free inodes value > (F). > The Inode Allocation Map control information has an incorrect number of > free inodes value for AG F6. > The Inode Allocation Map control information has an incorrect number of > backed inodes value for AG F16. > The Inode Allocation Map control information has an incorrect number of > free inodes value for AG F16. > ... > Incorrect number free detected in dmap 2659. > Incorrect internal (0) value detected in DM page 2659. > Incorrect internal (1) value detected in DM page 2659. > Incorrect internal (2) value detected in DM page 2659. > Incorrect internal (4) value detected in DM page 2659. > ... > Inconsistencies detected in leaf values (DM). > Inconsistencies detected in internal values (DM). > Incorrect data detected in pages (DM). > Inconsistencies detected in leaf values (L0). > Discrepancies detected in the Block Map Control Page AG free count list. > Incorrect data detected in the Block Map Control Page. > Incorrect data detected in disk allocation structures. > Incorrect data detected in disk allocation control structures. > > Could this cause performance problems?
I'm not sure. Was the file system unmounted, or mounted read-only, when you ran fsck? If not, it might be okay. You can't trust fsck results when the file system is mounted read-write. If it was unmounted, running fsck -f against the file system will fix it. I'd recommend doing that. > Could this be some kind > of JFS fragmentation problem? That's a possibility. We still don't have a defrag tool. I have ideas about smarter allocation that will help avoid fragmentation, but I haven't implemented anything yet. > BTW, I've noticed that filesystems > sometimes become corrupted after doing an online resize... There have been reports of problems after resize for a while. I haven't reproduced anything myself, but I haven't put enough effort into it either. > Fedora Core release 6 (Zod) > 2.6.18-1.2798.fc6 > jfsutils-1.1.10-4.1 > > Thanks, > > -poul -- David Kleikamp IBM Linux Technology Center ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
