SGI: Hardware

A slight further update on SATA DVD-RW drives. Ran thru some cdrecord atempts as follows : have two DC-writers, one an LG on a Yamadapter and the other a SATA Pioneer. First the Yamadapet on scsi bus :


now the unsuccessful attenmpt on the SATA bus :



The CD "written" on SATA is unreadable. Any SCSI experts can gather some clues from this ? It seems like it is close but jaan-jaap can save his virtual cigars still

I've worked a fair amount with LSI SAS chipsets over the last few years - some notes:

I don't have a Fuel so I can't do any tests with the card in an SGI.

1. The 1068 A0 rev is indeed a prototype chip, can't run new versions of firmware. I would not suggest buying any cards without knowing it had an A3 rev or greater 1064/1068 chipset, the previous revs were protos and were never released to the public.
2. Most of the SAS3041X-R boards I've seen have the A3 rev chip on them. (These are all low profile cards and come with a low profile bracket or full height bracket.
3. There was an issue with SATA dvd drives that I believe was fixed in the newest versions of the firmware for the 1064/1068 A3 and 1064e/1068e (pci express versions of the same chip) B2 & B3. No idea if this would fix the problem in IRIX though.
4. There should be no problems using the firmware posted on the LSI website for the Sun & HP OEM versions of the cards as long as you pick the correct chipset type, you can flash in a PC booted into DOS with the files on the LSI website. These flash updates also update the fcode for using the cards in a Sun SPARC system.

Quick update for those who may have missed my other post...

My Fuel now has a 120GB SSD, full details here .

Meanwhile, the fastest mechanical disk I've tested with an LSI SAS/SATA card is the Seagate 450GB 15K SAS (15K.7 series),
model ST3450857SS (I have several for sale if anyone's interested). Here's the diskperf, tested with a Fuel/900 using a SAS3442X-R:




And here's a diskperf for two of them, using a SAS3080X card in a Fuel/900:




Do check the SSD results in my other post though, the results are interesting to say the least.

Ian.

Not bad, my turn.



4xIP53@1Ghz, xvm raid 0+1, 4xST9300653SS.

Cool!!

What controller setup was this using? One card? Two cards? And in which slots?

Ian.

mapesdhs wrote: What controller setup was this using?

mapesdhs wrote: And in which slots?

Let's take this thing up a notch, with raid0, same hardware configuration:

That's more like it! Btw, what model cards are they? 3442X-R? 3800X?

Any tips on how you setup the RAID in XVM? So far I've only used xlv-make because I've
been focusing mainly on video I/O, but soon I want to experiment with RAID0 for general
use, so I'm assuming XVM is better for that.

Ian.

what model cards are they? 3442X-R? 3800X?

3800 rebranded, but probably identical to the LSI one.

Any tips on how you setup the RAID in XVM?

I'm going to try cxfs this weekend.

For completeness, I have run an identical diskperf benchmark on a single drive, to understand, perhaps to some extend, the xvm "overhead", those results are shared below:

Thanks!!

I'm a bit stuck for doing such tests atm, I don't have enough suitable drives, though I will do soon once again,
should have 6 x Seagate 600GB 15K SAS.

I'll also be testing with 4 x OCZ 120GB Vertex3 MAX IOPS SSDs, though earlier tests suggest performance
with IRIX is better with the Vertex2E. Here's a diskperf run in my /var/tmp (note the 4K random I/O compared
to your RAID0 test...



A 60GB V2E holds the root filesystem, but /var and /usr are on a 120GB V2E via a SAS3442X-R.

I also need to find another 3800X, only have one now, unless I can construct another 2-port breakout plate for a 3080X.

Ian.

Ian,

Impressive results.

I currently use those 4xSAS drives for backups (where streaming matters) with Amanda on IP35.

I'm satisfied with those results; although I might also include some large SATA drives for long term backups; while the SAS will be for the daily backup tasks, which are mostly incremental per nature.

I wasn't sure how to handle backups for a while, given the mix of devices in my Fuel (three SSDs, 600GB 15K SAS, 1TB SATA).
The third SSD (another 120GB Vertex2E, the early 3.5" version) holds my main 'ian' user account. The 1TB is my movie archive,
mostly backups of orig DVDs atm (the disk is a Samsung F3); I'll upgrade this later to 2TB when it starts to fill up.

In the end I bought a Startech 4-bay 5.25" enclosure, which can hold four 2.5" SAS or SATA devices. I'm going to fit it with
a 500GB SATA (two rotating backups of overall root), a 120GB V2E (/ian backup), 750GB SATA (backup of the SAS) and a
1TB SATA, all 2.5" devices. The Startech will be in an external 5.25" enclosure, the idea being that it uses minimal power.
Can't fit it inside the Fuel (bays taken up with CDRW & DVDROM) and wouldn't want to anyway; the external link will be
via a SAS cable to the 3442X-R, so it'll only use power when necessary. Nice & compact. And if whatever unit I use can't
handle the 4 devices at once, I have a couple of extra mini power PCBs removed from other units I can employ inside the
same case. Here's a link:

http://www.kikatek.com/P147865/SATSASBA ... e-2-5-inch
http://www.startech.com/HDD/Mobile-Rack ... TABAY425BK

I spent some time trawling 2.5" SATA specs, speeds & power consumption:

http://www.sgidepot.co.uk/misc/hdsummary.txt

The tables are ordered by best power consumption under load, but include ranks based on write performance, so one can judge
the best tradeoff of power vs. speed, and price.

Ian.

I use this same startech in my tezro, in place of the dvd; with those 4xSAS I benchmarked above.
Cool setup; but I could use the fuel to get 8 like that.

Oh!

True, the Fuel could hold 8. I don't like the idea though that they'd always be powered on,
thus the external case. Longer device life.

Ian.

mapesdhs wrote: True, the Fuel could hold 8. I don't like the idea though that they'd always be powered on, thus the external case.

If you want to have data "always" available to your Irix box (regardless what constitutes your dataset: movies, isos, documents, pictures, archives etc.) I suggest that you give DMF (Data Migration Facility) a try (documentation id #007-3681-019). It would allow you to use local or remote destinations to store files, which would be migrated on demand, in a transparent manner.

In a nutshell, under a xfs filesystem with dmf attributes:

mplayer ian.avi

The file ian.avi, if not locally present, will be automagically retrieved from either tape/ftp/nfs/xfs/cxfs/cifs... and, depending on your policy, sent back (if modified) to the remote location (which can be a windows, osx, openbsd or linux server if you want, it doesn't really matter); or even to multiple locations (great for online data mirroring). To you, it will be entirely transparent, if your network is slow, a disk cache (on a separate filesystem/directory) can be added to the mix. While this is not really a backup solution, it's a convenient way to unify "archipelagos of storage", in a transparent manner for the user, and requiring no administration overhead.

Policies can be set based on uid, file size, disk space left, etc. it's very versatile. It's meant to handle a lot of data, think NASA-large datasets, where you can't obviously store everything on a single disk, or even a few of these; if the data is modified, it will be pushed back to the remote store(S) (singular or plural) based on a weight factor (assuming you have rights to modify the data). Those "remote store(S)" don't have to run irix (but they can), so if you need cheap storage readily available on irix without the disadvantages of NFS, you should look into this.

It's relatively trivial to setup DMF to automatically fetch a file from tape (movie?) when one request access (mplayer ian.avi) to this file, the end-user will not even know the data is coming from tape (unless you use a DDS3 perhaps, heh).

At least, it's worth investigating; I intend to deploy it for data rarely accessed, which I don't want to keep on NFS; simply because NFS, despite its advantages in unix-land, doesn't offer a great way to replicate the data amongst remote stores (unless if you use EMC/Netapp/Hitachi asynchronous mirroring).

To store data (remotely) DMF supports: NFS, FTP, CXFS, XFS, SMB/CIFS; it's a transparent filesystem migrator. Data can be pushed (and pulled) to offline media as well, assuming it's used conjointly with openvault or tape management facility; but most commonly, the secondary storage can be any bulk-storage device accessible through NFS or FTP. Data is verified (checksumed) on the fly.

So rather than spending a lot of money to store a lot of data on very fast storage, you can automatically tier it, data will be automatically migrated between fast and slower drives (or stores) in a transparent way.

To sum things up, in your case, you could have a primary storage on SSD, secondary storage on SATA or SAS, to the end user, it's a single filesystem with absolutely no way to know it's automatically tiered. Cool no?

Hmm, nah, TBH the delay when doing things would really annoy me. Plus, I don't have enough active systems for such a thing to be
worth doing yet, really only the Fuel atm.

Thanks for the info though! I didn't know that's what DMF was for.

Ian.

Ian,

Understandable; of course. I like to throw those things to give people new ideas or different viewpoints.
It's cool however that DMF is available for Irix, it used to be mostly on big Unicos systems (Cray C90 & J90 and such) with some relatively big tape transports (thousands of slots in silos). In other words, it's good to see software that was available on systems worth tens of millions of dollars come to "affordable" workstations.

Even for "standalone" systems, it makes sense to tier between SSD/SAS and SATA (no network connection necessary, all XFS); and it's well supported by xfsdump/xfsrestore.

In any case, I'm still curious to hear what you're doing for backups these days, I imagine one cannot talk storage without mentioning backup strategies.

For the Fuel, the Startech unit is basically it. The only other often-used SGI I have atm is my gateway O2, and that just has
a 2nd disk for cloning every now & then (very little changes on it, just running ipfilter). All my other 'for keeps' SGIs are not
really setup properly yet (original Effect O2 with all manuals, general R7K/600 O2, quad-1gig Tezro, Octane2).

Ian.

mapesdhs wrote: For the Fuel, the Startech unit is basically it. The only other often-used SGI I have atm is my gateway O2, and that just has a 2nd disk for cloning every now & then (very little changes on it, just running ipfilter). All my other 'for keeps' SGIs are not
really setup properly yet (original Effect O2 with all manuals, general R7K/600 O2, quad-1gig Tezro, Octane2).

You seem to prefer using the Fuel as your primary workstation, while you own a 4x1Ghz-IP53, is it just a color preference?

Why would I use the Tezro? I'm mostly dealing with emails, web stuff, etc. The Tezro is for video, which atm
I don't have time to do. Since it's often convenient to leave the system on while I'm doing stuff so I can constantly
check things, power consumption is definitely an issue for me.

At one point I'd hoped to use the O2 as a mostly-on main desktop, but it's just too slow running Seamonkry/Firefox
(NB: my Fuel launches Seamonkey in just under 2 seconds now).

Ian.