Non-sparkly shenanigans

[digitaldiscipline]

Upshot of the hard drive fuckery of Monday:

Suspect my old 1TB drive shit the bed, or was not happy being made part of the RAID0 array. WTFE, just going to nuke the array and go back to using a single drive as main storage.

Crucial stuff was successfully backed up to a spare drive I happened to have laying around.

Win7 has been reinstalled on the SSD drive (why do I have to disconnect all the others first? You installed just fine on the 64GB partition when that was present, why should it behave differently when I delete it and make the whole drive a single partition?). Now I need to reinstall ALL THE THINGS.

At least all my settings and shit, I can bulk copy from the backup.

I should not be sitting here saying "WHAT DO YOU MEAN 120GB IS NOT ENOUGH FUCKING SPACE FOR MY OS BOOT DRIVE AND MY PROGRAM FILES" - but Win7 is burning nearly 30 gigs between cache (16gb) and hibernation (13gb).... when the OS itself is a relatively-svelte 15GB[1]. Certain entertainment applications are just gratuitously oversized (I'm looking at you, Blizzard and EA Games - when your application is larger than the OS itself, you need to step back and re-evaluate the demands you make of your user).


[1] Alternative OS users who feel compelled to feel smug and superior can pre-emptively kiss my ass; I've been dicking around with Ubuntu enough to recognize that small kernel plus familiar GUI[2] has certain benefits, but none of those include the ability to do most of the "for fun" activities that comprise most of my computer's purpose in life. Perhaps it's a shortcoming of virtualization compounding the issue, but, yeah, I kind of *need* 3D acceleration to play video games.

[2] Despite the GUI, there is still enough CLI wrangling involved to make me throw up my hands and say, "I DID NOT CLAW MY WAY TO THE TWENTY-FIRST CENTURY JUST SO I COULD RELIVE THE 1970'S, JUST WITH ON-DEMAND FILE DOWNLOADS."

Comments

[hellsop.livejournal.com]

I'm tempted, sometimes, when I feel rich, to get a box, a drive, an SSD, and see if I can figure out how to convince the OS to install on the SSD as B:\, just so the fuckwitted installers and assumptions about what lives on C:\ can go deal with their own shit on a spinning platter. Nobody's had two floppy drives since 1992, really...

As it is, the comfortable minimum I seem to maintain for "C:" (as a concept) is about 150GB these days. That's OS, the applications/games that I mostly use right now and want to have access to. Annoyingly, 128GB SSDs are affordable ($150 plus or minus) and 256GB are ... less so ($400 more or less).

[etcet.livejournal.com]

Yep. 128GB reports as 111.8 due to parity losses. If I didn't have an irritating array of life expenses coalescing, I'd be tempted to RAID a pair of them, but that's currently on a substantially more distant economic horizon.

[y2kdragon.livejournal.com]

I have a strict policy about installing programs. If I cannot tell the program to install on my D: drive, then it doesn't go on my computer. I do have some things on my 60GB SSD, Firefox for one, AV / Firewall software, and a few choice small applications that I do want to run fast. Everything else goes on the 1TB main HD. Big enough for all my fancy toys, system backups, and any other junk I want to play with.

When I built my box, I only connected the SSD, so the OS would have to go there. Once that was up and running, I connected up the HDD, then had to remember to tell Windows that I wanted it to use it. So far, things are working nicely. Also, had to remember to tell the power management to NEVER power down the SSD as long as the system was on. I found out, the hard way, that if the SSD goes to sleep, not even a soft reboot will wake it up. Who knew SSD's were such sound sleepers?

I decided that, when I built this box, that I can wait for a program to load, but I want my OS and main stuff to not be in the way. I think what I built fits this concept well. Plus, anything I download is not likely to get zorched if the SSD goes. Now to buy a home NAS unit, so I can offload the full box backup, so I don't risk losing anything off of that HDD.

[etcet.livejournal.com]

It seems like Steam and its ilk like putting things on C:\. When I get around to reinstalling WoW, it'll go on the mechanical drive, but right now, at least one of my TB drives is dead (formatting for 10 hours only got it 15% done, via USB3 docking station; that's... not good)

I may be running light and nimble on the SSD alone if it's the only functional drive I have, because I'm feeling a bit wary about putting my 300GB drive with all the archived important shit in the rig until I move the SSD to the SATA-0 header (for some reason, if there's a mechanical drive present, it preferentially tries to boot from that; I'm hoping that doing some header juggling will preclude this stupidity).

[critus.livejournal.com]

You can change those settings in Steam. All of my Steam files install to D:

[etcet.livejournal.com]

I need to install a drive that exists as D: first. Heh.

[argonel.livejournal.com]

I will note that Blizzard and EA bring a lot more pretty to the table than what you get from the OS. For example my WoW directory is 26GB but I think that no more than 2GB is actual code. Most of that space is 3d models, textures, and media files.

[cassandrasimplx.livejournal.com]

I was going to make a cogent point building on yours, but now all I can think is, "Ky00t W33z1L!"

[critus.livejournal.com]

What the ferret said. You want pretty pictures, voice overs, music, and other fancy stuff you gotta pay for it.

[cassandrasimplx.livejournal.com]

In the defense of alternative operating systems, the hatred appears to be mutual. I've never seen anyone stonewalled so repeatedly by otherwise-reliable tools.

Of course, if you were already running Linux, none of that would have been necessary. And if you'd purchased your hardware specifically with running those games under emulation on a Linux box in mind, you would have all the 3d acceleration you could wish for.

My point? Linux is a cult, and you have to pay your dues before you work your way up the the levels that offer fantastic perqs. *buffs nails*

[critus.livejournal.com]

One question that Krys and I had when we heard of your woes - Isn't the whole point of RAID supposed to be that if one drive fails the other is still working and you can just disconnect the dead one?

Also - I suspect the reason you had to disconnect all the drives but the SSD one is the same reason I'll have to if I ever decide to take the plunge. Once you have a boot sector installed in a drive on your machine Windows will detect and use it, even if you're installing the OS to a completely different hard drive. It's annoying, but it is what it is. My boot sector isn't even on my C drive at this point. :/

[mighty-man.livejournal.com]

Critus, it really depends on what version of RAID you are running.
If it's RAID 0 (striping), the RAID size is the combination of each of the 2+ drives in the array. However, the data is cut into chunks and some of it is stored on each drive. The upside is that the data can essentially be read simultaneously from each drive, so your read/write speed is higher. The downside, is that if *any* of the drives goes down, your RAID is gone. (I've gone through two RAID 0 failures in the last 20 years, one was costly, the other, not so much).

If it's RAID 1 (mirroring), the RAID size is equal to the size of the smallest of the drive in the array. Identical copies of data are stored on each drive. If one goes down, no problem, you have a spare copy. Read/Write speed is whatever the read/write speed of the slowest drive. I believe this is the version you were referring to in your above post.

If you go to RAID 5 (parity), the RAID size is equal to that of two of the drives. The three drives each hold a portion of the data, so speed is equal to RAID 0 (mostly, there's a caveat). However, the data is essentially checksummed, so that if one drive goes down, the information can be recovered because the data on the other two is compared and the missing information can be calculated from the known checksum. So if the drive goes down, you pull it out and replace it and the array does calculations and puts the missing data on the new drive and you're good to go. Downside on this one? RAID 5 requires raw XOR computing power with every read/write to verify the checksum. The other downside? Once you replace the damaged drive, you can access the information pretty quickly, but it takes time for the array to restore the lost information and get back to full speed (can be in the days range with 3TB drives available now). Oh yeah, and you'd better hope that no other drive fails while the array is rebuilding, or everything is lost (this is heartbreaking, but happens occasionally in corporate).

My NAS runs a bit more exotic flavor (RAID 6) which involves 5 drives essentially running a pair of RAID 5. 3 Drives store the data and the other two are for parity. So if one or two drives fail simultaneously, I'm still ok.

[cassandrasimplx.livejournal.com]

That's exactly why I recommended he disconnect the other drives before installing: to force the boot files to a known and controllable location. However, I think there was also some intransigence on Win7's part, refusing to install to the SSD at all until it was the only drive available -- which confused us because it had been installed to that drive before in a multi-disk build.

The acronym RAID itself just means "Redundant Array of Inexpensive Disks" -- now used for "Independent Disks" instead; I believe that was another case of Microsoft's inability to adopt a protocol without marking it first -- as opposed to a SLED (Single, Large, Expensive Drive) or JBOD (Just a Bunch of Ordinary Disks); the number indicating RAID level is needed to convey anything about the purpose or architecture of the array.

The RAID level most commonly used in business settings is RAID-5 (or one of its conceptual progeny) and it's recommended because it will do precisely what you say. Right now, I have a 5-disk RAID-5 NAS with one hot spare. One disk has died, but all my data is still available (if I leave the NAS running) and when I replace the disk (which can be done while the NAS is running) the NAS will rebuild the contents of the damaged disk on the fly. This, along with its more-complicated versions, is ideal for installations where constant data availability even in the event of catastrophic drive failure is a priority.

Other RAID levels, as mighty_man touched on, have other goals. RAID-0 offers a speed increase, but no redundancy whatsoever -- the reverse, in fact, since as etcet's experience shows, loss of one drive in the array means loss of all data across all disks in the array. It's great for application or game partitions that store no critical files, only things that can be reinstalled or recovered from backups. It's terrible for archival since every disk in the array is a potential single point of failure for the whole array and its contents.