Thursday, August 20, 2009


Today I got my RMA'd WD 1TB drive (the one I bought from craigslist is this strange unheard of Canadian model which only has 8mb cache and 5400rpm and it was broken... typical... Canadian...).

I've been using a Caviar Black, which sits at work, as my backup drive. Now I want to use the Black at home (replacing all 4 of my other drives) and take the Green to work.

The Black, however, is currently HFS+ Case-Sensitive formatted (ugh... try doing backups from Linux with case-insensitive... or don't).

I want the Green to be the same setup as the Black, but instead of using the good ol' fashioned way, I want to go through the pain of setting up a GPT partition and using the linux hfs tools.
dd if=/dev/sdb of=/dev/sdc bs=4M

So what's the first thing I do? I copy the partition table! I don't know what the size of a gpt table is, but I figure a meg will do it.
dd if=/dev/sdb of=/dev/sdc bs=1M count=1

Then I fire up cfdisk, which promptly declines to inspect the current gpt map.
I wanted to run gparted, but since my tablet runs XP (don't tell my friends) I had to install Xming-mesa first and turn on X11 forwarding in putty.

Oh, I guess I should mention that I'm storing all of my files on a headless server and I'll be replacing my primary desktop with this new (craigslist) tablet.
sudo apt-get install gparted hfsutils hfsplus hfsprogs
sudo gparted

Surprise! I can't use hfs+ because I don't have the right version of gparted. It turns out that my headless server isn't as up-to-date as I thought. Now I'm trying to figure out the name of the sources manager. So I find a screenshot on google and then decide to find the command by greping through all desktop files.

locate -i .desktop | while read FILE; do grep -H 'Software Sources' "`echo $FILE`" ; done
sudo software-properties-gtk
#sudo do-release-upgrade
dd if=/dev/sdb1 of=/dev/sdc1 bs=1M
sudo shutdown -r now

Well, an hour and a half is more than I want to dedicate to this right now, so I just do it from the commandline. Since I used dd rather than some sort of tool that can partition properly I have to restart for the kernel to re-read the drive. And, of course, I unplug the drive to be copied and double check which drive is which before doing anything drastic. I unplug it because when I was testing some things I copied the whole file table of the second partition and hence it thinks it has all of the files, but actually it just has the location of a bunch of zeros named as files.

mount /dev/sdb2 /mnt/black
sudo mkfs.hfsplus -s -v backup /dev/sdc2
mount /dev/sdc2 /mnt/green
rsync -avh /mnt/black/* /mnt/green/

Now that she's initialized, case-sensitive (-s), named (-v), and mounted, I copy everything over.

Well, it wasn't that much fun after all...

Next day:
A few files and folders couldn't be copied, some due to the utfmac problem (I have a music folder with Japanese characters in the name), others I don't know why so I left Green at home and took Black to work

First of all, being weary of any accidents, I run Apple's Disk Utility First Aid and Repair the disk.

diskutil list /dev/disk2 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *931.5 Gi disk2 1: EFI 200.0 Mi disk2s1 2: Apple_HFS Backup 931.2 Gi disk2s2 sudo diskutil enableJournal disk2s2 sudo diskutil disableJournal disk2s2

Then for fun, I run Disk Utility again now that the journal is turned off.
But I have to reenable it to resize the partition
sudo diskutil enableJournal disk2s2 HHPS-PROG6:~ hhpsprogramer$ sudo diskutil resizeVolume disk2s2 limits For device disk2s2 AJ_ONeal: Current size: 999860912128 bytes Minimum size: 575023239168 bytes Maximum size: 999860912128 bytes HHPS-PROG6:~ hhpsprogramer$ sudo diskutil resizeVolume disk2s2 450TB sudo diskutil disableJournal disk2s2

Then for fun, I run Disk Utility again now that the journal is turned off.

Tuesday, August 18, 2009

Copying MySQL from my Desktop to my Server

While I was copying /var/lib/mysql from one box to the other (it's a lousy way to do it, but it works), I noticed that there's a file called ibdata1 which is quite a bit bigger than any other file.

Apparently it's for all InnoDB tables and it only grows in size, it never decreases.

It can only be trimmed like so:

A very cumbersum way:
mysqldump all databases

Remove the ibdata1 file.

Start the mysqld process.
It will now recreate the ibdata1 table space since it recognizes that it is missing.

Import the sql dump from step 1 and you are back again.

If you're using the innodb_file_per_table option, then each InnoDB table gets its own .ibd file, so you can recover freed-up space in a table by rebuilding just that one table. The easiest way to rebuild an InnoDB table is to run the command, "ALTER TABLE tablename ENGINE=InnoDB;". However, this will build the new copy of the table on disk before dropping the old one, so you'll need to have enough free disk space to keep the entire second copy of the table. If you're tight on disk space on the database server (which is probably why you want to free up the space trapped in the InnoDB tablespace in the first place), then you can mysqldump the table to another machine with more free space and then re-import it back into the database server. It's still a pain to have to do that, but it's a lot better than having to dump ALL of your tables.

Access denied for user 'debian-sys-maint'@'localhost'
Had to find the password on the origin system in /etc/mysql/debian.cnf