Be wary of file integrity checkers

So, the other day, we were having some network trouble and our servers were unreachable off-site for about 5 or 6 hours, so I decided this might be a good opportunity to run a file integrity check on the hard disk drives in one of the linux servers that had a lot of data on it.

In windows systems, you can run "scan disk" and it will defragment your hard drive and there are also built in tools that will help repair file systems so that damaged files can be pieced back together and hopefully be usable. The experience that I've had with windows disk management/integrity assurance has been non-eventful...they just have done their job and if they couldn't make things better, they would just give up and not do anything.
However, that is not the experience that I had when I ran ICE ECC a few days back on the linux server. I'll talk about three areas of critique: speed, functionality, and end results.

O.k., first speed. The check only took around 2 hours to cull through about 40 GB of data, which seemed really fast to me. In windows, I can remember it taking 10 hours or more to go through much less data and hard disk space. So, in the speed category, I'm impressed.

However, the next two categories: functionality and end result, I'm not very pleased with. With functionality, the first thing that it did was it made a backup copy of all of the data on the disk by creating a small partition and calling it: /old-root, then, it went through and ran the file integrity check on the hard disk drive and files it considered were o.k., it copied to the main partition for future use. After all this was said and done, the files got renamed this wierd user...USERID 499, which had a common name of "pulse" and group name "pulse-rt". When I rebooted, everything came up fine, except there were some odd things that I'm still trying to fix...such as since the file permissions got changed to this new user, some services didn't start right or if they did, certain pieces didn't work. Also, it just makes me paranoid about what else might have been messed up, because...there were certain files that didn't make it over during the integrity check. A colleague found some important ones that didn't get copied over, but how many more could there be? So, for the end result category, we do have a faster system (disk I/O before and and now shows a 3% increase in speed), but this came at the expense of not everything running right after the check.

ICE is open source freeware, and maybe it did exactly what it is supposed to do, but at least some kind of warning about what it did would have been nice in this instance. Am I going to run file integrity checks in the future? Yeah, but I'm going to stick with the the tried and true e2fsck instead of any fancy-smanshy tools that claim they are better and more advanced. Sometimes, simple is better!

my two cents

Not Quite Crappy, But Still Confusing

I just bought an Apple Time Capsule this week (and, boy, did Apple ship it fast! Received it three days after I ordered it!). I bought it mostly for its ability to automate back-ups to its own hard drive, but also thought it was cool that it is a router containing the next gen of wifi ("N").

I ran into a confusing bit as I tried to set up its DHCP, however, and thought I'd include the solution here in case there are others in a similar situation. My problem is that my two printers, which happily hung on my previous network (a combination of wifi and wired connection), were nowhere to be found on the new, Time Capsule-based network.

The solution lay in the DHCP range, or, as it puts it in Airport Utility:

DHCP Beginning Address
DHCP Ending Address

For some reason I haven't been able to figure out, Apple has the beginning address default to 10.0.1.2 and the ending address defaults to 10.0.1.200. What this means is that all IP addresses on this internal network fall in that range: 10.0.1.2 to 10.0.1.200.

My printers, however, are at static IP addresses of 192.168.0.201 and 192.168.0.202. Hence, they fall outside the range. But the thing is, I've installed probably three or four routers at my house and the range of each of those routers was always 192.168.*.*. So why the heck has Apple chosen such a low range? Any answers? I'd truly like to know, but Googling the issue hasn't revealed the answer.

Once I tumbled to that off-beat DHCP range, I was able to use Airport Utility to change the beginning/ending addresses to 192.168.0.2/192.168.0.200. Now, the printers work just fine because they're on the same subnet as the DHCP addresses. And, since they're above *.*.*.200, there are no DHCP conflicts.

I wish Apple had been clearer about this!