When my Toshiba laptop died, I knew that the hard disk I had was still good, and so I got the UltraBay HD adapter to go with my IBM Thinkpad. When the Thinkpad arrived, I declined the MS EULA that the laptop booted up with, turned it off again, and swapped in my old HD. Thanks to the fact that Linux (and NetBSD) do not have stupidly motherboard specific kernels (it’s EVEN WORSE with Vista. See: http://ars.userfriendly.org/cartoons/?id=20061106&mode=classic ) I can just move my hard disk to a new system.
Anyway, in fall 2005, when my motherboard blew up, it took my hard disk as well (I’d reformatted the IBM HD, and was now using that). I replaced the hard disk, and still have to RMA the original, and wound up with a 60G drive inside the laptop, and a 40G drive in the bay. Most of the time, this is the right combination, with the CDrom in the docking station. The I/O path to the ultrabay is a bit faster than the I/O path to the docking station, although you can’t boot from a cdrom in the docking station.
The question arises: where do you put your music? When I’m at my home office, the music is accessed over HTTP, so I don’t need a local copy. When I’m travelling, I’m often on battery. I’d prefer to have my spare UltraBay battery in the bay rather than my spare disk. On sensible airplanes, and on VIA rail, you get power, so you don’t need the battery. I think that I’ve now concluded that putting my music on my second disk is okay, but up to now, I haven’t done that.
The second problem is where to put the master Linux Kernel git tree. Until this past summer, with “git clone -s” (more on that later), one wanted to have kernel git trees on the same partition as one’s experimental trees, since they could share with hard links. I made the decision that if I was doing core kernel development (vs Openswan + UML), I probably had test machines, so I have power. So I put my kernel in /mara1/git.
The result is that up to today I had five ~8G partitions on my external drive. This is big enough to be useful for work like git, but small enough that I won’t loose too much at a time, and I can do backups reasonably easily. Generally, I like to either backup everything on a partition, or nothing. So if I have data on a partition which can trivially be recovered from the internet, I may not back it up.
This means that my laptop (whose name is “marajade”) looks like:
The problem with any partitioning scheme other than “put everything in one partition”, is that one can run out of space on one partition, and still have space elsewhere. This is very difficult for new users to deal with, but it can be very annoying for experienced users as well.
Of course, with everything in one partition there are other problems: you can have logs run away and eat ALL the disk space, and then you may have a problem, and you may not notice for perhaps even YEARS. If you have a file system error, you are out of luck. If you re-install your operating system, you likely LOOSE a lot of your data.
I had my secondary disk partitions mounted via the LABEL= hack so that they would be found whether the second disk was hdc (ultrabay), or hde (docking station). I marked them noauto, so if they aren’t present life doesn’t end, and have a boot script that runs mount on them instead.
After using the Logical Volume Manager tools a bunch to deal with Xen, I realized that I could have the best of both solutions. I wondered at first, if I could create a single volume group, and sometimes not have one physical volume, and perhaps could simply force LVs to be on one physical volume or another, and migrate stuff around as I need it. That doesn’t work, unfortunately, see: http://www.sandelman.ca/mcr/blog/2006/05/24#how_to_unscrew_your_lvm
My solution is two volume groups, and I was able to move data around a bit to free up a partition to make my first physical volume for each volume group, and then restore data. The end result is that I now have a /corp/projects/SOMETHING (primary disk), and /corp/projects/SOMETHING2 (secondary disk), for a lot of project related data. Note that I didn’t move my operating system or personal data. I’m still a bit hesistant about LVM, and in particular, my local kernel source (which I’d need to build LVM modules!) is accessible without LVM.
My new /etc/fstab:
What would be nice
It would be neat if there was a way to move a logical volume from one volume group to another, and do this in the background. I would do this by turning the logical volume into a RAID-1 ( http://en.wikipedia.org/wiki/RAID ), and letting the RAID-1 mirror the data. The trick would be to do this using the dm-mapper, changing the “plumbing” underneath, and when it was done, remove the RAID-1 settings, leaving the file system layer ignorant of the change.
It would also be nice to be able to resize the partitions without unmounting them. I think that one of XFS or ReiserFS-4 can do this. I use ext3 at present.
How I use git-clone
The new thing about git clone -s, is that it doesn’t use hard links, or soft-links, but instead sets up .git/objects/info/alternatives. This effectively reduces the cost of a kernel .git tree to the space for the checked out files (about 50M for Linux) and objects. I move my “Linus Torvalds” git tree to =/distros/kernels/linus.git=, and git clone it. I put that master tree on my primary disk, because then I always have it, while I can put as many kernels with object files on per-project places as I go.
(=/distros/kernels= is an example of stuff that I wouldn’t bother backing up, btw.)
It is my intention to even create partitions for specific projects as I need them, and remove them when I am done. The question will be, how in such a dynamic world, will I get all my backups to do the right thing.