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 07:34:16AM +0100, Christian PERRIER wrote:
> (reducing CC as I guess that most are subscribed to -devel)
>
> Quoting Russ Allbery (rra@debian.org):
>
> > 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.
> >
> > Separating /var continues to be good and recommended practice if you're
> > running anything that's likely to produce a lot of output, IMO. (/tmp
> > should probalby just be tmpfs, but that's another discussion.)
>
> I'm inclined to follow this advice and would indeed propose that the
> "atomic" partman-auto recipe is kept, however without a separate /usr
> partition (discussions on -devel and the current practice convinced me
> that a separate /usr is seomthing that probably belongs to the former
> century..:-)
>
> So, would it be OK for participants in this discussion is we, in the
> installer, just drop separate /usr but keep the atomic recipe (which
> is not the default choice, by the way)?
Dropping /usr is a good idea, I think, and continuing to keep /var
separate would also be sensible.
Regarding /tmp, we're now defaulting to a tmpfs for new installs, so
I'm not certain if having a separate /tmp by default is a good idea
or not. I would certainly like for /tmp in particular (and tmpfses
in general) to become configurable through the partitioner, which
would then also check that sufficient swap is also allocated at the
same time.
Once we have /etc/fstab.d fully supported by mount (with the next
util-linux release, probably in early January), I will be looking
at making all the initscripts mountpoints currently hardcoded in
the init scripts like mountkernfs etc. into conffiles in fstab.d.
It would then be possible for the installer to edit these files
quite simply to change the defaults, perhaps using the partitioner
as a frontend.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Reply to: