On 16-02-01 12:19 PM, Tinker wrote:
My purpose with asking for SSD-accelerated HDD was DOUBLE:
1) I need some SSD storage but don't like that it could break
together - I mean, a bug in your system will feed your SSD at full
bandwidth for ~7h-7 days, it's completely fried - that's not OK, so
putting a "redundance layer" in the from of an underlying magnet
storage layer is really justified.
...so what? I don't understand what your concern is here. If you buy a
batch of HDDs from the same lot, they'll probably all die around the
same time, too. I don't think I understand what you're trying to say.
If you're worried about SSD write endurance, I'd say... don't. Or buy
better-quality SSDs ;-).
See http://ssdendurancetest.com/ for real-world stress-test data.
Especially
http://ssdendurancetest.com/ssd-endurance-test-report/Intel-SSD-520-60.
The Intel DC P3700 series should last about 1.5yrs in an absolutely
worst-case scenario. Even the worst-case DC series I could find should
still last about a month and a half under murderous stress-test conditions.
http://estimator.intel.com/ssdendurance/
This report
(http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead)
confirms that even if you completely fill an SSD, that's no big deal.
If your application has a "bug" it's unlikely the sort of bug that would
fill the entire SSD, erase it all, fill it again, erase it all again,
etc... and most SSDs can handle ~3000 full-device writes nowadays.
Also remember to factor in the fact that UFS/UFS2 doesn't (usually)
saturate a block device with I/O write requests. Maybe if it was just
writing to a single enormous file it might, but could that actually
happen in your situation?
2) I need some bulk storage, and I want the terabytes to be really
cheap so that i NEVER will run out of archival space. An 8TB magnet
HDD costs in the range USD 500.
Here, I like it to be stored "symmetrically" with how I store the
other stuff, that is having separate disks, directories, mount points
etc. for the two doesn't really appeal to me in this particular case -
Simply knowing that the less frequently accessed data will be
taken from magnet and the more frequently accessed data from SSD seems
both convenient and practical for my usecase, and, I'll try to have
SSD volume to cover for *MORE THAN ALL* of my frequently stored data.
Perhaps knowing the prioritization algorithm as to be able to
calculate more closely what's in the SSD and what's on the HDD only
would make some sense, BUT, training it by telling it what's to load
fast using "cat `find the-relevant-data/` > /dev/null" single-shot and
perhaps via crontab, should deliver really well.
Cheap storage is a valid argument. HDD vs SSD is still easily an order
of magnitude difference in price.
So go run FreeNAS (or TrueNAS, or Solaris, or FreeBSD, or even
Linux...), run ZFS with both a L2ARC and ZIL device on fast SSD, and
remote-mount the directory. You even have a choice of protocols :-).
(NFS or iSCSI. I suspect you'd want to use NFS, but YMMV.)
Short answer: I don't think any part of OpenBSD does what you're asking,
natively. Some supported hardware devices (like the MegaRAID Cachecade,
et al.) do this for you. But at that point, what's the difference
between having the disks hooked up to some speciality hardware in an
OpenBSD box, versus having the disks hooked up to generic, not-special
hardware on a non-OpenBSD box? (Particularly given that UFS/UFS2 on
OpenBSD isn't exactly known for its award-winning performance in the
first place?)
FYI, even if Intel SRT was available on a Xeon board, you'd still be out
of luck, because it requires device driver support - it relies on the
Intel fake-raid technology which, IIRC, is not supported at all under
OpenBSD.
I'd also like to see something like this available in OpenBSD's VFS
layer, but I'm not holding my breath.
IIRC there was some interest in integrating Hammer/Hammer2 into OpenBSD
instead of ZFS due to licensing issues, but even Hammer2 doesn't appear
to have tiered storage in its feature list.
Some more random thoughts:
- the Dell H800 supports up to 1GB NVRAM, which is just a CacheCade
implementation.
- CacheVault is the newer version of CacheCade (AFAICT), and is
supported on newer MegaRAID cards. See
http://www.avagotech.com/products/server-storage/raid-controllers/cache-protection#overview
for some pretty skimpy info.
- moving your data from HDD to SSD isn't going to dramatically speed up
READ operations. Carefully examine the specsheets on both the HDDs and
SSDs and compare read bandwidths. Access time (latency) is where SSDs
are useful, along with acting as write-back caches.
- Areca raid controllers support up to 8GB of cache and a sh*tload of
SAS ports; this might be good enough for your needs - have a look.
Either iSCSI or NFS against a ZFS-based NAS is probably still your best
bets for massive scale right now, sorry.
Obviously if you have money to burn, you can skip the ZFS part of that
and move straight to a hardware hybrid array, e.g., Equallogic, EMC,
NetApp, 3PAR, or whatever. But if that was the case you probably
wouldn't be asking the question in the first place.
-Adam
