Thursday, May 19
[root@naga ~]# iostat -k 60
Linux 2.6.9-5.0.3.EL (naga.mu.nu) 19/05/05
avg-cpu: %user %nice %sys %iowait %idle 0.24 0.00 36.99 62.77 0.00
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn hda 0.00 0.00 0.00 0 0 sda 1068.33 68366.46 1.04 3946112 60 sdb 1084.75 69425.36 0.00 4007232 0 sdc 1106.03 70785.86 0.07 4085760 4 sdd 1094.39 70028.55 0.90 4042048 52
Yep, 70 megabytes per second sustained from all four drives at the same time.
Interestingly enough*, sda and sdb are firmware revision 1.01, and sdc and sdd are revision 1.03, and are getting slightly better performance.
* If you're a geek.
I now recall that I actually worked out that point about the screaming interrupt possibly being fixed in more recent kernels some months ago, when the spluttage originally recommenced. (This was after rebuilding the system following the previous spluttage.)
However, when I upgraded to the latest-and-greatest-at-that-time kernel, it renamed my block devices.* My old kernel treated SATA devices like IDE devices, so they were named /dev/hdX, where X was some appropriate letter. However, since SATA only has one drive per channel, it actually skipped every second letter. Given the two channels of IDE on the motherboard† taking up hda through hdd, my SATA devices were hde, hdg, hdh and hdk. And then the drives on my PCI IDE controller were hdm through hdp.
Anyway, when I updated the kernel, it turned out that in th -
[Excuse me, something bad just happened. I was running badblocks again and it froze, apparently taking the disk offline. Doesn't seem inclined to bring it back, either. Unlike the old kernel, though, the system went neither clunk nor splut, which is at least some improvement.]
- in the process of patching this problem, they had changed things so that SATA drives were now pretend SCSI drives instead of being pretend IDE drives, and were now assigned device names starting with /dev/sda. Of course, my RAID arrays were built using the old device names, and so it, well, I believe the term is failed to proceed.‡
So I went back to the old kernel.
The very latest kernel, as it happens, takes care of all that, automagically fixing my RAID settings and bringing up the appropriate filesystems. Still borked, unfortunately.
[badblocks actually just reported in after a long nap, and then rolled over and went back to sleep.]
However, upon testing things with badblocks, or ϖ∂ as I like to call it, it seems that things are not much improved in terms of actually working. In terms of not bringing the entire system down, though, 2.6.10 scores major points.
So a win, more or less. Some more fiddling around for Pixy, and I'm probably still in the market for a good, cheap, four-port SATA controller. And don't mention the name "Highpoint", or I might be forced to bite you.
[Oh look, Lina just fell over. How about that. The one box that hasn't been giving me fits, and the place were all the munu backups are kept. Splut.]
* Equivalent to drive letters on Windows, except that on Linux you don't normally see them.
† Actually four, but I was only using two because the kernel I originally used didn't support the chipset for the other two.
‡ Some details of this might be wrong; I am going from memory here, and that is only slightly more reliable than my computers.
I've been fiddling with my old Linux box (Yuri) today, and splutted it twice. Or splutted once and nearly-splutted once; the second time I managed to get it to do a controlled reboot rather than having to switch it off.
This tends to happen whenever I do a very large amount of disk activity on my main RAID array - which is a degraded RAID-5, which is the main reason I'm doing all this messing about with the new computer and copying files back and forth and running checksums and so on.
What's interestink is that there are no disk errors in the log files. None. I do have the dreaded "screaming interrupt" message - rather a lot of those - but no disk errors. Which suggests that the disks are fine but I might need a new SATA controller.
Oh good, I think; a SATA controller will be cheaper and easier to install than a new hard disk. Then I looked at the prices. It would be cheaper for me to buy a whole new motherboard with four SATA ports than to buy an add-on four-port SATA controller. Except that it wouldn't be a Socket A motherboard, so I'd have to buy a new CPU as well.
Hey, look! Adaptec are selling a 16-port SATA RAID controller. Not that I need one, or anything...
Update: I just kicked off a run of badblocks, a Linux utility that checks your hard disk for bad blocks.* All happy happy, then screaming interrupt, then lots of bad blocks, and then splut. (Which makes three spluts, and I'm out.)
Update: A new kernel might fix the problem. Unfortunately, right now I'm at work, and the box is home and splutted, so I can't try it out. Mmm, remote kernel upgrades...
* The developer originally called it ϖ∂.†
† Well, that looked interesting on my screen at work, but it turned out that this was largely due to my fonts being screwed up. I didn't think that particular letter of the Greek alphabet looked familiar. Rather making a hash of a throwaway joke in the process...‡
‡ In case I've now confused you, I replaced the turned-out-to-be-boring-and-ruined-the-joke symbols with something else.
Wednesday, May 18
So I'm comparing some backups with the originals to see if they match (in which case I can zap the backups, because I now have backups of everything, so I don't really need to keep backed-up backups of backups), and the system is sustaining more than 50MB/sec from the two drives containing the originals and the backups respectively. Which is pretty nice.
Also, my GeForce 6600 just arrived. It turns out that it does do HDTV output, but it doesn't have the cute little backplate for it; it uses this adaptor thingy instead that plugs in to a min-DIN connector. Less cute, but it doesn't take up a slot.
The only problem remaining is that I now need to replace faulty hardware in both my Linux boxes, reformat and reinstall... Except that one is a backup of the other. So I have to rebuild one of them, copy everything across, rebuild the other, and copy everything back. Yay for rsync and gigabit ethernet!
Tuesday, May 17
I've kicked off a program to catalog every file on every disk on every one of my computers, including helpful data like MD5 checksums, image and video file resolutions, audio sample rates, and stuff like that.
It might take a little while.
Update: 750,000 files catalogued so far.
A GeForce 6600 (non-GT) is on the way to replace my X600 (non-XT). It won't, however, have the nice little HDTV output thingy that my X600 has. On the other hand, it will be 50% faster for running advanced 3D games like... The Sims 2... Which isn't available for Linux anyway.
I could have got a GeForce 6200 with half the speed and half the memory for 93% of the price, but somehow it didn't seem worthwhile.
Pixy's Tip of the Day: When you create an ext2 or ext3 filesystem under Linux, by default it will reserve 5% of the disk space for emergencies. On a one-terabyte volume, that's 50 gigabytes saved for a rainy day. And if you used the automatic partitioning option during the install, everything is one big filesystem, so you can't unmount it to fix it.
What's the tip then? You don't need to unmount it. tune2fs will work just fine on a mounted filesystem. tune2fs -m 1 will reduce the reserved space to a more modest 10 gigabytes, or you can use tune2fs -r to specify a precise number of blocks to reserve.
Monday, May 16
A few months ago, both of the RAID-5 volumes in my Linux box went splut, as is wont to happen here at Pixy Central. Through the use of Vile Necromancy, I was able to reconstitute the volumes even though they had suffered multiple disk failures.
When I tried to back them up, though, they went splut again.
Anyways, I have this new wizzy Linux box here with a terabyte of disk* and I have - oh look - a terabyte of splut filesystems on my old Linux box. So I can just copy them across† and then I can manually unsplut the old system the easy way.‡ Only problem is, the /pixy⊗ volume goes
splut clunk and dies when you try to read a lot of stuff (600GB, say) from it, so I decided to back up the /misa⊕ volume first.
Except I had a brain fart and typed in /pixy anyway.
And it's working. 390GB copied successfully so far. No spluts, no clunks. I think it hasn't yet noticed that I'm copying the Filesystem That Cannot Be Copied™ so I will tiptoe quietly away and leave it to its work.
Oh, and I just ran across Pixy's Tip of the Day for December 21, 2003. Thanks a lot, me. Though it ain't that easy to find old, reliable, well-supported PCI Express cards just yet. I thought an X600 would be reasonably safe - and maybe it's the card itself at fault. Yay for console mode, anyway.
And you know what? I still haven't played Knights of the Old Republic. I've even got the sequel now, and I haven't played the original. Considering that I've only recently caught up with games that came out in 2001, I may be a while yet.
Update: Did about 490GB before it splutted. Oh well.
* Yeah, I know I said 500GB. Well, I was walking past the computer store, and these little voices started calling out to me, and the next thing I knew...
† rsync over ssh using blowfish, 17MB/s. Not too shabby.
‡ Wipe the bugger clean and reinstall.
⊗ Yeah, /pixy.
⊕ Of course.
Sunday, May 15
Fedora Core 4 Test 3 x86: Splut
Ubuntu AMD64: Installs successfully (the Ubuntu installer runs in text mode and is, frankly, crap), brings up nice graphical login screen, accepts my username and password, and then splut.
Windows XP: System doesn't even see the CD. Hmmm.
Looking for cheapish Nvidia PCI Express video cards now. Meanwhile I've left it running Memtest 86 just to make sure everything except the video card is good.
This makes three systems in a row where I've had trouble with the video card. My current Linux box, Yuri, couldn't cope with the GeForce FX 5700, though it's been happy enough with my old GeForce 4. My Windows box, Kei has had to have its video card replaced not once but twice. And now this. I have plenty of spare AGP video cards lying around - for obvious reasons - but this is my first PCI Express system so the parts bin is empty.
PC video cards these days seem to be Suck City.
Update: Installing Centos without X Window. At least I'll be able to use it, and I can update it later when I have a video card that works.
Centos crashes shortly after starting up X. Ungood. It's either the drivers that ship with Centos 4, or the video card. Given that I've had two flaky video cards in two years, my bet is on the card.
As a test, I'm going to try installing Fedora Core 4 Test 3, which should have the very latest of everything. I'll know soon enough.
It's just a little annoying, because this computer was delayed for two weeks while I waited for the video card to come in, and then I changed the order to a different model (costing an extra $60) which was supposed to be available the next day but actually took another week to arrive, and turns out not to work.
Maybe it's a 64-bit driver issue. I'll try again with a 32-bit version of Linux tomorrow. That does kind of defeat the purpose though.
All assembled, plugged in, and booted into BIOS. CPU speed reports as 200MHz, which is a bit of a worry...
Time to burn myself an operating system and do a little installing, I think.
57 queries taking 0.134 seconds, 355 records returned.
Powered by Minx 1.1.6c-pink.