[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jfs-discussion
Subject:    Re: [Jfs-discussion] Performance problems, fsck errors?
From:       Dave Kleikamp <shaggy () linux ! vnet ! ibm ! com>
Date:       2007-10-12 17:27:25
Message-ID: 1192210045.6240.17.camel () norville ! austin ! ibm ! com
[Download RAW message or body]

On Fri, 2007-10-12 at 11:19 -0600, Poul Petersen wrote:
> > 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. 

I'll try to find the time to play around with running fsck on a
read-only mount.  Running fsck -n is kind of rare in practice, so this
kind of problem may not be noticed.  If you ever run fsck -f , the inode
and block maps are silently rebuilt, so errors won't be detected or
reported then.

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

Sorry for not being more aggressive with the testing.  I've been working
on other things.

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

I'll try to carve out some time to do more testing.

> -poul

Thanks for all your help.

Shaggy
-- 
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
Jfs-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
[prev in list] [next in list] [prev in thread] [next in thread]