> 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.

        It was a mounted read-only fsck.

> 
> If it was unmounted, running fsck -f against the file system will fix
> it.  I'd recommend doing that.

        I managed to schedule some downtime and fsck'd the disk. It
improved performance overall dropping the time it took for backups from
16 hours to 9 hours. Interestingly, the online read-only fsck did not
show errors immidiately after fsck'ing/remounting the filesystem, but
did show similar errors an hour or so later. However, performance was
still not as good as we expected. 

> 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.

        In fact, I reported one a year or two ago, now that I think
about it :)

        Since online resizing was one of the primary reasons we choice
JFS and since we've had some problems with it on this system we decided
to move to EXT3. We had another opportunity for some downtime on this
DB, so I dumped the DB and recreated the filesystem with EXT3. Backups
are now running in under an hour and overall system performance is
better than ever. HOWEVER, that's NOT by any means meant to be a
comparison between JFS and EXT3, since we were getting good performance
from JFS when we first setup the DB as well. I suspect the dump/restore
process eliminates fragmentation within the postgres DB as well as at
the filesystem level. I also tweaked some postgres settings. So, lots of
variables have changed. 

        I still use JFS at home and on another critical NFS server, so
I'm interested in getting to the bottom of the online resizing problems.
I'll see if I can put together a test box and get a test case going if
you're interested in having some solid examples.

-poul

-------------------------------------------------------------------------
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

Reply via email to