I'd argue that this is general file system issue, not so much a wafl issue. I don't think wafl is particularly slow at this workload either, they do far better then most other nas gear I've used for this workload. There are trickier things out there, like bluearc has some preloaded cache for meta data to help speed it along, but that's just fixing the problem by tossing it all in memory. If you compare a file system operation to file system operation between netapp and bluearc I'm sure you'd fine similar performance issues for a directory with millions of objects.
But I do hope some of those wafl guys can figure out a way to make lots of objects in a file system faster. It can be a huge pain.
-Blake
On 10/22/07, Peter D. Gray pdg@uow.edu.au wrote:
On Mon, Oct 22, 2007 at 12:55:48PM -0700, Blake Golliher wrote:
I have to deal with millions of objects in filesystems, I highly recommend subdirectories. look at your nfs_hist output. First do nfs_hist -z. Then count to 30 and run nfs_hist again. It's a histogram of all nfs ops, and how long they took in milisecond buckets. I'd bet lookup is taking a very long time. When dealing with a large number of objects, sensible directory structures are key.
Yes, but to be fair, this is a weakness in the wafl filesystem. You cannot have everything, and wafl has made a trade off in the way it stores file metadata that makes it slow to handle large number of files in a directory.
I am not sure if netapp is planning any enhancements in this area or even what would be possible.
Anybody care to comment?
Regards, pdg
--
See mail headers for contact information.