Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
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. :)
> 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
There will always be a war for space between partitions. No default will
fit all cases. So I only see two scenarios that work for the general case:
1) just one partition using all the space
2) LVM with partitions kept small and free space to grow them as needed
And I'm against having just one partition. But that is just me.
>> > 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.
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?
But I think that completly misses the point of having a read-only /. The
point is to have the filesystem mounted read-only and unaffected by
writes anywhere. A read-only bind mount only restricts access but does
not leave the filesystem itself read-only and safe from corruption.
> 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
Only to the extend you recommend. The proposal to not have a seperate
/usr partition seems sound. But lets just stop there for now.
MfG
Goswin
Reply to: