sata vs SAS?

A

AndreRio

[H]ard|Gawd
Joined
Nov 23, 2011
Messages
1,240
is SAS a new interface? will I need a new controller card+sas ssd to use it?
 
SAS has been around for a long time. The primary benefit is that you can use an expander card which allows you to attach dozens of cards to one controller. You typically only find it in servers and it cost quite a bit more than SATA. I see no benefit for a typical home or work desktop computer.
 
Last edited:
SAS is the sucessor to SCSI (It's actually an acronym for Serial Attached SCSI)


SCSI --> SAS
IDE --> SATA

Not really applicable to most non-server systems.
 
SAS and SATA are much more similar than IDE and SCSI ever were though. For instance, SAS controllers are compatible with SATA drives. The reverse (using a SAS drive on a SATA controller) is not possible however.

You often see situations where people use SATA SSDs instead of SAS drives in their servers because they are compatible, faster, and often cheaper.
 
As other people stated SAS is for servers. If you don't have a server you most likely cannot use SAS drives.

SAS has a single long connector combining power and data. SATA is the same connector just with a gap in the middle. This means SATA drives can be used in systems that take SAS, but SAS drives can not be used generally in systems designed for SATA.

SAS has a different command set (meaning it uses different system of communication between the drive and controller) and as mentioned previously allows more then 1 device to be connected to each port.
 
If you have to ask, it probably isn't for you! Just stick with SATA SSDs.
 
My P6T7WS has built in SAS ports which I never used until now. Out of curiosity I bought a 15K RPM 146 GB SAS drive on Amazon for $30 to see what it's like.

I'm still learning but for the most part, it works pretty much like everything else. You see the drive in My Computer and you can use it as usual.

One difference I noticed is SAS drives don't spin up until they receive the command to do so. In my case when Windows loads.
 
Last edited:
Buy SAS if you are awesome and need dual-port high availability features. SAS can read and write simultaneously, whereas SATA cannot. SAS can also handle higher QD loads much better.
 
Computurd said:
Buy SAS if you are awesome and need dual-port high availability features. SAS can read and write simultaneously, whereas SATA cannot. SAS can also handle higher QD loads much better.
Click to expand...
Wut?

Dual port allows two systems (controller cards, for example) to access the drive simultaneously. This allows you to lose an HBA without read/write interruption. It's redundancy, not speed. Think about the physical aspects of the drive as far as the read/write simultaneously thing goes. You still have one arm, and one platter for any given data. If you want to write something, you need to position the arm over an empty spot on the platter and then begin writing. If the arm is over that spot, how exactly is it going to read data that's on a different part of the platter, or even a different platter entirely? I think a lot of folks just don't understand what the "full duplex" aspect of SAS means, and end up misinterpreting it.

SAS is:
Hotter (higher RPM and higher signal volts)
More reliable (Excepting NL-SAS, the drives are built to a more exacting standard, and SAS itself has protection against transfer errors)
More expensive (Duh)
Faster (Higher RPM allows for quicker random access)
More expandable (One drive can be accessed by two controllers. One controller can handle 1024 drives.)
 
Last edited:
TJ, nice post. I'm still trying to wrap my head around this stuff. So if I have an SAS JBOD enclosure with two host ports, and connect a different HBA to each port, are the HBAs talking to the separate phys on each disk? And if I put, say, a SATA SSD in the JBOD, is it even possible for both of the HBAs to talk to it?
 
Last edited:
SAS can read and write at the same time. Again, we are talking about SAS, the protocol to talk to disks, how the disk does it does not matter.

Take a SAS ssd, it can easily read and write to many of it's chips at the same time.

SATA can only read or write, it is not a bidirectional protocol. You can't issue a new command, while receiving data from the disk, you must wait.
 
TJ, true, if you are using platters you have to wait for the drive. However, in light usage scenarios even with disk you can get a boost from simultaneous read/write.
Hook it up to an SSD, BAM!

..well i see that Patrick has already cleared it up.
 
In order to benefit from those advantages you'll need a SAS SSD, expensive!

As with my experience with SAS on a desktop, some small differences I've noticed is you have to run command prompt in Admin mode to use chkdsk and fsutil on SAS drives. I wonder why. SATA drives don't seem to care.
 
danswartz said:
TJ, nice post. I'm still trying to wrap my head around this stuff. So if I have an SAS JBOD enclosure with two host ports, and connect a different HBA to each port, are the HBAs talking to the separate phys on each disk? And if I put, say, a SATA SSD in the JBOD, is it even possible for both of the HBAs to talk to it?
Click to expand...
SAS disks have WWNs for unique identifiers. Dual-port SAS disks have two of them. The enclosure will map one WWN to each port, and allow the two HBAs to talk to the one disk simultaneously. A SATA SSD doesn't use WWNs, so only one controller could talk to it at a time. I suppose it's possible to have a chip that converts SATA to SAS, and I think LSI even makes them, but I'm not familiar enough with them to tell you which features would or wouldn't work.

patrickdk said:
SAS can read and write at the same time. Again, we are talking about SAS, the protocol to talk to disks, how the disk does it does not matter.
Click to expand...
I don't suppose you've got a link to a paper talking about how that works, do you? I think it might make for some interesting reading. I could see it working with multiple disks, but then again, I've not seen anything to suggest that SATA disks, even with the half-duplex limitation, wouldn't be able to do the same. I think I need to wrap my brain around it somehow. I'll gladly correct one person. If two people tell me I'm wrong, well... Maybe I'm not as right as I think.
 
"SAS disks have WWNs for unique identifiers. Dual-port SAS disks have two of them. The enclosure will map one WWN to each port, and allow the two HBAs to talk to the one disk simultaneously. A SATA SSD doesn't use WWNs, so only one controller could talk to it at a time. I suppose it's possible to have a chip that converts SATA to SAS, and I think LSI even makes them, but I'm not familiar enough with them to tell you which features would or wouldn't work."

TJ, sorry I wasn't clear. I am not concerned with simultaneous access. The idea would be: export a ZFS pool on host A, then import it on host B. The pool drives are SAS, so however that works, it works. The l2arc SSDs are SATA though, so I don't even know if they could be in the jbod enclosure. My question is: if you have a two port jbod enclosure, do the two ports automatically talk to the different SAS ports? Or is that tied into zones or domains or some-such? I guess I can answer that by plugging another host running linux or omnios or whatever into the other jbod port and see what WWNs it sees?
 
danswartz said:
My question is: if you have a two port jbod enclosure, do the two ports automatically talk to the different SAS ports?
Click to expand...
That depends on the physical cabling, if I'm understanding you correctly. For example, you can have one SFF-8088 connected to a controller, and another connected to a backplane. (Via a 8088-to-8087 cable) You could also have one connected to the backplane's "IN" port, and one connected to the "OUT" port. Or, you could have both connected to the backplane's "IN" ports. Only the last scenario is true "dual port".

As for exporting and importing a pool between hosts, I don't really see an issue. Most enclosures I know of support SATA drives in SAS slots. I haven't tried it myself to see if it "downgrades" all drives on the backplane to SATA or not. We've got a system here at work that has 24X SATA drives on one controller port, and 42xSAS drives on the other controller port (in a JBOD), but they're different pools.
 
The enclosure in question has two input and two output (daisy chain?) ports, so I can certainly plug each host into a specific in port. What I wasn't sure of was whether each in port goes to a different phy on each sas drive. Your comment 'depends on the cabling' is what someone I was chatting with at work said. I guess I won't know until I get home and boot a spare host with an HBA connected to the other in port and enumerate the drives to see if the WWNs are different or not. Thanks!
 
!
I really don't understand a single thing u guys are talking about. :c(
 
Long story short, as I mentioned before, as an average consumer, SAS is not for you and shouldn't worry about it. It offers a features that businesses and enthusiasts desire, but at an added cost and complexity. Wikipedia will give you a nice detailed description instead of the various tangents that this forum seems to go off onto (which not all of is even correct).
 
GotNoRice said:
SAS and SATA are much more similar than IDE and SCSI ever were though. For instance, SAS controllers are compatible with SATA drives. The reverse (using a SAS drive on a SATA controller) is not possible however.

You often see situations where people use SATA SSDs instead of SAS drives in their servers because they are compatible, faster, and often cheaper.
Click to expand...
Speaking of which, have you guys analyzed the kind of writes that a system drive undergoes on Windows Server? That is, if it's been configured as a discrete drive for Server with data on the array? I'm wondering what kind of feasible life the average enterprise MLC has because the prospect of applying updates and rebooting a server in like 30 seconds is appealing as all get out :cool:
 
I'm wondering what kind of feasible life the average enterprise MLC
Click to expand...

I expect several decades of life provided you get a 250GB SSD or larger. Although with that said any storage device can die at any time so always have a backup.
 
drescherjm said:
I expect several decades of life provided you get a 250GB SSD or larger. Although with that said any storage device can die at any time so always have a backup.
Click to expand...
Wow! I get it now about the provisioning, that totally makes sense about the size of the drive. About the backups, what is a good low maintenance strategy? RAID-1 would affect the life of the mirror just as much as the primary so is there some kind of delayed or periodic swappable drive software or hardware solution? Say for example the mirror drive is written to four times a day or so and only incrementally so it's not mirroring the entire thing? I guess just periodic images of the system drive would be an option but I'm thinking something that can come online quick like BackupExec Pro's imaging features.
 
RAID1 is fine for uptime but I would do a real backup instead or in addition to the raid.
 
drescherjm said:
RAID1 is fine for uptime but I would do a real backup instead or in addition to the raid.
Click to expand...
This. Set something up in Windows scheduler to do a robocopy /mir (mirror) once a day between drive 1 and drive 2. Or, in linux/unix/bsd/etc, add an rsync command to cron. You won't get real* backups that way, but it's basically RAID-1 without constant writes.

*Differential backups, backups set to read-only once they're written, etc
 
TeeJayHoward said:
This. Set something up in Windows scheduler to do a robocopy /mir (mirror) once a day between drive 1 and drive 2. Or, in linux/unix/bsd/etc, add an rsync command to cron. You won't get real* backups that way, but it's basically RAID-1 without constant writes.

*Differential backups, backups set to read-only once they're written, etc
Click to expand...
Awesome!! Thanks guys!
 
eoreality-robby said:
http://www.sandisk.com/enterprise/sas-ssd/optimus-max-ssd/
Quite fast actually. I can't wait until those come out :p
Click to expand...
The Optimus SSDs are optimized for storage size, and can sustain "only" 1 to 3 full drive writes per day. The Lightning SSDs are smaller but twice faster, and can sustain 25 full drive writes per day. Still, it is amazing that they are able to pack 4 terabytes into a 2.5 inch form factor. That would be 16 terabytes if they had 5.25 inch SSD drives! It's rare that SAS drives are leading the edge for storage capacity compared to consumer SATA drives.

By the way, both the top Optimus and Lightning drives are guaranteed for 5 years, which matches the best enterprise hard drives, but their Mean Time Before Failure is 2.5 million hours, which if my computation is correct is about 285 years... ;)

http://www.sandisk.com/enterprise/sas-ssd/
 
TeeJayHoward said:
This. Set something up in Windows scheduler to do a robocopy /mir (mirror) once a day between drive 1 and drive 2. Or, in linux/unix/bsd/etc, add an rsync command to cron. You won't get real* backups that way, but it's basically RAID-1 without constant writes.

*Differential backups, backups set to read-only once they're written, etc
Click to expand...

Also look at Cobian Backup. Nice GUI tool for backups.
 
Chimel said:
By the way, both the top Optimus and Lightning drives are guaranteed for 5 years, which matches the best enterprise hard drives, but their Mean Time Before Failure is 2.5 million hours, which if my computation is correct is about 285 years...
Click to expand...
Please note that this does not mean a drive will fail on average every 285 years. It means that if you had 2.5 million drives, one would fail per hour. Big, big difference.
 
Nothing wrong with having SAS on a desktop. There's no such thing as overkill. This is [H]ardOCP right?

I just bought two 15K RPM SAS drives on my desktop a few days ago ($30 bucks on Amazon these days!) just to satisfy a curiosity and old dream of having SCSI drives.

There are several topics online about the SAS protocol being more reliable than SATA because its SCSI nature. Is that true? Is the SAS interface and/or protocol (not the drive) more reliable?
 
TeeJayHoward said:
Please note that this does not mean a drive will fail on average every 285 years. It means that if you had 2.5 million drives, one would fail per hour. Big, big difference.
Click to expand...

The problem with SSD's is the way they fail. It can just go without warning. At least HDD's give some sort of warning. With SSD's the data is spread across the chips, like RAID-0 within the SSD. If one chip dies, the all the data is gone.
 
You must log in or register to reply here.
Back
Top