Darkavich's Daily Ramblings Ramblings of a Mad Sys-Admin

July 25, 2010

Sync complete

Filed under: Muggle Tech — Darkavich @ 8:52 pm

The data sync finally finished. A total of 6 days to transfer 845 gigs of data. Not really speedy, but at least it’s all back online. Most of what I was copying was Time Machine vaults, so I was not too concerned. I was able to point the mac clients at the new vaults and all the history was there. Hurray for small wonders.

Now I will work on creating my secondary data syncs so that it will be easier the next time. I will perform some speed tests to try and find out why the Drobo’s can’t get full speed.

almost done syncing, and an X-Raid observation

Filed under: Muggle Tech — Darkavich @ 10:20 am

The sync’s are almost done. I am only getting 5-8MB/s. The max is supposed to be 25MB/s. Clearly there is something wrong with one end or the other. At this point, I don’t really care until the sync is finished, then I will run some I/O tests to see if I can figure out where the bottleneck is. During the 1st sync, I ran out of disk space and had to add a third drive to the ReadyNAS. This drive was larger than the 1st two. I expected it to add it like the Drobo, but what Netgear calls X-Raid vs what Drobo calls X-Raid are two completely different animals.

On the Drobo, when you add a new drive, larger or smaller it will level the drives so that you get the max-possible space available. On the Netgear, it will level the drives so that they equal the same size as the smallest drive in the array. What this means is you have to have all the drives be the same size in the array if you want to use the max space. The good thing though is that once all the drives are the same, it will level them up to the max size again.

I am looking forward to putting this behind me and getting some real work done.

July 20, 2010

one drobo down, one to go.

Filed under: Muggle Tech — Darkavich @ 9:38 am

My first Drobo has completed it’s syncing. I have moved all the data off to another host. I broke my rule and went to fry’s for a new array. I picked up a ReadyNAS NV+. Nobody else had one in town. Man, sales tax has gone way up from the last time I have bought electronics.

I setup the system and started my rsyncs. This morning, I reviewed their status and ran into some permissions problems. Apparently, the group ID’s didn’t match so it could not “chgrp” the files. Not a big deal, just changed them on the local drive and re-sync’d. I ran into an interesting issue. I normally do a “du” to confirm that the right number of bytes copied over. I was getting larger values on the destination than the source and was scratching my head. It turns out that every directory was a larger size than the source. The source is an HPFS+ volume and the destination is an AFP volume. Apparently the AFP volumes have more attributes than HPFS+ so the inode needs to store more data and hence the file is bigger.

I only have two more volumes to copy but I now need to figure out how to move the Time Machine sparse bundles over to the ReadyNas as the volume for TimeMachine doesn’t appear to be a normal share.

the recovery continues.

Filed under: Muggle Tech — Darkavich @ 9:32 am

After repairing the volume, I was still unable to mount the volume. Turns out the journal was corrupt. Again, I don’t get how this can happen. I was able to issue the following command:

% /System/Library/Filesystems/hfs.fs/hfs.util -N /dev/disk1s2
Turned off the journaling bit for /dev/disk1s2

I then re-ran the fsck option and then remount the volume. It complained again that the volume was corrupt, but this time let me mount the volume. I am now syncing the data over to a new set of drives so that I can re-purpose these drives.

July 19, 2010

thank you sooo much SDG&E!

Filed under: Muggle Tech,Things Peeves Would Do — Darkavich @ 2:47 pm

Please note the sarcasm 😉

Today, I was awoke to the sounds of UPS beeps. Apparently, today was the day they planned to swap out our meters for the 3rd time. Well I figured everything would be ok since most of my equipment is all on UPS.

Well I discovered that two pieces of equipment (My mac mini and one of my drobos rebooted.) I will be checking the cables and battery on them later today. After the mini rebooted, the Drobo volume did NOT mount. It saw the device and the volume, but refused to mount. I ran the DiskUtility software and did a disk repair but it failed.

So I brushed up on my UNIX skills and tried to fix this manually. I ran “fsck” but it reported a bad super-block, I tried running with an alternative super-block and that failed…. I then learned that fsck is not always successful and you should run “fsck_hfs”. I ran this and it complained that the catalog was corrupted. Huh? I thought I had a journaling file-system, this should never happen. 99.9% of all articles on the web claim I am totally screwed and to re-format and restore.

Well that’s the stupidest thing I have heard and I dug into the manual pages. I found an option “-r” that rebuilds the catalog. So far it has been rebuilding for the last two hours. It’s encouraging as it’s way past the point of where it failed before. Because this is a 650 gigs worth of data, it may take several more hours. Unlike Solaris and Linux it doesn’t give me any idea on the progress, so I just have to wait it out.

Once this is all done, I plan to consolidate all of my data onto a single Drobo and use the 2nd unit as an rsync copy. Ultimately (when I can afford it), I plan to purchase an eSata array and plug that back into a Solaris host and run ZFS on it.

Older Posts »

Powered by WordPress