[issue1556] many processes stuck in "hmrrcm", system unusable

[Steve O'Hara-Smith]

On Sun, 04 Oct 2009 21:46:30 +0200
"Simon 'corecode' Schubert" <corecode at fs.ei.tum.de> wrote:

> Steve O'Hara-Smith (via DragonFly issue tracker) wrote:
> > 	Voice from the sidelines - I would rather you worked on the
> > clustering, after all the hammer code won't really be stable until the
> > clustering is in.
> 
> Are you using hammer more than casually on any machine?  It is PAINFULLY 
> SLOW.  And adding clustering won't help, it might only make it even worse.

	Clearly I am not using it as hard as you are. For the way I am
using it at it is far from slow. I would not be at all surprised if adding
clustering made it worse, which is in fact the reason I'm suggesting it's
better to do that before attempting to optimise it.

	I do note that Matt suggested two scenarios that would lead to the
problem you describe. One being large amounts of inode creation and
destruction caused by unpacking large archives or deleting large numbers of
files, I have done both of these without seeing problems but perhaps they
weren't large enough. The other being heavy atime churn caused by heavy
random file access, this is a load that I have not (as yet) had cause to
impose on a hammer filesystem.

	If you are suffering the latter then I would certainly agree with
the suggestion to mount with noatime, I do this routinely for any file
system which gets heavy random file access because atime updates will
cripple performance on any filesystem I have ever used by making the discs
spend more time seeking than reading. It does sound like hammer may suffer
more than other filesystems from this.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/