Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Sun, Dec 18, 2011 at 06:48:53PM +0100, Goswin von Brederlow wrote:
> Josh Triplett <josh@joshtriplett.org> writes:
> > On Fri, Dec 16, 2011 at 12:13:55PM +0100, Goswin von Brederlow wrote:
> >> Josh Triplett <josh@joshtriplett.org> writes:
> >> > Russ Allbery wrote:
> >> >>Josh Triplett <josh@joshtriplett.org> writes:
> >> >>> In all of the recent discussions about separate /usr partitions, most
> >> >>> people seem to acknowledge them as unusual, special-purpose
> >> >>> configurations, even those who use them. To the extent they have a use
> >> >>> at all, they primarily have a use for people who have very specific
> >> >>> reasons for wanting them, and all of those people will know how to
> >> >>> handle partitioning. To a lesser extent, that holds true for having
> >> >>> separate partitions for /var, /tmp, or other top-level directories. It
> >> >>> seems likely that any such setup will have custom requirements.
> >> >>
> >> >> I don't think these things are alike. Separating /var and /tmp from the
> >> >> rest of the file systems is done because those partitions contain varying
> >> >> amounts of data and often fill if something goes wrong, but can fill
> >> >> without impacting the rest of the system and allowing easy recovery if
> >> >> they're not on the same partition as everything else.
> >> >
> >> > Exactly what I had in mind when I said "To a lesser extent". :)
> >>
> >> There are strong reasons for a seperat /tmp and /var partitions. Most
> >> importantly because both are writable and written to.
> >>
> >> /tmp should default to tmpfs and D-I should not create a partition for
> >> it normaly. There could be recipies for a sperate /tmp partition but it
> >> shouldn't be the default. I agree that people that need a seperate /tmp
> >> partition will know that they do.
> >
> > As far as I know, /tmp currently does default to tmpfs.
> >
> >> As for /var that should be a seperate partition. The default setup
> >> should allow / to be mounted read-only even if that isn't the default.
> >> Besides that it also reduces fragmentation and lessens the risk of
> >> filesystem corruption on /. Overall it is a good idea and having it a
> >> seperate partition is no burden for the normal user.
> >
> > I disagree; I think it leads to a significant burden. Having /var
> > separate requires pre-determining an appropriate size for it, and that
> > will vary wildly between systems. At a minimum it needs enough space
> > for /var/cache/apt, which can grow to many gigabytes. Servers with mail
>
> Dude, run apt-get autoclean in cron daily. :)
Doesn't happen by default. I've encountered a number of users who
didn't know about /var/cache/apt at all, and as a result they had quite
a pile of wasted space there, contributing to their nearly-full disks.
> > spools (/var/spool/mail), large websites in the default location
> > (/var/www), or large databases (/var/lib/postgresql or similar) will
> > need a lot more. The same applies in reverse, when /var has space to
> > spare but other partitions don't. And even experienced sysadmins find
> > it painful to either resize disk partitions or create magic bind mounts
> > to partitions that have space.
>
> lvresize, resize2fs, done
Doesn't make it any less painful. (Also, don't forget the resize2fs and
lvresize of some other partition first, and figuring out the appropriate
amount of space to move around.) This also assumes LVM, which we don't
default to.
> > Now that the Linux kernel supports read-only bind mounts, making /
> > read-only does not actually require having separate partitions for
> > /home and /var.
>
> How would that work? Mount / somewhere temporary, read-only bind mount
> it to /real-root, read-write bind mount /var to /real-root/var (same for
> /home) and only then have the initramfs run-init?
Or just mount / over itself read-only, with /home and /var bind-mounted
read-write.
> > In any case, this doesn't seem like an argument against the bug I've
> > filed here; you don't seem to advocate the particular guided
> > partitioning option I've proposed the removal of. :)
>
> Only to the extend you recommend. The proposal to not have a seperate
> /usr partition seems sound. But lets just stop there for now.
While I'd still prefer removing the recipe in question from the guided
partitioner, I'd settle for removing /usr from that recipe.
- Josh Triplett
Reply to: