Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
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
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.
> > I still think the general statement applies: "It seems likely that any
> > such setup will have custom requirements.". Anyone installing a server
> > probably either wants one of the two other guided setups (all-in-one or
> > separate /home) or wants the manual partitioner because they have
> > specific ideas about which partitions and sizes they want. Thus, I
> > think the guided partitioner shouldn't offer a generic
> > pile-o'-partitions option, and particularly not one with a separate
> > /usr.
> >
> > - Josh Triplett
>
> Imho the default should be /, /var and /home as LVM LVs and /tmp as
> tmpfs. It is minimal but flexible.
I understand your point in general, and I do like the idea of making
read-only / easier. I also think, though, that the setup you recommend
here will lead to complex problems that prove difficult for many users
to deal with.
Now that the Linux kernel supports read-only bind mounts, making /
read-only does not actually require having separate partitions for
/home and /var.
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. :)
- Josh Triplett
Reply to: