The Book of SCSI, 2nd Edition

Craig Maloney contributes the below review of a book he claims is long overdue -- the second edition of Gary Feld's The Book of SCSI. Probably it won't be long until someone is reviewing The Book of Firewire, but SCSI remains probably the most widespread standard for high-quality, reasonably priced storage. I know it's gotten better since the last time I struggled with termination issues and bad cables, but if you rely on SCSI every day, you may need this book.

The Book of SCSI, 2nd Edition: I/O for the New Millennium author Gary Field, Peter M. Ridge pages 456 publisher No Starch Press rating 7.5 reviewer Craig Maloney ISBN 1-886411-10-7 summary A one stop resource for the SCSI protocol.

What's Good? For those in a hurry, Appendix A (The All-Platform Technical Reference) is the entire book in a nutshell. I think Appendix A should be included with every SCSI card sold. It includes pin-out descriptions of the major and not-so-major SCSI interfaces, tables for bus timings, and a quick description of termination rules. The pages that surround Appendix A are also quite good.

The chapter on connecting devices to a PC talks at length about one of the more troubling aspects of SCSI; termination. Anyone who has had to troubleshoot SCSI installation problems will enjoy how thorough Chapter 6 deals with troubleshooting. (It even includes what a SCSI signal should look like on an oscilloscope). Programmers will find a Chapter with information on programming using ASPI, as well as protocol specifications for those looking for more low-level information. You'd be very hard pressed to find a more complete and readable treatment of the SCSI protocol than this book.

What's Bad? Unfortunately completeness can lead to information overload. Novice users will find themselves at a disadvantage with the sheer amount of material presented.

When discussing how to set up a SCSI adapter, the book mentions the various PC busses from the earliest IBM PC to draft revisions of PCI and everything in-between. Had I been a novice reader, I would have been overwhelmed with all the information about historical PC busses that are no longer in use. (When was the last time you used VLB or EISA?) In the interest of completeness, the authors also include a chart comparing these interfaces. I question whether this is really necessary. Some may also be put off by the hand-drawn diagrams in the earlier chapters.

On the CD

The CD includes items such as the SCSI FAQ, ASPI Development Files, ASPI tar, SCSI disk driver source for MSDOS, Western Digital SCSI Utilities, SCSITool, Postmark I/O benchmark source code, and Linux SCSI information. Of note, the CD also includes a PDF file of the entire book.

What's in it for me?

The Book of SCSI is definitely written by SCSI enthusiasts. On the early pages, the authors include a bit of SCSI poetry, and the CD includes a text file entitled "SCSI: A Game With Many Rules and No Rulebook?". This book reads with an excitement only an enthusiast can project. If you have ever been curious about SCSI, I encourage you to sit down and read the first few chapters of this book. If you are in a position to use SCSI components more than occasionally, I recommend you purchase this book and keep it on your reference shelf for those times when troubleshooting is necessary.

My biggest complaint? I wish the authors had written this book ten years ago. However, it is still a welcome addition to my library today.

• Chapter Listing
• Chapter 1: Welcome to SCSI
• Chapter 1.5: A Cornucopia of SCSI Devices
• Chapter 2: A Look at SCSI-3
• Chapter 3: SCSI Anatomy
• Chapter 4: Adding SCSI to Your PC
• Chapter 5: How to Connect Your SCSI Hardware
• Chapter 6: Troubleshooting Your SCSI Installation
• Chapter 7: How the Bus Works
• Chapter 8: Understanding Device Drivers
• Chapter 9: Performance Tuning Your SCSI Subsystem
• Chapter 10: RAID: redundant Array of Independent Disks
• Chapter 11: A Profile of ASPI Programming
• Chapter 12: The Future of SCSI and Storage in General
• Appendix A: All-Platform Technical Reference
• Appendix B: PC Technical Reference
• Appendix C: A Look at SCSI Test Equipment
• Appendix D: ATA/IDE versus SCSI
• Appendix E: A Small ASPI Demo Application
• Glossary
• Index

You can purchase this book at Fatbrain.

Comments

Chapter list

[Monte]

Which chapter has the instructions for sacrificing the goat?

I love SCSI!

[aussersterne]

IDE is clumsy and slow compared to SCSI when you start to get many devices in the same machine.

I have a 3-channel LVD SCSI controller in my video system and it's talking to devices of all vintages:

1) Three 18.2GB Barracuda LVD drives in a RAID-0.
2) Four 9.1GB Micropolis UW drives in a RAID-0.
3) 8x CD-R (not CD-RW) drive.
4) Brand new DVD-R drive (whoopee!)
5) Two 1.3GB 5.25" Magneto-Optical drives.
6) 7/14GB 8mm tape drive.
7) 12/24GB 4mm tape drive.
8) Very old (but needed) Archive 2150S (QIC-150).
9) 100 MB Zip drive.
10) 300 DPI scanner (for rough stuff).
11) 1200 DPI scanner (for more important stuff).

The system lives in a server case with dual 450W power supplies, so of these devices, only the two optical drives and the two scanners are external. There are only three cables inside the case for the lot. Theoretically, there are 28 more SCSI IDs available for use.

Now, the nice thing about this is that I can have damn near all of them running at the same time without any appreciable slowdown -- something that never happens on my "play" system with IDE drives.

On my IDE system, I've got two hard drives, a CD-RW and an IDE tape, and the IDE channels often seem to slow each other down and fight for control when I start to burn, backup, and do lots of disk I/O at the same time. I've been told that this is because a single IDE interface doesn't do concurrent access to both drives.

Either way, I love using the SCSI system. It's an I/O monster. And I love being able to just hang whatever kind of device I need to use off of the external connector and know with reasonable certainty that Linux will support it. Long live SCSI.

Re:If you rely on SCSI every day...

[Salamander]

As to the high end... Fiberchannel is a step forward, but not enough. Forget all these special purpose buses anyway... my suggestion would be to put a gigabit ethernet interface and an IP stack directly in the drive.

IP is a poor match for storage needs, IMO. TCP in particular was designed - and designed rather well - for the high-latency small-packet environment of the Internet, but storage is a low-latency large-packet world. It's also a world where the hardware must cooperate in ensuring a high level of data integrity, where robust and efficient buffer management is critical, etc. etc. etc. Even on cost, the equation does not clearly favor storage over IP. Sure, you get to use all of your familiar IP networking gear, but it will need to be upgraded to support various storage-related features already present in FC gear. Even on the controller end, do you really think a GigE interface plus an embedded IP stack is easier or cheaper to incorporate into a controller design than FC? I could go on, but I hope you get the point. "One size fits all" is a bankrupt philosophy. Let IP continue to be designed to suit traditional-networking needs, and for storage use something designed to suit storage needs.

Better to run something like GFS directly on the drive.

No, not better at all. Who wants the drive to be a bottleneck or SPOF? The whole point of something like GFS is to avoid those problems via distribution. Putting an IP stack on the drive is bad enough, and now you want to put a multiple-accessor filesystem on it? Dream on. People used to put things like networking stacks and filesystems on separate devices, because main processors were so wimpy, but they stopped doing that more than a decade ago. For a reason.

huge RAID arrays with one smart control node (like NetApps, etc)

NetApp doesn't make disk arrays. If you look at the people who do make high-end disk arrays, you'll see that they have far more than one brain. A big EMC, IBM, or Hitachi disk array is actually a very powerful multiprocessing computer in its own right, that just happens to be dedicated to the task of handling storage.

one drive per brain, a full computer in each drive, each drive a full node on the network

...at which point you're back to distributed systems as they exist today, wondering how to connect each of those single brains to its single drive with a non-proprietary interface. Going around in circles like that doesn't seem very productive to me.