[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

On Wed, Dec 21, 2011 at 07:16:53PM +0000, Roger Leigh wrote:
> On Wed, Dec 21, 2011 at 07:08:17PM +0000, The Fungi wrote:
> > On 2011-12-21 10:42:56 -0800 (-0800), Josh Triplett wrote:
> > > People expect that they can use all the capacity of their disk
> > > without having to take unusual steps like resizing partitions and
> > > filesystems. After installing Debian on a 1TB drive, "df -h"
> > > should say that you have just under 1TB of free space, not just a
> > > handful of GB.
> > [...]
> > 
> > Which is why I suggested that half the challenge with shifting that
> > paradigm is education, to reset those expectations among the user
> > base. I didn't mean to imply it would be easily accomplished...
> > after all, there's an entire computing lifetime of momentum behind
> > us which set the original expectation of all your disk being
> > formatted ahead of time.
> And things may change yet again in the future.  With Btrfs, one can
> have a single filesystem with multiple subvolumes.  The subvolumes
> can be mounted independently, and also snapshotted independently,
> but have a common pool for free data, so unlike partitions any
> subvolume can grow/shrink as required.

Ie, almost all upsides of LVM.

> I understand that limits will also be able to be set for subvolumes in the
> future.

Done but not merged into Linus' tree yet.

> This gives the ability to have multiple "partitions", but without the
> limitations and inflexibility of real partitions, or even logical volumes.

Basically, everything but some fragmentation concerns and the possibility to
have different filesystem types on different subvolumes.  And there's no
concern about running out of space on one subvolume while having plenty on
another, which is pretty much what this thread is about.

> With Btrfs, it would make logical sense to have dpkg-managed locations
> under a single subvolume (two if including /var), which would enable
> ~instantaneous checkpointing/rollback during upgrades.

/var has the problem of including three kinds of data:

* Most (by count) are things indirectly managed by dpkg.

* Some are ambiguous: apt cache, system logs.  You can argue for them to be
  included in snapshots, or not.

* User data (Postgres, etc).  I'd say these belong in /srv/ or such instead.

If we could split /var into system and user parts, it would be great.
On the other hand, I disagree with you that snapshotting multiple subvolumes
would be manageable.  It'd be a nightmare of multiple parts going out of
sync.  /etc, /bin, /lib, /sbin, /usr and /var [system] need to go together.

I kind of wonder if all of these couldn't be moved into /usr.

> User data in a separate subvolume would thus never be rolled back.

Snapshotting a subvolume doesn't recurse past mount points, so if your / is
a subvolume that includes /etc, /bin, /usr, ... and empty mount points for
/home and /srv, you can roll the system back and forward to your heart's
content without affecting the data.

> I've not checked it recently, but support for subvolumes in the d-i
> partitioner would be a nice feature for wheezy.

Hell yeah.  The most important part IMHO would be letting it place stuff
into a subvolume other than [filesystem]:/, even if you had no option of
mounting other subvolumes initially.

1KB		// Yo momma uses IPv4!

Attachment: signature.asc
Description: Digital signature

Reply to: