Slashdot Mirror

kernel hacker guide to git, git tutorial git bisect manpage, git bisect example.

... to say that software RAID is almost invariably a poor solution. It is woefully slow compared to even a slow hardware RAID implementation.

Please cure your ignorance here.

Or simply test some systems before you talk nonsense.

Spend a few bucks and get the right hardware. It is not expensive these days.

Are you selling raid controllers or are you one who actually believe their marketing bullshit?

I can't speak for your config. Mine is obviously different, cheap parts on my side. The only name brand anything are the Seagate disks.

Sustained single disk speeds are around 12Mbps. Using RAID, you can increase that a little depending on the width of your array and the amount of disk cache RAM you have available.

My SMB server is a Ubuntu 6.xx LTS desktop. It runs all sorts of other processes, but also has an external RAID5 array (4x320GB) connected via infiniband. The network is 1GB switched.

I use Linux software RAID, not hardware RAID due to driver issues with my cheap Promise RAID card and the added flexibility it provides. Here's an excellent article for why using software RAID is a good idea http://linux.yyz.us/why-software-raid.html

The server has only 2GB of RAM. Most of the RAM goes towards disk buffering - no tuning needed. I backup via rsync over ssh about 10GB of data every morning. 50Mbps throughput until the buffer gets filled, then it is limited by the disk performance on the source systems, usually around 12Mbps. Using network testing tools, I was able to see 550+Mbps throughput for pure network tests between Ubuntu clients and servers, so the network isn't an issue. WinXP client throughput was only slightly less over samba. I run WinXP in a Vbox VM under Vista, so that isn't really fair.

There are, in fact, when it does work, you may just see one drive, though you'll probably need to use a setup disk/utility if it doesn't default to something. Numerous people get compaq/hp proliants with scsi raid cards to work.

You might like this, it doesn't just apply to SATA.

http://linux.yyz.us/sata/faq-sata-raid.html

http://developer.skolelinux.no/info/prosjektet/del prosjekt/hw-raid-info.html

I recently did all this research myself. SATA on Linux is going to get MUCH faster, probably as fast as SCSI, but you'll have to wait for the libATA improvements to take hold. Right now NCQ isn't implemented, and neither are 'multiple sector transfers'. I bought hardware that WILL support those features because I know that NCQ will dramatically improve speed and latency (under high-use conditions) when it is finally fully-baked.

The site to track progress on the library and driver status is here: http://linux.yyz.us/sata/

The project has been moving along quite well. I think their goal is to completely modularize, simplify, optimize, and consolidate the ATA, ATAPI, and SATA kernel pieces into one overarching (underlying?) library. I like this kind of work. I can't see why ALL disk-like I/O isn't under one big modular kernel library, it seems like it would make adding new transport types and drivers a lot simpler and reduce maintainance all-around.

Well, it helps to look at the current SATA compat list for Linux first -- which has been pretty dismal so far (but slowly getting better):

http://linuxmafia.com/faq/Hardware/sata.html
http://linux.yyz.us/sata/sata-status.html

Read my SATA RAID FAQ.

It's all software RAID, provided by the BIOS and OS drivers.

Or in other words, its Softare RAID, provided by the marketing department.

Slightly OT, but this site is frequently updated with the current state of SATA/RAID support under Linux.

dmraid, apparently. Once you've migrated the data off your array, do yourself a favour, and rebuild it using Linux md RAID. :-)

Check http://linux.yyz.us/sata/faq-sata-raid.html and http://linux.yyz.us/sata/sata-status.html. There's a good chance you'll be able to use your existing SATA "RAID" card with open drivers included in the standard kernel, and without any performance penalty.

Check http://linux.yyz.us/sata/faq-sata-raid.html and http://linux.yyz.us/sata/sata-status.html. There's a good chance you'll be able to use your existing SATA "RAID" card with open drivers included in the standard kernel, and without any performance penalty.

• hardware raid - where the OS speaks RAID-specific commands to the controller
• firmware raid - where software RAID is implemented in the firmware of the card
• software raid - RAID done by the OS

See my SATA RAID FAQ for a listing of the most common SATA chipsets which are sold as RAID, but are really software RAID (a.k.a. "fake RAID").

I'm also rather amazed that this wasn't mentioned in the review, but I admit I did not read all the of the 32 pages.

Troll my fanny. Have a read of the Linux SATA RAID faq. Notice all the claims that the RAID controllers aren't really hardware RAID controllers?

These claims are like the old claims that winmodems weren't really modems. Remember that? Strangely, now that someone figured it out, almost all winmodems work with Linux now and they are real modems again.

The fact that these RAID controllers are working RAID controllers for other operating systems but, don't work on Linux means that they really are hardware RAID controllers, contrary to the faq's claims. It means that LINUX does NOT support them. It means that no Linux developers have figured out how to make them work, yet.

I'm also willing to bet that Linux inability to work with many SATA RAID controllers is one of the primary, undisclosed, reasons that the majority of the controllers in the article weren't scored.

Oops, there's a problem. Let's just pretend it doesn't exist.

Well, cheap+reliable == linux + softraid + Enhanced Network Block Device + Enterprise Volume Management System (or LVM2). It is often faster than non-hw-raid (fake-hw controllers.

Fixed link: http://linux.yyz.us/sata/sata-status.html#tx2.

That status page is a few months old. Anyone know if what the mentioned there (that the PATA patch in libata-dev) has made it into the mainline kernel?

nvidia SATA status and other Linux SATA info.

nvidia wrote the SATA driver that's current in the Linux kernel, and has generally been helpful in addressing problems that arise in it.

Although the ethernet driver ("forcedeth") was indeed reverse-engineered, nvidia eventually lent their support behind the effort: they contributed gigabit ethernet support to the driver.

The video stuff is still closed, of course.

Jeff

nvidia SATA status and other Linux SATA info.

nvidia wrote the SATA driver that's current in the Linux kernel, and has generally been helpful in addressing problems that arise in it.

Although the ethernet driver ("forcedeth") was indeed reverse-engineered, nvidia eventually lent their support behind the effort: they contributed gigabit ethernet support to the driver.

The video stuff is still closed, of course.

Jeff

See this. (short version, they are mostly software raid controllers.)

Well for starters, you can set up 6to4 automatic tunnelling on your network, without having to bother your ISP at all.

Hurricane Electric and others offer tunnel broker services, which are static IPv4<->IPv6 tunnels. Note that most tunnel brokers refuse to forward IRC traffic.

Certainly some ISPs are starting to roll out IPv6 service, and if that's available in your area, take advantage of it. But if not, there are useful options (I recommend 6to4).

No, 6to4 is really that bad - it relies on custom tunnels and special ISP support rather than just specifying it on the routers.

Actually 6to4 Just Works(tm) in most cases. You can't get much easier than that. That is the purpose of 6to4: the special anycast prefix guarantees that you do not need special configuration or special ISP support.

I've played with ipv6 in the past, but after so many years it's still a very long way from useful. Since nobody has ipv6 machines and you need ISP support (which ISPs don't provide) putting up an ipv6 website is a sure-fire way to get zero hits.

Putting up an IPv6-only website would be pointless. The idea is for IPv6 transition to be seamless: a web server admin adds IPv6 to an existing website, and nobody except the IPv6 users will notice a difference.

My own website supports IPv6, and it gets a few hits daily from IPv6 users. It also supports IPv4, of course. And neither set of users ever need know, or care, about my web server setup. It Just Works(tm), and will continue Just Working as the world moves to IPv6.

It doesn't help that proxies eg. squid don't support it yet..

Apache does proxy caching and http acceleration quite nicely, and has stable IPv6 support.

I agree that squid lags behind, but overall you picked a poor example. Most of the core Internet software, both client and server, either has production-stable IPv6 support, or is close to it.

For Fedora Core users stuck without a direct IPv6 connection (read: most of the world), I wrote a quick IPv6 6to4 setup guide.

6to4 is "automatical tunnelling", which in layman's terms means you don't have to bother your ISP or a tunnel broker in order to set up IPv6 on your network. Most OS's these days (not only Linux but *BSD and Windows) fully support basic IPv6, including 6to4.