I always forget exactly how to do this…
echo check >> /sys/block/mdX/md/sync_action
…where mdX is the raid device name you want to check.
You can monitor the status of the check with cat /proc/mdstat
Gentoo turns 10 today, and so I figured I’d make a post about one of my favorite aspects of Gentoo: the world file.
Such a simple idea and yet most package management systems seem to lack it.
When you install a package, it gets recorded in the world file, but its dependencies do not. This means you can always figure out which packages you need/don’t need.
Contrast this with many other package management systems, who do not distinguish between packages specifically installed by name by the user and those pulled in as dependencies.
After some time passes and you install and remove packages, you wind up with a bunch of packages that you are not sure if they’re necessary or not.
With gentoo, you can simply do a
emerge --pretend --depclean
On an up-to-date system to see which packages the system thinks are no longer needed. You can then rerun without the pretend option if you don’t see anything necessary in the list.
With other package management systems this can be a pain in the neck. For instance, on debian, I used to have to go through dselect and look at each package and use intuition to determine if anything installed was no longer necessary. And with gem, the package management system for rubygems, I wind up maintaining my own world-file-like file list in a file I call required_gems by hand, then to remove unneeded packages, deleting every single gem, and then reinstalling the ones I have recorded in my required_gems file.
So all hail the world file and happy 10th anniversary Gentoo!
I’m in the process of learning Spanish and wanted to have something in Spanish to listen to.
I figured I’d try listening to the Spanish tracks from some of my DVDs for this purpose. The only one I have that actually has a Spanish audio track is Pulp Fiction and my Simpson’s DVDs.
To rip Pulp Fiction, I used the following command:
mplayer -alang es -vc dummy -vo null -ao pcm:fast -af resample=44100:0:0 -ao pcm:file=pf.18.wav -chapter 18-18 dvd://
This rips chapter 18. I repeated this for chapter 01 through 27. Note that you have to replace that number in 3 places in the command each time. I prefer to have it broken up by chapter for skipping-around convenience, but if you want it all in one file, leave off -chapter.
If you want to rip from a different language, change what you pass to -alang, or remove -alang for the default language.
You can then encode them with LAME if you’d like.
By the way, my chapter 16 is screwed up on my Pulp Fiction disc and won’t rip. If you have this DVD and don’t mind ripping the Spanish audio from that chapter for me, let me know. It’s the “Where’s my watch?” chapter.
Gather ‘round my children and let me tell you a tale
So I notice that 4 of my 2-disk raid1 arrays were degraded after a RAM upgrade on one of my servers. I checked which device was missing and it was /dev/sdd1 (/dev/sdd2, /dev/sdd3, /dev/sdd6 from other arrays, too, but I will only consider sdd1 from /dev/md1 for the sake of this tale.) Opening the case I saw that I knocked off one of the SATA cables. It seems like about 1 in 10 SATA cables that I encounter do not clip properly and slide off easily. The one that had been knocked off was at the SATA3 port on the mobo (which starts at SATA0, so it seems reasonable that it is /dev/sdd.) Anyways, I reconnect the cable, boot the machine, and mdadm –add the partitions back to the relevant arrays, like so mdadm /dev/md1 –add /dev/sdd1.
Everything looks great in cat /proc/mdstat
After a kernel upgrade, I noticed that the arrays started degraded again! I went ahead and mdadm –add’ed back the partitions, all looked well in /proc/mdstat.
Then I rebooted just to make sure that it would assemble properly on boot. It booted degraded once again.
So after trying lots of stuff such as clearing the superblock, zeroing the whole device, –stop’ing and –assembe’ing manually, I finally do what I should have initially done, which is a dmesg | less. (nothing peculiar was in /var/log/messages and friends)
In dmesg, the kernel tells you what it’s trying to do as it’s assembling the arrays. It finds all the partitions that could possibly be members of raid arrays. It then matches them up by UUID and tries to assemble them. So I first see the kernel considering /dev/sdd1. Ok, so it finds a bunch of partitions that doesn’t match up with it, then it mentions /dev/sda1 matches and will be considered (which was the working disk still in the array.) Then it finds more that don’t match, and finally, to my surprise, mentions that /dev/sdb1 matches and will be considered! So that’s three devices in a two device array. How does the kernel handle this? Well it chooses to use the last 2 matching ones it finds, so it doesn’t bother with /dev/sdd1 at all. It assembles /dev/sda1 and /dev/sdb1 into /dev/md1 but /dev/sdb1 isn’t “fresh” because it was actually the device who’s cable fell off. That’s right, the kernel now decided that the device at SATA3 on the mobo would be /dev/sdb instead of /dev/sdd.
To fix this, I simply had to
mdadm /dev/md1 –add /dev/sdd1 mdadm /dev/md1 –fail /dev/sdd1 mdadm /dev/md1 –remove /dev/sdd1 mdadm /dev/md1 –add /dev/sdb1
for each of the relevant arrays. Then it assembled properly on each boot.
The moral of this story: always do a mdadm –detail /dev/mdX BEFORE adding partitions to an array to make sure you have the proper device name of the failed device.