[mythtv-users] Suggestions for a partition structure (Craig Cook)

[Simon Hobson]

James Linder wrote:
>eg the suggestion earlier of a /boot partition ... for medieval bios' ... please give me a break - for younger folk who prodly never heard of the bios 1024 boot limit. Nevermind newer boards with EFI.
>So the intentions are probably good but the advice is pretty bad.

Why do you assume that BIOS limitations are the only reason people do it ? Just because you can't see a reason and/or you disagree with it, that doesn't make it "bad".
FYI - other reasons to use a separate /boot partition include "how the f*** to boot the system if you want / on sw raid or lvm and your bootloader doesn't support software raid or lvm ?" That was the case for a while, though I believe GrUB2 does now handle this - I've certainly run systems where GrUB didn't support whatever raid/lvm I was wanting to put / on.
Also, since /boot is virtually static, it's highly unlikely to suffer FS damage. This means you can boot the system into maintenance mode even if / needs manual intervention. That's the difference between "boot the system, put password in when prompted after FSCK fails, FSCK the filesystem and carry on" and "go find a boot /live disk, boot the system from that, find the CD/DVD drive doesn't work any more, go find another drive, boot the system (slowly !), FSCK /, reboot and take disk out".
Been there, done that.


Jean-Yves Avenard wrote:
> Now with huge disks (even a 20GB SSD is huge by comparison to what fit was back in the days)having
> a dedicated /var partition is just a plain pain in the a***. Because that one will run out of space sooner or later.

> Same with /tmp
> And that is a nightmare to deal with...

Do you think that running out of space on / is less of a PITA ? Does that change if when the system goes tits up it's an hour or two drive away - or perhaps better in context of a home user, just as you've started your holiday and can't log in remotely to fix it ?
I've had / fill up in the past, it's not something I recommend.
Yes, managing multiple partitions is something of a nuisance, and I agree it would be better if we didn't have to, but the reality is that I'd prefer not to have /var on my root partition - because then when it does fill up, I don't lose the whole system and can normally fix it remotely (where remote may mean in the server room, or it may mean the other end of the county. On mail servers I have /var/spool or /var/spool/mail on it's own filesystem for the same reason.
Another factor to consider is that some of you are clearly only thinking in terms of "one system, big disk, big / filesystem is no problem". Once you start managing a number of systems, then all that extra space for / sized to be as big as it could ever need starts to add up - especially if you are constrained to the point where you are being asked to run up "one more system" but just don't have any disk space left (though I'll admit this isn't common for home users).
That's just my preference. You are free to run whatever layout suits you - just please don't suggest that anyone doing differently is "wrong".


James Linder wrote:
>If you use ssd then root partition should be much bigger than needed to give wear levelling a place to roam about.

Wear levelling takes place across the drive, not within a partition or filesystem. Not only that, but writes are normally made to "spare" blocks which are then mapped into the linear list presented to the host* - with the now unused old version returned to a pool to be erased and reused later. So any physical block on the ssd may end up part of any partition/filesystem on the disk at different times.
* This is to avoid the performance hit (and scope for inopportune power failure) of having to do a read-modify-erase-write cycle for all writes. Where the larger physical chunk is read into a buffer, the parts written to are updated in the buffer, then the whole chunk is erased, and finally the chunk is re-written from the buffer.



But I think the main conclusion we can draw from the discussion is that there are probably as many ways of partitioning your system as there are people doing it. Few, if any, of those ways are "wrong" and it's a matter pr personal preference in some cases, together with some influences from the requirements of the system - eg in Myth, performance is better if OS/DB is not on same drive(s) as recordings.

Perhaps it would be better if we stuck to saying what we did, and why we did it, the OP can look at the reasons we've given, and decide what makes sense for him ?