Slashdot Mirror

At some point, the data on any writable disk is inconsistent, even with a journal system.

ZFS is copy-on-write, ie. it is not a journaled filesystem. It is transaction-based and atomic; it does not traverse an inconsistent state because it does not overwrite the data during a write.

but data can be lost, simply because data that hasn't been written to disk yet can't be if power is lost.

Right, no doubt you have deduced I am making a distinction between data inconsistency (corruption) and "lost writes". Note that because ZFS is a "rampant layering violation", lost writes cannot cause inconsistency/corruption of the filesystem itself (except in degenerate scenario 2 below).

The primary data "loss" scenarios for ZFS during power loss are:

1) File writes that haven't been flushed yet. Note that this does not lead to filesystem inconsistency, just lost writes. A battery-backed write cache won't fix this—if this scenario is a concern, then you really need a UPS for the machine and an orderly shutdown. That is to say, if pending asynchronous writes being flushed is a concern then you're probably also concerned about currently-executing application processes that may not be complete.

2) Hardware that lies/breaks spec and acks a synchronize-cache command when it hasn't really done so. This causes much rage in the ZFS developers, because there's no true fix for it besides suggest people not use substandard hardware. Note that this *can* cause ZFS to lose data. Would this scenario corrupt a system with battery-backed RAID write cache as well? The drive fraudulently swears it has flushed the data... would the controller double-check later by reading the data back in just to see if it was lying? Even if the controller did try to check, how would it know that the drive wasn't responding from its own cache?

This is where battery-backed cache can help, as the OS thinks it has been written, but it hasn't yet.

I presume you are referring to enabling write caching on your controller, and asserting it is safe to do so due to the battery-backed cache.

I specced an IBM System x3650 M3 with a similar system for a production PostgreSQL server. God, I loved that machine... you could even make a 96 core/1 TB RAM Voltron-like single logical machine by plugging four of them together. Anyway, the intention of the cache was to be able to safely disable fsync() in PG without risk of data corruption. The IBM system took it one step further: the battery-backed cache had the ability to be transferred to another x3650 and replay the cache on the other machine in case of catastrophic failure. Anyway, I never bothered to enable the feature because we never became I/O bound on writes with fsync() enabled while I was there. It did give us headroom, though.

Anyway, the obvious perf advantage is to allow the hardware to lie and assert sync has happened even though it hasn't yet.

On my home ZFS array I have a allocated part of my OCZ Vertex 4 SSD for my RAID zpool's ZIL, which serves a similar acceleration function for synchronous writes (only). The ZIL acts like a protected write cache, but only in the case of power failure. Essentially, the in-RAM ZFS pending write cache is mirrored to the ZIL device(s) (if you have them). If the ZIL device acks a sync of the ZFS cache data written to it, then ZFS counts the overall write to the destination volume as complete (because the transactions are now replayable if power is lost) and therefore allows the OS sync() to return.

Also note that I misspoke, because the Adaptec 5805Z that I have uses a capacitor, not a battery.

By design, the ZIL is never read unless there is a power-failure. The Vertex 4 is supposed to have supercaps to ensure flush, but given

Haha, fair enough. I suppose my rejoinder would be that with RAID-Z my data on the array is never in an inconsistent state while writing, so I don't have to worry about obtaining a battery-backed cache or a UPS and then ensuring the batteries are still good after a few years.

At some point, the data on any writable disk is inconsistent, even with a journal system. It may not be irrecoverably inconsistent, but data can be lost, simply because data that hasn't been written to disk yet can't be if power is lost. This is where battery-backed cache can help, as the OS thinks it has been written, but it hasn't yet.

Also note that I misspoke, because the Adaptec 5805Z that I have uses a capacitor, not a battery. This, along with the flash, essentially means that it's a zero-maintenance system for far longer than the useful life of the card. The flash only gets written when power is removed and has 800% over-provisioning, so there's not much worry about write-endurance.

As for a UPS, it's worth it just to avoid other hardware issues that can happen when bad power hits the computer. The CyberPower UPS I use has a three-year warranty that includes the batteries failing to hold a charge. The batteries are about 25% (at wholesale) of the cost of the UPS, so they wouldn't want to pay out on too many of those.

Hardware was always better supported on *n*x.

I totally disagree. Yes, a few raid controllers work well, like Adaptec Cards, which have for a long time been quite active in making sure that their cards run nicely (which is one of the reasons the last few I have used at home have been such - I take my home media center VERY seriously), but overall, hardware support is much better on Windows.

Actually, this is an excellent example. The card I recently upgraded to is a 6805 which gives me a lovely Raid5 and I have 7 3TB drives running in it. Now, I popped the card in, flicked on the PC and followed the quick setup instructions to get into the controller card just after the bios ticked over. It let me add the drives into the raid and set it up correctly. I then loaded up into my desktop, fumbled around for a while to get the additional StorMan software installed (so that I could actually do anything useful with the new Raid). While Adaptec said the offer Ubuntu support (oh, Natty (11.04 is around a year old now) is still their newest supported version), it takes some serious mucking around to get it to run. Their version of "support" means offering a .rpm file, which well isn't something that you can just install. So, I flipped into a terminal to convert it with Alien. Unsurprisingly, there were packages missing, so that needed fixing. After some kung fu, I finally got it running. Now, to do anything useful in this software, you need to log in as root. Of course Ubuntu has root disabled by default (The lovely "Pretend Root" doesn't cut the mustard), so flip back into terminal, enable root account, use the Storman software to set everything up as needed, then disable the root account in terminal again.

Now, it works, and I do like Linux for a number of reasons, but I must say that for the average joe, doing all of that would have likely resulted in a trip back to the store to return the product. I am not going to start on stories about graphics cards, flash performance, printers or all the other hardware gripes that we have.

I prefer to use this simple description of hardware support in *nix Vs Windows: I can do it in *nix, but I can guide my parents over the phone to do it in Windows. I love Linux, but I have to admit that in terms of "Plug and Play" windows does it better to a "non admin user" which is what I would consider most of the world.

Adaptec has a new technology called Hybrid RAID, which uses 50% SSD/50% HDD in RAID 1 or RAID 10. Reads are serviced by the SSD(s) only. It seems to me you might need to short-stroke the HDD in order to make this a reasonable approach.

Their new 6E series is very inexpensive for 6Gb SAS cached (128MB) hardware RAID; 6805E is (8 int. ports) is about $225 retail:
https://www.adaptec.com/en-us/products/controllers/hardware/sas/entry/sas-6805e

I'm no shill or fanboy; I just found this interesting and relevant.

* Sorry, "Adaptec", not "Adapter"
http://www.adaptec.com/en-US/products/Controllers/Hardware

They actually have only 2-3 such boards, so we're not there yet. You don't need SSD disks for the caching, the cache is on board, but I just checked, it's a ridiculous 4GB for an extra $330 compared to the non-SSD cache model. So it's more like $83/GB.

4GB is what you get on hybrid SATA/SSD disks, so I guess it is not adequate for a RAID controller that can handle 256 disks.

I've read some people are starting to mix SATA and SSD: SATA arrays for backups, documents storage, etc., and SSD arrays for high IOpS data such as database read/write transactions.

Since SAS and SSD disks are basically the same price, $1.2/GB for SAS and $1.4/GB for SSD, with SSD prices dropping continuously, no mechanical parts, pure NAND memory speed, mixing SATA and SSD arrays makes sense, and you can drop global storage prices a lot with the SATA arrays.

Still, the lack of SATA III controllers, the small size of the SSD cache, and the few glitches with SSD drives after many write operations would make me wait until these issues are resolved.

SAS is doomed!

As much as I would agree with you on futility of chaining controllers (does not solve the problem in the question), I was referring to standalone controller cards which function in addition to whatever logic comes with the drive. These type of standalone controllers are very much produced today, e.g. by Adaptec:

http://www.adaptec.com/en-US/products/

You mean, kind of like this?

Viking Arxcis-NV

And:

Adaptec RAID 5805Z

Looks like all the Adaptec 5Z series cards have the "battery less" RAM->flash backup feature.

All of my server deployments are on Linux, and after suffering for many years with awful Linux drivers from Adaptec I just gave up on them altogether some time ago (around 2002 I banned them altogether from my systems). It looks like they may have recently released products that work OK with that operating system, judging from things like Smartmontools and Adaptec RAID controllers where controllers that have basic SMART support are mentioned as finally available. From the perspective of a Linux admin, I would dispute that Adaptec has been "the way to go for the last 20 years"--there's at least a 5 year period there where Adaptec's Linux drivers were so awful that you had to use alternate vendors like 3ware if you wanted good support.

OpenBSD confirms it. Adaptec is dying.

While it's certainly not low budget, I still saved a bundle by not going with an enterprise class solution. I have a little money to burn so here's what I got:

10x 200GB Seagate SATA 7200.7 Barracudas (RAID 50)
2x SuperMicro 5-Drive Hot Swap SATA Backplanes
2x 80GB Seagate SATA 7200.7 Barracudas (RAID 1 for OS)
Adaptec 21610SA 16-Port RAID Controller

I use FC4 Samba and NFS for shares to clients.

Seriously, this is the company which sells a £50 dual port SATA card based on the same SiI chipset you find in £5 cards; that same chipset widely regarded as being one of the buggiest controllers in common use today. I shudder to think what they fit behind their proper SATA RAID controllers.

Well, serial attached scsi started to ship

http://www.adaptec.com/sas/index.html?source=home_ story1a_SAS_technology_home

Pro level already moving but I suspect it will be OK for home with enterprise features it offers.

I checked a bit you know ;)

Do you mean something like this?

Recently a client had a drive fail in a RAID 5 configuration on a Dell server. You know the theory: pull the drive, replace it, watch RAID rebuild. However, that was not the situation. The RAID had quitely become corrupted. Subsequently I discovered from OnTrack that is not as uncommon as one might think. Running RAID 5 on our computers in the office ourselves, I became concerned about this and looked into it further. Luckily, we run Adaptec RAID controllers, Adaptec's RAID controllers (including Zero Channel) have the ability to verify the RAID integrity and repair it. I don't know which other controllers have this ability, but it can be a lifesaver. We run the utility once a month.

Accelerating Ethernet in hardware, while remaining 100% compatible with the standard protocols on the wire, isn't all that new. Just over 2 years ago, I worked on a TOE (TCP offload engine) card at Adaptec.

http://www.adaptec.com/worldwide/product/prodfamil ymatrix.html?cat=%2fTechnology%2fNAC+Cards%2fNAC+C ards

It was a complete TCP stack in hardware (with the exception of startup/teardown, which still was intentionally done in software, for purposes of security/accounting).

Once the TCP connection was established, the packets were completely handled in hardware, and the resulting TCP payload data was DMA'ed directly to the application's memory when a read request was made. Same thing in the other direction, for a write request. Very fast!

I'm not sure of the exact numbers but we reduced CPU utilization to around 10%-20% of what it was under a non-accelerated card, and were able to saturate the wire in both directions using only a 1.0Ghz CPU. This is something that was difficult to do, given the common rule of thumb that you need 1Mhz of CPU speed to handle every 1Mbit of data on the wire.

To make a long story short, it didn't sell, and I (among many others) was laid off.

The reason was mostly about price/performance: who would pay that much for just a gigabit ethernet card? The money that was spent on a TOE-accelerated network card would be better spent on a faster CPU in general, or a more specialized interconnect such as InfiniBand.

When 10Gb Ethernet becomes a reality, we will once again need TOE-accelerated network cards (since there are no 10GHz CPU's today, as we seem to have hit a wall at around 4Ghz). I'd keep my eye on Chelsio: of the Ethernet TOE vendors still standing, they seem to have a good product.

BTW, did you know that 10Gb Ethernet is basically "InfiniBand lite"? Take InfiniBand, drop the special upper-layer protocols so that it's just raw packets on the wire, treat that with the same semantics as Ethernet, and you have 10GbE. I can predict that Ethernet and InfiniBand will conceptually merge, sometime in the future. Maybe Ethernet will become a subset of InfiniBand, like SATA is a subset of SAS....

Under standard PCI the host bus has a maximum speed of 66 MHz. This allows for a maximum transfer rate of 533 MB/sec across a 64-bit PCI bus.

What flavor Kool-Aid are you drinking?

I don't think you can find (easily at least) Kool-Aid over this side of the atlantic, and from what I hear it's rather disgusting anyway. Ie, I don't drink any flavour.

Hardware manufacturers will be highly unlikely to even care about Solaris on x86 because it has a market share that is a rounding fo OS/2 let alone Linux.

Gosh, good point. I hadn't realised that no hardware
vendors provided Solaris drivers. Thanks for pointing that out. (And thats just a small sample). Further, some code included with Solaris is provided by ISVs and could not be GPLed.

Sun is simply using fear of GPL to hide the fact they sat on their butts when the battle for market share was being waged.

Sun are not afraid of the GPL, as I explained above, the GPL just wasn't right for opening Solaris, for practical reasons. If Sun were afraid of the GPL then why would Sun have spent so much engineer resources on getting GNOME into shape to replace CDE on Solaris? Why would Sun have LGPLed OpenOffice? Why would I be working on a GPL project?

Great idea! We can dedicate chips to graphics coprocessing, sound tasks, network relating things, input/output. I hope they build this soon!

SCSI, in its current form, is just opening itself up to becoming antiquated.

Perhaps, though personally I've had far more trouble getting SATA (and IDE) drives to work than SCSI drives and I've used both extensively. Driver issues mostly. SCSI's performance is better in multi-user systems, it's easy to set up, drivers tend to be less problematic especially on systems other than Windows, and it can have more devices attached. People claim it's more reliable though I have no evidence of this, and frankly am a bit dubious of the claim. SATA is also easy to set up and is a lot cheaper, though the drivers are still less ubiquitous than with SCSI and performance doesn't match SCSI yet for multi-user systems. (on a single user system it doesn't matter much)

That said, the next generation of SCSI is Serial Attached SCSI which is compatible with SATA. A SAS controller will be able to use SATA drives if you don't need the extra features of SAS. SCSI isn't going away, it's just adapting.

Yes and see also this Adaptec product which seems to have been doing TCP/IP offloading for over a year.

There's two popular RAID cards for the PC. I'm most interested in Raid-5 because the obvious cost-per-gig savings vs. mirror (raid-1) solutions.

1. httP;//www.3Ware.com
2. http://adaptec.com/

The 3ware is quite popular, but the adaptec wins in my book because it will do several things the 3ware one will not:

a. On-line expansion: the ability to expand your array without backing up the data to another location, reconfiguring the array, and reloading the data.
b. Differently sized disks: if I have 2 disks of different sizes, the 3ware one will only do RAID1 with a total size of the smaller of them; likewise with raid-5.

Just some ideas for you...
-- Kevin

Including the RAID5 performance hit for losing the redundant drive? That calls for an immediate system maintenance just to get the server back to normal performance, not just waiting for the next normal maintenance. And are you really going to let your RAID array sit on a failed drive hoping that you don't lose another any time soon? That's just friggin sloppy. It happens and that's why many server vendors are now moving to double-parity systems.

Sorry, taking the server down for any reason at all is just not acceptable. Letting the server limp along is not acceptable. Five 9's means you've got five minutes per year of downtime, and I sure as shit follow that rule.

OK, someone else mentioned that you aren't losing 80GB of data, just access to 80GB of storage, since you are hopefully going to have other cubes around to do a RAID rebuild onto. Not guaranteed, but that's true for any system. In this case you still have 80GB of data that you need to tear the cube apart to get to, and that's still a stupid design.

Hmmm this must be an important topic since this was on ask slashdot where the Adaptec VideOh! DVD Media Center USB 2.0 or the AVerMedia UltraTV USB 300 where mentioned.

rely on /. to repeat "important" hardware.... 8-)

the tv wonder was NOT recommanded by a lot of readers, but this might be the usb 1.1 tv-wonder that simply does not have enough bandtwith to the computer.

I've been looking at one of these for when I build my next server:

Adaptec 2410SA + Enclosure Kit

For $600 MSRP you get an Adaptec 2410SA 4-channel SATA RAID controller (does RAID levels 0, 1, 5, 10, and JBOD), a 4-drive enclosure with hot-swap sleds, cables, and your choice of beige or black. The only thing you don't get are the drives themselves. The 4-drive enclosure takes up 3 full-height drive bays. Note: make sure you have enough 12v current from your power supply -- I'm not sure if the enclosure staggers the spinup.

Chip H.

An ideal solution, although it's somewhat expensive, is to do SATA RAID. Adaptec has a controller card that is excellent for this and runs about $330. Then you'll need some SATA hard drives. The card can do RAID-0, RAID-1, RAID-5, and RAID-10, so you still have flexibility that way. If you can afford it, do it.

PC Pitstop
Cooldrives.com
Adaptec (DuraStor line... a bit beyond your stated price range, though)

Hope this helps!

after posting some hardware sugs, i forgot about the driver issue:most of the newest 64bit driver work from the
major manufacturers appear to be for Windows(ech). ( Here's a review that came out today.)

The latest Linux drivers from nvidia aren't too old; their last nForce3 update was in Dec 2003 and the gpu drivers in Jan 2004

Tyan have a page of drivers, as does Highpoint, and Adaptec

Look into the suse amd64 message boards - they seem to be having some success...

The performance we get with Promise controllers (when they work) has been satisfactory. The application is a cash register; the computer is always faster than the operator. We only need a mirror copy of our data.

3Ware told me they cannot boot from one drive, after one fails. A 3ware formatted drive cannot boot from the IDE controller on the motherboard. Promise can do both. We need features, not performance, in this case.

Do you have a link to an Adaptec IDE mirroring RAID controller you would recommend?

The Adaptec ATA RAID 1200A is about $55, about $30 less than the price of the Promise controllers. We have no experience with them; I found the info by Googling and Froogling.

Depends on the windows API? It does depend on having a valid ASPI layer, but it doesn't have to be the default windows one. I'm not entirely sure, but you may have some success getting/using the Adaptec one from here.

Maybe you should buy better hubs. Perhaps this one from Adaptec with a 5 Amp power supply would do the trick. And, look, it even has a cute widdle picture frame built into it. *boggle*

Peter

Apple hardware is closed to third party vendors?

I guess that means there are no Mac CPU upgrades from third party vendors... no disk controller cards from third party vendors... no thriving market in third-party optical and hard drives... and I'm sure Apple keeps a lock on the hardware so you can't install Linux or BSD. Yeah, Microsoft would just be doing what Apple do.

Or maybe you're full of it.

You are quite wrong on this point. VGA cards and SCSI cards need an onboard BIOS to be able to boot from. The x86 cards will not work on a PPC platform. Period.

Really? That will come as a shock to Adaptec, who have been selling SCSI cards that support PCs and Macs for years now. (Admittedly I've never personally tried to boot from one, but the product detail page makes no mention of any such restriction.)

Video cards are in general stickier, but not entirely: several manufacturer's flavors of GeForce 2MX will work perfectly well in both Macs and PCs, and I believe the same goes for the Radeon 7500. Not entirely sure about later-generation cards.

Here are some answers/clarifycations on some stuff I've already seen in the coments here:

iSCSI is a SAN (Storage Area Network) replacement. It is not a file shareing system like Samba or NFS. The primary advantage of iSCSI over something like Fiber Channel is cost. You can build an iSCSI system with regular Ethernet switches where as Fiber Channel requires "special" switches and cableing. I would think that two systems could use the same iSCSI target, but only where it would make sense and where the file system could handle such access.

Yes, there are already are adapters. (Not quite sure how they are out ahead of the spec, but why would you let a little thing like that slow you down). They connect to the Ethernet switch (usually a gigabit switch) and therefor could boot off a volume via iSCSI.

Cisco also makes a device that can bridge lagacy SAN networks to iSCSI

You are right. iSCSI will be used over LAN and WAN links. Hopefully this will be done in a way that is tunneled and secure, similar to how a VPN works today. Allowing outside users to arbitrarily inject packets into a SAN network would be a Bad Thing.

A good application of iSCSI over a remote link is to bridge multiple iSCSI SAN networks together. This combines storage devices in multiple locations into one logical network. This would be useful for applications such as remote backup, mirroring, database replication, and so on.


http://www.adaptec.com/worldwide/product/markedi to rial.html?sess=no&prodkey=ipstorage_sra_asic&type= Common&cat=/Common/IP+Storage


It is also useful as an interconnect for bridging multiple Fibre Channel SAN networks together, and translating between iSCSI and Fibre Channel.

http://www.adaptec.com/worldwide/common/index.ht ml ?prodkey=ipstorage_index1


iSCSI is useful as an interconnect in a SAN environment. The storage devices exist as their own node on the network, independently of the computers they are attached to. This is good for reliability (can replace the disk independently of the computer if it fails, and vice versa), configuration flexibility, and many other useful things.

iSCSI is nice because it uses standards that are well understood (Ethernet, TCP/IP) instead of custom networks like Fibre Channel. This should make SAN networks cheaper and more common, as well as providing an easy way to bridge a SAN network over the Internet (firewalled and encrypted, of course).

The only difference between a LAN and a SAN will be what you use it for!

I should have been more clear. Adaptec's on-board "zero channel" SCSI raid is a true hardware raid solution. I'm not talking about promise and highpoint stuff.

Details here

-ted

Have you even tried getting on the phone and calling their documentation department?

Yes. As I mentioned in my post, they just asked for a product serial number and it went no further.

In the past I've found no register level docs on the web site, but was able to get paper copies w/o much hassle by calling them and ordering it.

Sorry, that's just not good enough, especially considering the above brick wall. If they want their chip properly supported, they should just post the the docs on their web site.

The driver is full source, even source for the sequencer on the chip. Most other vendors don't go to that level of source code availaibilty.

Most vendors give a binary blob to load onto the card for the on-board sequencer.

Many other vendors have similar or worse mental deficiencies, it's true, however there's no safety in numbers here. There used to be lots of dodos as well.

In short, I don't think that you have the first clue what you are talking about here.

Give me a break. Go look for yourself.

Have you even tried getting on the phone and calling their documentation department?

Yes. As I mentioned in my post, they just asked for a product serial number and it went no further.

In the past I've found no register level docs on the web site, but was able to get paper copies w/o much hassle by calling them and ordering it.

Sorry, that's just not good enough, especially considering the above brick wall. If they want their chip properly supported, they should just post the the docs on their web site.

The driver is full source, even source for the sequencer on the chip. Most other vendors don't go to that level of source code availaibilty.

Most vendors give a binary blob to load onto the card for the on-board sequencer.

Many other vendors have similar or worse mental deficiencies, it's true, however there's no safety in numbers here. There used to be lots of dodos as well.

In short, I don't think that you have the first clue what you are talking about here.

Give me a break. Go look for yourself.

I have a similar problem with Adaptec. I'm trying to get register-level specs for their AIC-7xxx series of scsi chips.
On their Linux page they claim to support open source:

We have launched a dedicated Web site to provide a repository of
information for our open source solutions, including:

* Our latest Open Source drivers
* Technical documentation
* White papers
* FAQs

But in fact there is no technical documentation available beyond lightweight lists lists of features and general hardware type. Directly contacting Adaptec, I get nowhere without a product serial number, which of course I don't have because the chips are embedded in an OEM motherboard.

So maybe I'm just not talking to the right person, but it does look like the company is saying one thing and doing another.

To be fair, the driver support for Linux is good. Drivers are developed by an Adaptec-sponsored group and provided in source form. These drivers are in the mainline 2.4 and 2.5 source trees. This is a far better performance than, for example, NVidia, whose drivers are well-known for breaking every few kernel releases because of their binary-only nature. Still, it's not enough. It seems to me Adaptec is just shooting themselves in the foot by keeping the low level interface specs closed. If they continue to do that, they will certainly be knocked out of the market by other hardware that's better understood by kernel hackers, for which both low and high level optimization can be done by lots of developers. That's exactly what I'm trying to do with their chips, and to be frank, I'm doing it only because I happen to have one available to play with at the moment. But I'll move on without hesitation as soon as something shows up that gives me more scope for interesting optimizations. I'm just not one of those people who enjoys reverse-engineering, though I have immense respect for those who do.

The way things are, the Adaptec guys who develop the Linux drivers can do plenty of low level optimization based on things that only they know about the hardware, but who will listen to them if they want changes in the core kernel for better support? Plus, who wants to invest in hardware that is certain to become unsupportable as soon as the company EOLs the product? With Linux basically taking over the server market, I see that policy as the most efficient way to become part of the sedimentary fossil record as soon as possible.

But this is probably Adaptec's fault, since they label RAID 1+0 and RAID 0+1 opposite from standard convention.

I connect different power supply lines to each of the mirrors' halves, so that one half of each mirror is powered by one line, and the other half is supplied by another line.

If a power supply fails only partially, it usually does so on one of the peripheral power lines. With the right power supply wiring, and the 2400A set up in RAID 1+0 mode, a power supply failure will not usually result in any lost data, since it will be isolated to one half of each mirror.

Power supplies have been failing on me more often than drives have lately, even when they are used well within their rated limits.

Don't power both drives of a mirror with the same peripheral power cable!!! On many power suppplies, those separate peripheral power connector lines are on separate circuits, which means one may fail while the other doesn't. It's best to spread the chances of failure out as evenly as possible across the RAID.

Two-channel IDE RAID cannot support RAID 1+0, only RAID 0+1. Four IDE channels are necessary for RAID 1+0 to be effective, because if one drive fails in a two-channel configuration, the other drive sharing the same channel can stop working too, especially if the failing drive was the master.

Adaptec also offers open-source drivers for the 2400A, while the article neglects to mention that, and in doing so implies that only 3ware and HighPoint do.

Also, the article's table has read/write speeds of the Promise FastTrak shown backwards (133 vs 100).

Nonethless, the article's comments about the 2400A's slow rebuild time are accurate. It takes around 8 hours to rebuild my 120 GB 1+0 RAID (four 60 GB 7200 RPM drives).

And keep in mind that the 2400A is a SCSI RAID solution retrofitted onto an IDE interface -- some of the 2400A's firmware is shared with Adaptec's SCSI RAID firmware. So the 2400A is not really built or optimized for IDE from the ground up.

But if you need RAID 1+0 or RAID 5 data protection, and you have 4 inexpensive IDE drives to use, the 2400A is nice. It's twice saved me from losing any data. Don't expect blazing-fast performance, though -- just consistently good performance, very low CPU usage, and very strong reliability.

• 39320D-R
• 39320-R
• 29320-R
• 29320LP-R

• 39320D-R
• 39320-R
• 29320-R
• 29320LP-R

• 39320D-R
• 39320-R
• 29320-R
• 29320LP-R

• 39320D-R
• 39320-R
• 29320-R
• 29320LP-R

There is a certain elegance to such things as SCA backplanes which ATA (in any incarnation) will never achieve.

Which is another point:

They botched SATA by not including power on the bus, having no standardized connector locations, and (at least so far) having no facility for connection of external devices.

The 1-device-per-wire rule of SATA is another detriment: Sure, the cables are fairly small, but can you imagine the rats nest that would be a 12-device SATA system?

SCSI daisychaining is an easy fix for that, and now-common LVD SCSI is quite able to support this number of devices with a single ribbon. And LVD, by its differential nature, is quite resistant to the electrical problems introduced by slice-and-jacket cable rounding techniques that are all the rage these days..

Oh. And you've got your math wrong, Son:

It doesn't matter if 3ware makes a controller with 12 150MBps ports. The 12-port Escalade 8500 you speak of has a 64-bit 33MHz PCI interface, topping out at no more than a paltry 264MBps to be shared by all connected devices.

If you're serious about throughput, try something like this: Two 320MBps channels on a 64-bit, 133MHz PCI bus. Good for real-world transfer rates in the realm of 640MBps, more than twice that of the 3ware product, while keeping a good portion of the PCI bus free the -other- 30 SCSI devices you've got plugged into it.

And none of this says anything about the benefit of SCSI for the home user:

Just bought a new DVD-R, but don't want to toss your old but dead-solid Plextor? SATA requires you to buy another port. SCSI just requires you to plug it in.

Nevertheless, when it comes to hard drives, the basic performance of the drive itself will be a limiting factor. I doubt your IDE drive will suddenly get a boost in performance, though it would be neat to see some Bonnie++ results to confirm this.

As for the SCSI controller, does anyone have any experience with these? Its a fair bit cheaper than the equivalent Adaptec model. After putting SCSI in my Linux workstation at work, I'm hooked on it: what's not to like about cutting compile times by 50%? Maybe I could get SCSI at home if this controller is the real deal.

That POS $9 firewire card won't support OHCI due to a low-value ancient chipset so you can say hello to hellish proprietary windows-only drivers and flaky-at-best linux support. And I'm willing to bet it won't support an internal power connection so you won't be able to recharge the iPod through via power through the firewire cord. And good luck getting any modern-day DV cam connected to it.

You have to spend some good money to get a good firewire card. I am leaning toward the Adaptec DuoConnect because it has Firewire, USB 2.0, Internal connectors for those interfaces and PSU supplied power. (Cost: CDN$132)

Now, those 28 drives will need to be attached to something. Maybe an Adaptec SCSI RAID 5400S, which is a four channel card that can accept up to 60 drives and is priced at about $900. Add to that a machine to put the RAID card in with at least GB ethernet, at around $6000, 3 40U racks at $2000 each and a UPS for each rack at $2500 each.

All told, that's $67,200 each for drives and arrays, $900 for the SCSI RAID, $6000 for a single box, $6000 for racks, $7500 for UPS's, at a sum total of $154,800 for a single 50TB array. Primary point of failure is the single box running it. For a backup system, running a full second array as redundancy would cost a net $309,600. All of this is not inclusive of labor, which for setup might run easily $100k. Thus, a redundant reliable RAID solution would run you $400,000. All that's once the 320GB IDE drive is released by maxtor.

Does that answer your question?

Please note, this won't be the best array money can buy, just a large array on the cheap. (what RAID was intended for)

Look, all you clowns keep on saying, "In 1999, Adaptec snubbed Linux. Therefore, they suck!" For you're information, it's now 2002, and Adaptec is not snubbing Linux. Here is a good place to look. Adaptec writes all of it's drivers in house (with the exception of the aacraid driver, it's been a joint effort with RedHat) and gives them official support. We participate in the mailing lists and work closely with the vendors. We feed bugfixes back to the community, even when they aren't for our code. We have a public presence and respond to everyone who emails us. About the only thing we don't do is tape a $100 bill to all of our products and ship them for free to you.