I'd like to thank Dan Harrington, Jesper Frank Nemholt, Selden E Ball
Jr, Keith Strange, Dr. Blinn, Robert Fridman, Kevin Binda, Horst Dieter
Lenk, and alan_at_nabeth for their replies and comments.
I've gotten many suggestions including memory file system (mfs), solid
state disks, disk with large on-board cache/fast rotational speed, and
using PrestoServe. Some people described their own implementations and
reported on good performance.
After much discussion and all kinds of budget analysis, we decided to
purchase the four HSZ80 RAID controllers and many disks.
---excerpt from Dr. Blinn's response---
I suspect the performance killer in this application is going to be
the filesystem metadata updates. In a UFS file system, this usually
results in forced writes to disk for each directory change ("mv") or
file extension (part of the inode data). AdvFS will tell you that
it does this faster due to the transaction logging and maybe that's
true. You didn't say whether it's UFS or AdvFS file systems.
In either case, you need to shortcut the metadata updates. The classic
solution to this is hardware, something called "PrestoServe" which is
a battery backed up cache memory. There are other methods, but none of
them are easy to implement. There *might* be system tuning parameters
you can tweak to get deferred metadata updates, but that depends on the
release you are running.
LSM doesn't solve the problem unless you manage to stripe EVERYTHING
across the disks just right -- both data and metadata (and the data
is usually sitting in memory anyway until the UBC fills up and needs
to be pushed out to disk, especially if there's a lot of activity, it
is the METADATA that needs to be consistent on disk and that's what
is usually the bottleneck -- and you can't control to any extent where
it's going to be on the disks, and often it's going to be in one place
and never move). A hardware RAID controller that buffers the data and
reports I/O complete even though the data is still in it's own memory
would speed this up, as would buffering the data in the disks. All of
the speedup tends to come from getting I/O complete for metadata writes.
---end Dr. Blinn's response---
Thanks for your comments,
Kevin
Kevin Dea wrote:
>
> We have an application that performs many many small writes and moves to
> disk in single directories, which we need to speed up greatly. One
> thing that was suggested was to purchase several large 72.8GB disk and
> configure with LSM as a striped volume (about 200GB).
>
> Now realizing that this is somewhat of a software RAID, what are
> performance issues? Is it much worse than using a real RAID controller
> like a HGZ70 or HGZ80? We are aware of the lack of reliability in this
> and prepared to take that risk. Does anyone have better suggestions to
> fit our needs?
>
> --
> Kevin Dea
> UNIX System Administrator
> Alpine Electronics Research of America
--
Kevin Dea
UNIX System Administrator
Alpine Electronics Research of America
Received on Tue Oct 16 2001 - 00:28:18 NZDT