Linux RAID is different from Windows for sound technical and historical reasons
plus.google.com
plus.google.com
I know this is Linux's Alan Cox but the post reads like a typical Windows hater Linux desktoper and is quite amusing and even quaint if you have just passing familiarity with ZFS internals to contrast.
As far as the layered approach I would also suggest study of FreeBSD's geom which dips slightly below and above Linux's mdraid (i.e. you still use geom with ZFS, zvols) but IMHO is a bit cleaner probably because it's a later arrival.
How do you know you you have hardware with different queue sizes? Why, you start to experience data corruption for no apparent reason, of course. There's no other warning. And the only "workaround" is setting the global queue size to the lowest common denominator of the hardware installed – and God help you if you later install hardware with a lower queue size.
(Aside: I think bug trackers should be configured in such a way that you can't mark a bug as having been fixed unless you specify the ID of the commit in which it was fixed.)
Alan Cox, former #2 Linux kernel developer, at G+, on the differences between Linux and Microsoft RAID support, related to recent Lenovo news,[1] and the technical and historical basis for this.
I did some massaging of the fourth paragraph, which seems closest to a lede/head, to fit within HN's 80 character headline limit. The first four 'graphs of the post:
"Unsupported models will rely on Linux operating system vendors releasing new kernel and drivers to support features such as RAID on SSD"
Good to see that the tech press fact check comments from companies as well as the political press fact check politicians. I'm reading this on a box with RAID1 SSD. It's had RAID1 SSD for some years.
Linux has supported RAID on SSD for years, in fact it supported it from the moment you could plug an SSD into a Linux PC.
Linux RAID is different from much of the Windows experience, for a mix of sound technical reasons and historical ones.
________________________________
Notes:
1. http://www.gossamer-threads.com/lists/linux/kernel/2352338 (from Cox's post).
As far as hardware RAID controllers, at least you get a battery-backed write cache that will "just work" without the OS, right? As in, you don't need to boot the OS to finish flushing. Or maybe I've just bought into the hardware RAID marketing. It does seem simpler, as in less to deal with, to let the card do it and just present whatever volumes desired to the OS.
What's worse: if you try and mount the drives, it doesn't say "this looks like a raid1 volume, I don't have drivers for that, please upgrade to access this data", it says something more like "data corrupt, would you like to format this drive? [Yn]" :/
Same thing on Windows 7 (that may be limited to the pro/entreprise editions)
Since windows server 2012. The OS has "storage spaces" which is a full management solution for RAID and volumes and physical disks. It's somewhat similar to the ZFS/zpool/mdraid/dmcrypt tooling, EXCEPT it's all in a single software, unified, way easier to use and with a nice GUI.
IMO. Software raid and disk management is utter shit on Linux. They are easily lagging > 10 years behind but that's just my point of view.
Make a simple search on google on "how to resize a partition on linux" and you get ten tutorials, all of which give different steps, none of which work.
There are at least 7 different tools for managing disks on linux most of which vary by distribution and version: fdisk, mkfs, partx, parted, growpart, mdraid, dmcrypt...
Little story: The auto extending of partitions on boot (i.e. a critical thing in cloud environment) has been broken in debian stable for more than 6 months.
It's calling "growpart" that is calling other tools, one of which is "partx". Some flags are changing between versions and it breaks the whole toolchain, unless all software versions are carefully selected.
We could continue on why do some of the tools only accept cylinder and block counts as size??? or why is gparted a terrible GUI for managing disks.
Well there wasn't really a choice was there?
Reason for that is that adding a disk to vdev will require rebalancing everything and considering complexity of zfs, you better just make a new raidz with 4 disks and move data over, otherwise it might just take ages and complicate things a lot. This is obviously not ideal for a home user, but zfs was not created with a home users in mind.
Btrfs supposedly should let you do this, but their raid5/6 is still unstable - probably for a reason. In fact, this is not such a big deal. You can add disks to a zfs mirror (and it is real n-way mirror, not btrfs raid1 thing with multiple disks), you can add mirror vdevs to raid10 setup. If you are making raidz1/2/3 just make sure you understand that you can't expand it by adding more disks.
And yes, most people should default to ZFS for everything on FreeBSD/IllumOS/Solaris/Linux. There are specific cases where you should use XFS or UFS on these operating systems such as fail in place and overlay filesystems (HDFS, Ceph, Swift etc) but times have changed, the tables have turned, these non-ZFS filesystems are now expert territory with here be dragons warning label.
* outboard RAID provides write amplification across physical devices
* soft RAID1 (simple mirror) is nice for things like boot volumes and easy to fix when it breaks
But yeah, ZFS and similar strategies work much better than soft RAID-5/6 for file store resiliency across visible LUNs.
I think you perhaps meant fan out, which is partially valid but addressed in the submitted article - i.e. bus speeds have improved greatly. In fact to the point where you can easily have no bus at all: point to point PCIe lanes to each NVMe device.
A zmirror is simple too, and gives you boot environments so you can roll back failed upgrades and other magic.