Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: High performance random-access disk operations (Raidframe?)



On Sat, 15 May 2010 21:17:01 -0400
Chris Ross <cross+netbsd%distal.com@localhost> wrote:

>    Well, there are a lot of issues here.  (1) RAID 1+0 requires 4  
> disks  (right?).  Not necessarily a problem, but worth noting.  (2) I  
> don't actually care about the data, so the cost of the "RAID 1" part  
> is a waste.  (3) As it turns out, the filesystems I was originally  
> looking at combining *aren't* t he same size, which is unsupported by  
> RAIDframe anyway.
> 
>    So, I'm working with ccd(4) at the moment.  We'll see how that works.

Indeed, at least two per unit for redundancy, and at least two units to
benefit from stripping.  Even if the data isn't that important, is
uptime important?  Because there would be minimal downtime with RAID 1
and spares in the case of a hardware failure.

Some other tips to enhance random read/query performance, depending on
your application:

If the data set is small enough to fit in RAM and can be volatile (and
initial reading to RAM isn't prohibitive), by all means use RAM if
possible.  If you can't control the storage format or software, an
in-memory FS could be used...

If you have control over the storage format and software, also consider
using mmap(2), where pages will initially get loaded on demand but will
remain in the cache if there's enough RAM, with madvise(2) used to set
the region MADV_RANDOM.  This is lighter for random access than using
lseek(2)+read(2) syscalls (if the media is slow, this might appear of
small benefit, but with decent RAM the cache will greatly contribute to
performance with uptime as previous sets are queried again).  The
stripping would enhance performance of uncached sets.

Even if not using mmap(2), the buffer cache will greatly enhance
performance for frequently queried sets, and the cache will remember as
much as it can as RAM is available, so the more RAM, the better.
Unfortunately, RAM is not free, admitedly.
-- 
Matt


Home | Main Index | Thread Index | Old Index