On Wed, Feb 05, 2014 at 08:27:15AM -0800, David Guntner wrote: > > It's not just a matter of capacity. I've got a 1TB drive, and I still > partition them into separate sections: > > > $ df -k > > Filesystem 1K-blocks Used > > Available Use% Mounted on > > rootfs 1818872 299704 > > 1426704 18% / > > udev 10240 0 > > 10240 0% /dev > > tmpfs 309540 12812 > > 296728 5% /run > > /dev/disk/by-uuid/36f6b922-0e9a-4ce5-aeee-c92104fa2428 1818872 299704 > > 1426704 18% / > > tmpfs 5120 4 > > 5116 1% /run/lock > > tmpfs 1049560 0 > > 1049560 0% /run/shm > > /dev/sda1 137221 20211 > > 109689 16% /boot > > /dev/sda12 67284600 16339432 > > 47527264 26% /home > > /dev/sdb1 307665016 40081124 > > 251955400 14% /backup > > /dev/sda9 28835836 351612 > > 27019444 2% /opt > > /dev/sda6 2882592 69908 > > 2666252 3% /tmp > > /dev/sda7 28835836 7400256 > > 19970800 28% /usr > > /dev/sda8 48060296 15360908 > > 30258020 34% /usr/local > > /dev/sda10 28835836 1455184 > > 25915872 6% /var > > /dev/sda11 28835836 179364 > > 27191692 1% /var/spool
While this works, it's suboptimal for a number of reasons, primarily being inflexible and space wasting. It's inflexible because should your needs change (e.g. you run out of space on /opt or /var), you can't do anything about it other than hairy repartitioning involving backup and restore of the data. It's also vastly more complex than it really needs to be. I've been bitten by this in the past. Firstly, when my fixed size /boot prevented kernel upgrades because two images and initrds would no longer fit (and the sizes keep getting bigger). Secondly, when the rootfs got too small and wouldn't allow package install/upgrade despite having gigabytes of space on /usr; there's no need to separate them, and it's much less likely to cause problems if they are together. So you're caught between two bad situations: preallocating sufficient space that you won't be caught out by size requirements increasing over time, and overallocation of space which is then wasted pointlessly. On Linux, there are three possibilities which mitigate all these things: 1) Use LVM. You can use the entire drive as a single physical volume (PV) and then carve it up into separate logical volumes (LVs). This allows exactly the same strategy as above, but you can start with the minimum needed size for each partition and leave the remaining space unallocated. Should you need additional space for any of the volumes, you can just extend it on demand. Downside: space allocation is manual and some degree of space wastage still occurs. 2) Use Btrfs. You can have a single Btrfs volume, and then use subvolumes for all the separate parts, divided up exactly as above. The subvolumes may be independently snapshotted, backed up and preserved. The rootfs itself can be a subvolume. The main problem here is that Btrfs isn't production ready, so I can't recommend it unless you don't care about your data. 3) Use ZFS. Allocate the drive as a single zpool. You can then create zfs volumes for all the separate bits. However, you don't have the space wastage issues since all the data is in a single pool, and you can adjust the size allocations/quotas on demand for each individual volume (or leave them unset to give them as much space as they can get). Needs a kernel patch for the zfs driver. With kFreeBSD you can do this natively. It has all sorts of great features which I won't go into here. I've tried all three. For Linux, using LVM is easy and can be done in the installer. If you reinstall you can keep the LVs you want and wipe/delete the rest. For kFreeBSD, you can install directly onto ZFS; I've been using it for kFreeBSD and native FreeBSD installs, and it's the best of the lot--hopefully Debian can offer native support for Linux at some point [currently needs patching, and the patches don't work with current 3.12 kernels] Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140209210544.gi11...@codelibre.net
