[ale] [semi OT] encouraging and discouraging HDD and SSD observations

[Ed Cashin]

On Fri, Nov 1, 2013 at 8:18 AM, Michael B. Trausch <mbt at naunetcorp.com>wrote:

>  On 11/01/2013 08:06 AM, Phil Turmel wrote:
>
> That's probably a reference to "bcache", a new persistent block device
> cache for linux.  I don't know if there's any initramfs support for
> assembly yet, but you could roll your own.  That'd do what you're thinking.
>
>
> Sounds like a nice thing to try.  I might want to do that, actually, given
> my workflow and large storage requirements.
>
> I have 2 TB of data on my regular workstation; however, on any given day I
> don't access even 10% of it, and in any given week I probably been work on
> one to three projects that are relatively "small" (relative to the size of
> a 100GB SSD, that is).
>
> Thanks for the pointer, there, and I'm totally going to look into that.
>

Not to discourage you, but that's "bleeding edge" technology.  It's very
cool, though, and Kent Overstreet (bcache guy) has been getting some
traction (some positive comments, anyway) in getting large, invasive patch
sets accepted by the maintainer of the Linux kernel block subsystem, Jens
Axboe.

The reason for caution is that this is difficult technology to get right,
 The L2 ARC in ZFS seems to be the culprit in a disproportionately large
number of the most debilitating bugs, and Jeff Bonwick and friends are no
dummies, so I suppose bache might be prone to similar difficulties.  The L2
ARC is a read-only cache; the slog ZIL is a write cache on SSDs and is a
different part of ZFS; but the bcache is both a read and a write cache.

-- 
  Ed Cashin <ecashin at noserose.net>
  http://noserose.net/e/
  http://www.coraid.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20131101/759b6a5e/attachment.html>