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