Re: About to format the whole laptop, need some partitioning advice.
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
Reply to: