SGI: Hardware

Are SCSI ssd drives available ? - Page 2

mila
From Bålsta, Sweden
Who joined Dec. 31, 2009, 4:20 a.m.

Wrote the following at Nov. 24, 2010, 2:28 p.m...

skywriter wrote: 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.

Your point 1, if the SSD does not know the FS(most dont) how can it make use of the "spare" capacity?

/michael

--
No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own
risk.

jan-jaap
From Wijchen, The Netherlands
Who joined June 17, 2004, 11:35 a.m.

Wrote the following at Nov. 24, 2010, 2:43 p.m...

skywriter wrote: we just put a fix in for XFS in linux fragmenting large IO's up into smaller ones. what a hack it's become

You're not kidding, you are living in a living in a linux-blunderland

Thanks for the insights.

Now this is a deep dark secret, so everybody keep it quiet

It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:

(2x)

In the museum : almost every MIPS/IRIX system.
Wanted : GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)

skywriter
From living in a linux-blunderland
Who joined March 14, 2003, 5:22 a.m.

Wrote the following at Nov. 24, 2010, 3:54 p.m...

mila wrote: Your point 1, if the SSD does not know the FS(most dont) how can it make use of the "spare" capacity?

say you buy a 146GB capacity EFD, the actual amount of flash to 200GB. the extra 54GB is use as a pre-erase pool. this way you don't have to wait around for ~3ms while a block is erase, and the old data (that doesn't change in the block, and the new data (that you're over writing in the block) are assembled into the new block and written. you can just go to the read/write part. in the back ground the extra 54GB is being pre-erased as much as possible. however, if you were to do 100% writes you would eventually us up the pre-erase pool, and performance would drop. another background task is wear leveling which simply attempts to keep the the block evenly utilized for erase/writes.

the file system still only thinks it gets 146GB of space. more of them commodity drives only maintain a couple of pre-erase blocks used to wear leveling and erase/writes so the discrepancy isn't obvious.

DECUS Member 368596

dc_v01
From Boston, MA
Who joined July 29, 2005, 3:38 p.m.

Wrote the following at Nov. 24, 2010, 7:59 p.m...

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

Nothing in anything you listed, but perhaps he's simply making reference to the controller/drive manufacturers making utilities available to erase/refresh the drives even when the operating system doesn't natively support TRIM, such as Windows XP - I've only seen them for Windows myself.

In my own case, I run a trim supported drive under XP but can't use any of the utilities because they don't support the SATA drivers on my system. After using it for about a year, I'm sure it's a prime candidate for slowdown and any artificial benchmark would show a big hit. But I don't notice it with my typical usage, and it's still many times faster than when it ran with a mechanical disk - so I don't care. This is a disk that was supposted to be good in that regard (Vertex - one reason I purchased this model), but I'm guessing I'd feel similarly with an equally capable disk under IRIX.

Tabalabs
From Rio de Janeiro, Brazil
Who joined Nov. 11, 2010, 1:43 p.m.

Wrote the following at Nov. 24, 2010, 8:54 p.m...

A nice combination is a SSD drive for OS/apps and maybe /usr and an usual SCSI drive for swapping.

If you can justify the price of a SSD, maybe you can afford enough RAM, so swap wouldn't be needed.

THE dream come true: Silicon Graphics' Octane

Octane R10000 225MHz, 2GB RAM, 1x36GB HDs, 21" monitor, SSI (no TRAM) graphics

mila
From Bålsta, Sweden
Who joined Dec. 31, 2009, 4:20 a.m.

Wrote the following at Nov. 25, 2010, 12:54 a.m...

I would say that unless you have a filesystem that works works well with SSD drives read is where you get the best performance of them.

Say if you have a webserver,streaming, install server and so. The "SSD firmware house keeping/defrag" that skywriter writes about may help some but
I doubt that the drive will work for a real-time app.

I have tried to use SSD for a real-time app storing videocontent which comes continously to the drive but it did not work well, or did not work at all I should say since the video capture driver did not buffer enough!
The reason for my trying was that I had to be able to stream out(random parts) aswell so seektime was very important in order to not case frame drops.

--
No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own
risk.

rusti
From Brussels, Belgium
Who joined Nov. 29, 2009, 2:20 a.m.

Wrote the following at Nov. 25, 2010, 4:07 a.m...

I think the OP gave three reasons why he wants to put an SSD into his Indy:

1) It would be screaming fast - this is obviously disputed and due to lack of experience / knowledge I will not comment

2) It will be silent - I think we can agree this is the case

3) It will keep him from having a disk crash ever again - This is what I would like to comment. AFAIK these flash storage things have a maximum amount of write operations before thay, too, can very well fail. Is this number so big that you can rightfully assume that in a real life application the SSDs will last indefinitely. From what I read so far I got a different impression so I am curious why nobody ever commented on this assumption.

Current inventory: :O2:

Former members: :PI:

mila
From Bålsta, Sweden
Who joined Dec. 31, 2009, 4:20 a.m.

Wrote the following at Nov. 25, 2010, 4:15 a.m...

rusti wrote: I think the OP gave three reasons why he wants to put an SSD into his Indy:

1) It would be screaming fast - this is obviously disputed and due to lack of experience / knowledge I will not comment

2) It will be silent - I think we can agree this is the case

3) It will keep him from having a disk crash ever again - This is what I would like to comment. AFAIK these flash storage things have a maximum amount of write operations before thay, too, can very well fail. Is this number so big that you can rightfully assume that in a real life application the SSDs will last indefinitely. From what I read so far I got a different impression so I am curious why nobody ever commented on this assumption.

You are absolutely right that the lifetime of a SSD is limited in some ways, like the amount of writes. This is also a reason for having "extra space" on the SSD to compansate for it.
The good thing about SSD is that there is no moving parts so if you read ALOT(say streaming servers) it will not affect affect the lifetime compared to a HD which will fail pretty quick if it a heavly loaded server.

--
No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own
risk.

GL1zdA
From Warsaw, PL
Who joined Dec. 31, 2009, 3:18 p.m.

Wrote the following at Nov. 25, 2010, 5:56 a.m...

rusti wrote: 3) It will keep him from having a disk crash ever again - This is what I would like to comment. AFAIK these flash storage things have a maximum amount of write operations before thay, too, can very well fail. Is this number so big that you can rightfully assume that in a real life application the SSDs will last indefinitely. From what I read so far I got a different impression so I am curious why nobody ever commented on this assumption.

But there is one, very important difference - after it reaches the maximum number of writes it will become 'read only' (not only by Ontrack).

jan-jaap
From Wijchen, The Netherlands
Who joined June 17, 2004, 11:35 a.m.

Wrote the following at Nov. 25, 2010, 6:28 a.m...

mila wrote: 3) It will keep him from having a disk crash ever again

This is an illusion. Anything can fail, including SSDs. The Indy itself can fail in subtle ways, corrupting your data for a long time before you realize that something is wrong (bad memory, bad scsi controller, bad cabling, ...). If you value your data, you make backups.

The tricky bit with harddisks is that you cannot buy a new SCSI disk for an Indy anymore because new disks are all SAS. You don't want to buy something second hand that may fail any moment. SMART data should tell you how many hours a disk has been used, but you will not know before you buy the disk. Some of the newer models have FD bearings so they are very quiet and should last longer.

I've had good results with Seagate 15K.3 and 15K.4 disks. You can buy many of those for the price of one SSD plus SATA-SCSI adapter.

Now this is a deep dark secret, so everybody keep it quiet

It turns out that when reset, the WD33C93 defaults to a SCSI ID of 0, and it was simpler to leave it that way... -- Dave Olson, in comp.sys.sgi
Currently in commercial service:

(2x)

In the museum : almost every MIPS/IRIX system.
Wanted : GM1 board for Professional Series GT graphics (030-0076-003, 030-0076-004)