OctalDump wrote: » Yeah, they are just layers of abstraction. So the hardware RAID can be set up to present logical 'disks' (or virtual disks or LUNs or other vendor terminology) to the OS, and the OS can use those 'disks' to create storage pools, which can be used to create volumes. If you want to go in deep and tune for speed or redundancy, then you really need to understand the whole stack (from the physical disks up to the volume and filesystem). But for the goals of MCSA, it's safe to play around with what you have at the hardware RAID level, since as far as the OS is concerned these are just regular disks (well, sort of, but not in a way that matters for MCSA). Actually, the deeper you go into storage, the more layers of abstraction you come across. For example the addressing that the OS uses to talk to the 'physical platters' isn't necessarily the address used, since blocks can be remapped if they go bad. This is one reason disks get slower as they get older. This matters a little bit for tuning, and a lot for data forensics, but for regular use, it doesn't matter.
anouri wrote: » Ah, I see. But won't Storage Spaces software RAID functionality conflict with hardware RAID functionality? Like if you're striping data at hardware layer and then mirroring at software. I understand storage pools might not be a problem, but I thought mixing software and hardware RAID would cause some issues. Thanks.
poolmanjim wrote: » If I am correct, Storage Spaces actually cannot work with a configured Hardware RAID. From https://technet.microsoft.com/en-us/library/hh831739.aspx :Serial ATA (SATA) or Serial Attached SCSI (SAS) connected disks, optionally in a just-a-bunch-of-disks (JBOD) enclosureRAID adapters, if used, must have all RAID functionality disabled and must not obscure any attached devices, including enclosure services provided by an attached JBOD.