[lkml]   [2006]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CD writing in future Linux (stirring up a hornets' nest)
    >>>>> "Rob" == Rob Landley <> writes:

    Rob> Yup. Apparently with SAS, the controllers are far more likely to
    Rob> fail than the drives.

    While a single drive is more likely to fail when compared to a single
    controller, for a truly redundant system you want no single point of
    failure, which means redundant controllers is a requirement.

    >> Makes redundant systems much simpler to build if you can connect
    >> each physical drive to two places at once.

    Rob> Or you could use raid and get complete redundancy rather than two
    Rob> paths to the same single point of failure. Your choice.

    Excuse me? Think about what you just wrote here and what you're

    Of course you would use RAID here, along with two controllers and two
    paths to the single disk. But you'd also have multiple disks here as
    well. Not a single disk and two controllers and consider that

    >> They support port expanders (which SATA seems to be starting to
    >> support although more limited).

    Rob> I still don't see why drives are expected to be more reliable
    Rob> than controllers.

    He never said they were.

    Rob> I think the most paranoid setup I've seen was six disks holding
    Rob> two disks worth of information. A three way raid-5, mirrored.
    Rob> It could lose any three disks out of the group, and several 4
    Rob> disk combinations. If six SATA drives are cheaper than two SAS
    Rob> drives. (Yeah, the CRC calculation eats CPU and flushes your
    Rob> cache. So what?)

    And how many controllers could that setup lose? You need to think of
    the whole path, not just the disks at the ends, when you are planning
    for reliability (and performance as well).

    Also, with dual ports on a drive, it becomes much easier to build two
    machine clusters which both can see all the drives shared between the
    clusters. Just like SCSI (old, original 5MB/S scsi) where you changed
    hte ID of one of the initiators. Not done frequently, but certainly
    done alot with VMS/VAX clusters.

    Rob> I keep thinking there should be something more useful you could
    Rob> do than "hot spare" with extra disks in simple RAID 5, some way
    Rob> of dynamically scaling more parity info. But it's not an area I
    Rob> play in much...

    RAID6, or as NetApp calls it, Dual Parity. You can lose any TWO disks
    in a raid group and still be working. It covers to more common single
    disk fails, and then you still have full parity coverage if another
    disk fails during the re-build of the parity info onto the spare

    With 250Gb disks, that run a 50MB/S, it takes a LONG time to actually
    sweep though all the data and rebuild the parity. 24 hours or more.
    So to cover your butt, you'd like to have even more redundancy.

    I've run fully mirrored servers, where I had redundant paths to each
    disk from each controller. When I lost a controller, which certainly
    happened, I didn't lose any data, nor disk I lose mirroring either.
    Very nice.

    In the situtations where I only had one controller per set of disks,
    and mirrored between controlles, losing a controller meant I had to
    re-mirror things once they got running again, but I didn't lose data.
    Very nice.

    Building reliable disk storage is not cheap. Fast, reliable, cheap.
    Pick any two. :]

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-02-16 04:09    [W:0.025 / U:17.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site