Linux partitioning
-
Every Ubuntu server I have ever installed has filled up the /boot after a few updates/upgrades. I know it is normally easy to resolve but it is a pain.
-
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.
Used to happen more often because bad programming was more common.
Take Ubuntu for example, it will fill up /boot after a few kernel upgrades, so anything is possible.
That's a known badly implemented system. IE bad programming. Don't use it.
Also, it has nothing to do with /var filling up.
-
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.
Used to happen more often because bad programming was more common.
Take Ubuntu for example, it will fill up /boot after a few kernel upgrades, so anything is possible.
That's a known badly implemented system. IE bad programming. Don't use it.
Also, it has nothing to do with /var filling up.
It's just an example of partition filling up, doesn't matter which one. It proves the point that it does happen.
-
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.
Used to happen more often because bad programming was more common.
Take Ubuntu for example, it will fill up /boot after a few kernel upgrades, so anything is possible.
That's a known badly implemented system. IE bad programming. Don't use it.
Also, it has nothing to do with /var filling up.
It's just an example of partition filling up, doesn't matter which one. It proves the point that it does happen.
In your example, they are causing a new problem because they've implemented your solution to the problem.
-
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.
Used to happen more often because bad programming was more common.
Take Ubuntu for example, it will fill up /boot after a few kernel upgrades, so anything is possible.
That's a known badly implemented system. IE bad programming. Don't use it.
Also, it has nothing to do with /var filling up.
It's just an example of partition filling up, doesn't matter which one. It proves the point that it does happen.
In your example, they are causing a new problem because they've implemented your solution to the problem.
No, it would've had the same outcome if /boot wasn't on separate partition, but under root. Eventually it would've filled up entire disk with old kernel versions. The main point is to prevent root partition from filling up, not any other mount point.
-
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.
Used to happen more often because bad programming was more common.
Take Ubuntu for example, it will fill up /boot after a few kernel upgrades, so anything is possible.
That's a known badly implemented system. IE bad programming. Don't use it.
Also, it has nothing to do with /var filling up.
It's just an example of partition filling up, doesn't matter which one. It proves the point that it does happen.
In your example, they are causing a new problem because they've implemented your solution to the problem.
No, it would've had the same outcome if /boot wasn't on separate partition, but under root. Eventually it would've filled up entire disk with old kernel versions. The main point is to prevent root partition from filling up, not any other mount point.
If you have that many failures, for enough years for that particular thing, to become a problem, you have many more issues than just a full root partition.
Seriously, this has been solved, and is nothing more than make-work anymore on any halfway decent platform.
-
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Reduces in one way (separation), increases in another (lower buffer size.) It's beneficial, but not by as much as it seems.
-
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
It's about risk assessment. Yeah, anything can go nuts. But filling up the drive is just one of so many ways that something going nuts will get you. In the real world, the risk is so low, I would not generally split it out.
-
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.
Used to happen more often because bad programming was more common.
Same here, we know it can happen. but never see it.
-
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.
Used to happen more often because bad programming was more common.
Take Ubuntu for example, it will fill up /boot after a few kernel upgrades, so anything is possible.
Yeah, but that's a known issue with out of date systems, and isn't mitigated by splitting out the /var space. But IS mitigated by going with all one partition. So the risk doesn't match the mitigation.
-
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.
Used to happen more often because bad programming was more common.
Take Ubuntu for example, it will fill up /boot after a few kernel upgrades, so anything is possible.
That's a known badly implemented system. IE bad programming. Don't use it.
Also, it has nothing to do with /var filling up.
It's just an example of partition filling up, doesn't matter which one. It proves the point that it does happen.
It does matter, because splitting them out requires knowing specifically which are risks and which are not.
-
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@travisdh1 said in Linux partitioning:
@marcinozga said in Linux partitioning:
@JaredBusch said in Linux partitioning:
@marcinozga said in Linux partitioning:
Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.
Better solution, don't use bad apps
You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins
Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.
Used to happen more often because bad programming was more common.
Take Ubuntu for example, it will fill up /boot after a few kernel upgrades, so anything is possible.
That's a known badly implemented system. IE bad programming. Don't use it.
Also, it has nothing to do with /var filling up.
It's just an example of partition filling up, doesn't matter which one. It proves the point that it does happen.
In your example, they are causing a new problem because they've implemented your solution to the problem.
No, it would've had the same outcome if /boot wasn't on separate partition, but under root. Eventually it would've filled up entire disk with old kernel versions. The main point is to prevent root partition from filling up, not any other mount point.
That's not really true. That's making a lot of assumptions. In reality...
-
It would not likely ever fill up. The scales are so different. This is where creating a separate /boot actually CREATES the risk. The very pattern you are trying to follow is the one causing the issue.
-
It has lots and lots of chances for humans AND monitoring systems to catch and resolve it long before becoming an issue. This should have years, typically, to be flagged rather than filling up in a day or two.
-
