[Gllug] Battery-backed SAS controllers

[Andy Smith]

Hi James,

On Tue, Dec 15, 2009 at 05:53:03PM +0000, James Hawtin wrote:
> On Tue, Dec 15, 2009 at 01:31:38PM +0000, Peter Corlett wrote:
> > Battery-backed JBOD isn't *that* odd a requirement. ZFS is more robust  
> > than hardware RAID, so there's little need to have (and pay for) the  
> > extra complexity. Controller manufacturers seem to be missing a trick  
> > here.
> 
> Perhaps... can you set drive timeouts for non responsing devices?

Don't know about this one.  I know there are various "RAID edition"
SATA drives that are supposed to give up sooner, not sure if it
matters on SAS/SCSI.

> Anything but mirroring is a nightmare on non hardware based system
> as they may require alot more reading to keep the parity in sync.
> 
> For an N+1 raid system you need up to N-1 reads and 2 writes for every one
> real write, all that additional IO is going though your computers
> kernel.... Bad!

In most cases software RAID and similar schemes outperform hardware
RAID.  The algorithms are known, the processors in servers are
faster even while doing other things than the dedicated ones in RAID
cards.  The only performance issue is bus speed; yes there's extra
traffic going over the bus, if that's going to be your bottle neck
then fair enough but for most people it isn't.

Software RAID doesn't always mean parity, neither does ZFS always
mean parity.  They do mirroring too, if you want.

> Does ZFS do pre-emptive reads checks for failure? My hardware system does,
> so ZFS check the status of drives (smart etc), for drives getting to the end
> of their service life, and pre-emptively move the data to another drive
> before failure, So no parity rebuild is required? My hardware system does!

ZFS has checksums to detect all of this.  There's some up-and-coming
Linux filesystems that will too (e.g.  btrfs).  Even existing Linux
software RAID can do a consistency check and overwrite unreadable
sectors with good copies.

You can do SMART checks if you like (the disks are JBOD so nothing
stopping you talking to them); I probably wouldn't bother though
until a drive actually showed problems.  I believe there is a Google
paper that mentions the limited usefulness of SMART as a predictor
of drive failure.

Basically clever filesystems that feature extent-based storage,
checksums, snapshots, online resizing, online fsck, compression,
de-duplication etc. are on their way to making hardware RAID
obsolete, so I have to agree with Peter that the controller
manufacturers are missing a trick in not selling battery-backed
cache on its own.

However until I can afford to virtualise the storage to put the
battery-backed cache in just one place, it seems I am stuck buying
multiple RAID cards just for the cache. :(

Total data loss due to RAID card failure really happens, restore
from backup then isn't pretty (especially when some data belongs to
other people who needed to pay for backups, and they didn't).

Cheers,
Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20091216/b8d1cf87/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug