Mar
4
Installing a replacement drive and being unable to shrink a filesystem to fit to the smaller replacement drive. I encountered an interesting problem today - how to copy a large dataset containing many hardlinked files.
Hard links are used relatively rarely, and so don't normally cause an issue - however - there was an interesting solution using rsync..
At home I have a Red Hat, Fedora based server, which earns its' keep by serving a number of roles. The most fundamental facility that it provides is fileserver, with a pair of (mirrored) 160GB drives.
Earlier in the week one of these drives failed on me, which after finding that its' warranty had expired, I proceeded to order a replacement.
With the benefit of hindsight, I guess I ought to have ordered an obviously larger drive (say, 200GB). Without that piece of common sense.. drive replacements are always a bit of a lottery - especially when the previous make/model is no longer a viable option. Needless to say - the replacement turned out to be about 4GB smaller than the original.
Being a hardened Solaris geek, I guess I'm just a little too used to having the benefit of VxFS in production environments, which would have made shrinking the filesystem an absolute doddle.
However, with the aid of Google, it began to be clear that shrinking the existing ext3 filesystem so that I wouldn't truncate it on the smaller disk was going to be difficult.
"No problem" thinks I, proceeding to dump/restore the filesystem across onto the new disk. Shortly after, it dawned on me that this wasn't going to work and that I had a problem.
You see, amongst other things, this server acts as the backup server for my laptop using "BackupPC". BackupPC is quite simply an astounding piece of software, and suits my purpose absolutely perfectly.
The problem lies in the way that BackupPC stores its' backups on the filesystem - as it backs up files from clients, it MD5s the file and indexes the checksums, thereby identifying whether that file has been previously backed up.
If the file has been backed up already, it knows from the MD5 hashed index that it doesn't need to make another copy, and so just creates a hard link to the original.
And therein lies the problem...
In the backup pool, there can be files with literally hundreds of hardlinks, which, dump/restore (even tar) doesn't handle very well at all.. Rather than a 1MB file, with a hundred links, there would be one hundred 1MB files after I had finished copying.
It took me a while, but I spotted a previously unnoticed option to rsync:
-H, --hard-links preserve hard links
Ideal - kudos once again to the rsync developers..
Filesystem copied, my backups are preserved and the metadevice re-setup. Back in business.
0 Trackbacks