看板 DFBSD_bugs 關於我們 聯絡資訊
On Sun, 04 Oct 2009 21:46:30 +0200 "Simon 'corecode' Schubert" <corecode@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/