SGI: Hardware

I would really, really love to put a SSD into each of my indys ... not only are they screaming fast, but they're silent as well.

And it would be very nice not to worry about disk crashes [1].

But I cannot find any scsi SSDs ... the only ones I see are these ridiculous external disk boxes that cost a million dollars, etc.

I use the Intel SSDSA2MH080G1C5 in SATA systems and it is great ... I really just need a scsi version of that to start plugging into my sgi/sun machines.

Do they exist ?


[1] I know all about the write-resiliance issues with flash media. I am aware of those risks.

You might try a SCSI-SATA adapter. Acard makes them but they don't all seem to be compatible with all SGIs. See if anyone here has tried on with an Indy before you buy. There's a Yamaha SCSI-PATA adapter that supposedly works well but then you need a PATA-SATA adapter unless you get a PATA SSD.

Isn't noise from the Indy already drowning out your hard drive's noise?

In my life I have only ever seen one SCSI SSD and it was only in a photo and my goodness was it old.
It was apparently made by Quantum
Even if you could find it there is no way you could stuff it into an indy.

QuicksilverG4 wrote: Isn't noise from the Indy already drowning out your hard drive's noise?

When I saw this post I thought it was genius, because a Sony PSU in an Indy is one half notch over silent. All the old SCSI hard drives I have in my Indy's are far louder than the power supply fan. Besides, the hard drive probably contributes between 1/4 and 1/3 of the heat, meaning the temperature controlled fan in the Sony might even work a little less.

I wonder if a SCSI <-> PATA + PATA <-> CF adapter would work well enough with a modern 16gb CF card. The CF might be a little more prone to cell wear than a purpose built SSD though. I'm not sure if CF cards have wear pattern mitigation like the SSDs.

japes wrote:

QuicksilverG4 wrote: Isn't noise from the Indy already drowning out your hard drive's noise?

When I saw this post I thought it was genius, because a Sony PSU in an Indy is one half notch over silent.

Sorry, never owned an Indy. Never liked them.

Ok, they exist

Here are the scsi narrow, 50pin models (2.5"):

http://www.bitmicro.com/public_docs/pro ... 2S20BL.pdf

and the u320 model (3.5"):

http://www.bitmicro.com/public_docs/pro ... S320EL.pdf

So that's that. I have not looked up a price, but since they have relatively low capacity models (8 and 16 GB, etc.) I am thinking they are not outrageous... could probably be used in any desktop SGI/Sun application.

japes wrote: ... All the old SCSI hard drives I have in my Indy's are far louder than the power supply fan.

There are better alternatives:

- Seagate 18GB 50pin (ST318418N): very, very quiet indeed. Actually annoying sometimes when testing stuff, keeps
fooling me it's not even powered on. I honestly can't hear it making any noise when the system is power on (R5K/180,
XZ, 256MB). There's one on eBay USA for 56 UKP which is much less than my price (I have two, one is spare).

- IBM-branded 9GB Seagate U160 ST39236LC (with adapter). Unbelievably low-noise. I've yet to find a quieter SCA
drive than this one. I don't know if the generic ST39236LC is just as quiet, or if the IBM version is special in some way.
Couple on eBay USA for approx. 25 UKP.

Ian.

japes wrote: I wonder if a SCSI <-> PATA + PATA <-> CF adapter would work well enough with a modern 16gb CF card. The CF might be a little more prone to cell wear than a purpose built SSD though. I'm not sure if CF cards have wear pattern mitigation like the SSDs.

FWIW, I'm using an Acard SCSI <-> PATA + PATA <-> CF adapter with my Compaq XP1000. Works great, gets picked up by the SRM fimware as a bootable drive and everything. If it works on an Alpha, it'll probably work on an SGI. I would try it on my Indy, but then I would also need a 50-68 pin scsi adapter which I don't have handy.

No comment on the wear leveling, I'm using mine purely to hold the OS kernel (linux) for booting. Once the kernel boots, it loads the drivers for my scsi RAID card where the OS is installed.

pentium wrote: In my life I have only ever seen one SCSI SSD and it was only in a photo and my goodness was it old.

The SSD concept has been around for a couple decades at this point, with various interfaces at first, but up until a few years ago, all of the recent ones were SCSI.

Ian wrote: There are better alternatives:
- Seagate 18GB 50pin (ST318418N):
- IBM-branded 9GB Seagate U160 ST39236LC

Just keep in mind that if you're looking for total silence, you need not just specific models, but also a brand new drive. Not used, not refurb, but brand spanking new. Anything with moving parts can start making noise when those moving parts move.


And, generally speaking, I'd try to avoid multiple adapters from different manufacturers if you can help it. The various translation layers sort of nominally work for the most part, but if any one layer hiccups even slightly, the other layers have a tendency to freak out.

Chris

Wont SWAP help end the SSD life span sooner?

Gray Fox wrote: Wont SWAP help end the SSD life span sooner?

Not if you disable it. Although Indy's 256MB memory limit doesn't make it the best machine to run without swap.

SAQ wrote:

Gray Fox wrote: Wont SWAP help end the SSD life span sooner?

Not if you disable it. Although Indy's 256MB memory limit doesn't make it the best machine to run without swap.

Hmmm... I am under the impression that modern SSDs deal with swap much better using their wear-routines ...

It's still a problem, but not nearly as acute as, say, a sandisk CF card sitting in an adaptor.

I'll look into it...

For a while they sometimes had a setup similar to the Prestoserves where there was a front "cache" of RAM that handled the rapidly changing data before writing it out to the flash. Not sure what they do now. Of course, there's also the really old SSDs made of entirely battery-backed SRAM.

The Keeper wrote:
> Just keep in mind that if you're looking for total silence, you need not just specific models, but also a brand new drive. Not used, not refurb,
> but brand spanking new. Anything with moving parts can start making noise when those moving parts move.

That's being overly fussy IMO. The Seagate 18GB 50pins I have really are ridiculously silent. Friend of mine from SUN was over today,
I got talking to him about drive/system noise, so I put together an Indy with a Sony PSU and the 18GB Seagate - he agreed, almost no
noise at all. One can just about her a faint whir as the drive spins up, but afterwards there's basically zip. I make a lot more noise just
typing.

Sure, used drives can develop odd noises, etc. and lose any nice quietness, but it's equally possible to get used drives that work flawlessly.


> And, generally speaking, I'd try to avoid multiple adapters from different manufacturers if you can help it. ...

Never had a problem with this myself. It's just a single conversion afterall. I'd be much more wary of SCSI/IDE conversion.

Ian.

mapesdhs wrote: That's being overly fussy IMO.
[...]
Sure, used drives can develop odd noises, etc. and lose any nice quietness, but it's equally possible to get used drives that work flawlessly.

As always, YMMV.

mapesdhs wrote: > And, generally speaking, I'd try to avoid multiple adapters from different manufacturers if you can help it. ...
Never had a problem with this myself. It's just a single conversion afterall. I'd be much more wary of SCSI/IDE conversion.

Right, that's what is being referred to in this thread -- taking a SATA SSD, sticking a SATA-PATA adapter in front of the SSD, and then sticking a SCSI-PATA adapter in front of the PATA interface. I wouldn't trust that combination myself, especially not for an operating system disk.

(I'd actually refer to them as "bridges", because that's what I work on for a living, but it's easier to refer to those devices as "adapters".)

Chris

mapesdhs wrote: > interesting bit of wild speculation. got anything to back it up?

Maybe you read different articles. Seems pretty obvious to me. The whole TRIM issue is a typical example.

Ian, block oriented devices such as HDD and SSD don't interpret file system constructs stored on them. if they did, they would be able to tell if a block or page, extent or range of storage had been de-referenced, or deleted, and thus the storage may have a different context. in the case of SSD where blocks have to be erased before they can be re-written, the device has to treat all blocks as containing data, as the meta-data detailing which blocks have been written, or deleted is contained in the file system, which is not interpretable by the block device. since all blocks therefore contain data, the erase, or pre-erase operation has to be worse case, by treating all block as used. clearly, if the block device had information about which blocks are being used at any one time, it would make more optimal choices about which blocks can be erased, since it could use the least populated blocks.

a TRIM command allows an operating system to inform a solid-state drive which blocks of data are no longer considered in use and can be wiped internally.

the TRIM command is the mechanism that allows the file system / device combination to transcend interpretation of the file system meta data to identify which blocks are not being used.

Ian, in all that where does Windows have an advantage?

As for the OP, if you want the advantages of solid state storage on an Indy you are probably better off going with a SCSI->ATA adapter and a compactflash card. Indy has a SCSI system from 1993 and putting in an SSD will not change that.

Unless you have big memory buffers SSD will not work well on Irix that I am very much sure of.
The device will run quick from the beginning when the disk is fully erased since the SSD can find avalible(erased) flash blocks and write instantly.
Assume that you have a 64GB SSD, erased and new then you put IRIX and XFS on the SSD and you will have maybe 55 GB free after added the swap.

Once you start to create a file(mkfile) say 1GB you will use up 1GB of the 55GB leaving 54 GB to available for instant writing, then you remove(rm) that 1GB file and you will still only have 54GB of free erased memory BUT the XFS will know that it has 55GB not 54GB of free memory(the 54GB is the free erased space). Then you create a 1GB again, and then rm the file and you are down to 53 and so on until your are down to 0GB of erased space BUT still 55GB of free space on the drive but these 55GB are not erased.

Not you create a new 1Gb file but this time the drive will stop for a long period of time(seconds) while the SSD flash cells are being erased BUT only 1GB of them then after they are erased the 1GB is written.

From now on the drive will dead slow.

Now once you are down to 0GB erase

So you need buffers alot of them to buffer while erasing in order to not halt the application, I think ZFS is one of very few that can run nicely on SSD without adding some (erase/TRIM) commands to the FS drivers.

Correct me if I am wrong.

I should add that I went to all SSD for a year or two ago and they don't differ that much.

I am certainly not an expert, but XFS makes heavy use of buffers. If system memory is not being used for anything else well over half of the memory will be used for the filesystem. Even on Onyx with 2gb of memory... I have seen it using well over 1gb of memory (by gr_osview)

two things:
1) enterprise SSD's keep as much at 1/3 flash capacity for pre-erase buffer to keep up with performance. you can buy FC and SAS/SATA drives in the several hundred GB range that keep up with wrire speed in bandwidth, sub millisecond response times, and as much as 30K IOPS (Read). SCSI SSD are likely to be well engineered too. the little PCI-E ones are dinky.
2) XFS IO traffic has a lot of 4K IO for data, and small 512byte data for meta data. there are small writes for logging as well. i don't remember the numbers off the top of my head, but it can still be substantial. we just put a fix in for XFS in linux fragmenting large IO's up into smaller ones. what a hack it's become.

the internal architecture of the drive has a heavy influence on the read vs. write performance. multiple flash channels allow you to keep a high random IO as long as there are no writes. once a write occurs, it picks a channel that will now be busy for 3ms during an erase cycle. your read could be stuck behind that erase, and that channel can't be used for anything else. the little cheap ones only have a couple of channels, you're unlikely to see this effect.

the IO working set of heavy DB application can be several hundred GB easy, that couple of GB write buffer will only cut the very small top of your IO skew. i've seen applications with several TB of working sets over a few short hours. in mainframe it's much worse.