SoylentNews is people
SoylentNews
A Debian user has recently discovered that systemd prevents the skipping of fsck while booting:
With init, skipping a scheduled fsck during boot was easy, you just pressed Ctrl+c, it was obvious! Today I was late for an online conference. I got home, turned on my computer, and systemd decided it was time to run fsck on my 1TB hard drive. Ok, I just skip it, right? Well, Ctrl+c does not work, ESC does not work, nothing seems to work. I Googled for an answer on my phone but nothing. So, is there a mysterious set of commands they came up with to skip an fsck or is it yet another flaw?
One user chimed in with a hack to work around the flaw, but it involved specifying an argument on the kernel command line. Another user described this so-called "fix" as being "Pretty damn inconvenient and un-discoverable", while yet another pointed out that the "fix" merely prevents "systemd from running fsck in the first place", and it "does not let you cancel a systemd-initiated boot-time fsck which is already in progress."
Further investigation showed that this is a known bug with systemd that was first reported in mid-2011, and remains unfixed as of late December 2014. At least one other user has also fallen victim to this bug.
How could a severe bug of this nature even happen in the first place? How can it remain unfixed over three years after it was first reported?
(Score: 1) by linuxrocks123 on Sunday December 21 2014, @09:01AM
Why should my default behavior be to split my disk into multiple data partitions, and how is using a single partition for data a disaster waiting to happen? Disks typically fail for mechanical reasons; partitioning will not save you there. I consider it best practice to have a single root partition and a single swap partition, unless I have good reasons to do otherwise. Needlessly splitting of /usr or /home is just setting yourself up for pain when you discover you need more space for /home and less space for /usr than you expected, or vice versa. If you're using NFS or something then yeah by all means slice up your FS, but otherwise ... what's the point?
(Score: 1) by neleai on Sunday December 21 2014, @09:28AM
Why should my default behavior be to split my disk into multiple data partitions, and how is using a single partition for data a disaster waiting to happen? Disks typically fail for mechanical reasons; partitioning will not save you there. I consider it best practice to have a single root partition and a single swap partition, unless I have good reasons to do otherwise. Needlessly splitting of /usr or /home is just setting yourself up for pain when you discover you need more space for /home and less space for /usr than you expected, or vice versa. If you're using NFS or something then yeah by all means slice up your FS, but otherwise ... what's the point?
It is also used when you have different distros then you use separate / and common /home partions.
(Score: 2) by Marand on Sunday December 21 2014, @12:10PM
If you're using NFS or something then yeah by all means slice up your FS, but otherwise ... what's the point?
I don't agree with going batshit-crazy and making dozens of partitions, but having /home on its own apart from / isn't a bad idea. If you have to do a reinstall or decide to change distros it's a lot easier because you can just wipe and reinstall /, and your data (the stuff you actually care about) can be left alone. You can also have multiple distros installed on their own root partitions, all using the same home dir. Good for experimentation or just having an emergency backup install in case something goes horribly wrong with your normal install.
It also lets you have a much smaller root partition, since the bulk of your storage use will usually be in /home. That means you can get to a usable system faster even when you need (or want) to fsck, and afterward you can remount /home read-only and fsck it while in a mostly-usable system.
TL;DR: Separating /home from the root has saved me a fair amount of frustration in the past, though I find further separation to be overkill for most situations.
(Score: 2) by cafebabe on Thursday December 25 2014, @01:55PM
It was standard practice on the Amiga to have a boot/application partition and a data partition. If the data partition was screwed, it was possible to boot and attempt recovery. If the boot partition was screwed, data was safe and re-installation could proceed from floppy disks.
For desktop Unix systems, a variation of this arrangement is to include a partition for dedicated swap-space. If one wishes to minimize harddisk head seek time, the swap-space partition should be arranged between the system and data partitions.
I've tried more complicated arrangements but they are only worthwhile if you wish to purge large quantities of data on a regular basis.
1702845791×2
(Score: 2) by Marand on Friday December 26 2014, @01:12AM
That's basically what my setup is -- partitions for /, /home, and swap -- except I think the swap partition's at the end instead of in the middle. I don't actually use swap that much so it's largely irrelevant where it is, but I still prefer having it on its own partition instead of using swap files. I just didn't think to mention swap since the discussion seemed to be more about partitioning the actual file stuff. If you have a lot of RAM, there's also the niche case of using ramdisks for certain parts of the filesystem, but that's getting even farther away from disk storage and partitioning...
You have the same experience with over-partitioning that I do, basically. Too much becomes annoying to deal with eventually, but keeping the system stuff separate from the user stuff just tends to be good sense for a lot of reasons. Something else I didn't think to mention is that SSDs add another reason to do that kind of split, because you can put your OS and apps on the SSD and have the user data on the spinning disk, so that you have lots of space for data while getting the SSD speed increase.
You can even do it in Windows, at least with Windows 7! It's a bit harder to get set up that way, but it can be done and it's worth it IMO because OS problems won't wipe out your files and settings. It should really be the default setup, but I get why it isn't. User space needs differ so it's not a one-size-fits-all solution the same way that dumping everything onto the same partition is.
(Score: 2) by cafebabe on Monday December 29 2014, @05:57PM
Putting your swap space at the end is possibly more efficient if you have a perpetually full disk.
Regardless, if you wish to reduce the volume of writes to your SSD boot and application disk (and further increase access speed), add the noatime option in /etc/fstab. For each volume, this eliminates filing system writes to update access times. (This option is also useful for databases and high volume SMTP servers.)
1702845791×2
(Score: 2) by Arik on Sunday December 21 2014, @02:16PM
It's no magic bullet but it does make dealing with it a bit easier.
"I consider it best practice to have a single root partition and a single swap partition, unless I have good reasons to do otherwise."
So first off, with that setup, any process can fill the hard disk with temp files and cause all kinds of problems here. It's a pretty big deal when that happens on the root partition.
Put /var on it's own partition, and make /tmp a link to /var/tmp, and the same occurrence becomes a trivial annoyance instead.
You should put /home on its own partition for the same reasons. Lots of stuff gets to write to the home directory, if any of it ever goes berserk, for any reason, having /home on its own slice saves lots of toil and trouble.
And /usr is where post-boot software is installed - in many systems the majority of the disk space is used for this. Giving this its own slice is done simply to reduce the total size of /. Because the larger a slice is the longer it takes to fsck it - and it's not a linear scale. A very small / partition will fsck before you can notice it and hit ctrl-c - which is exactly the behaviour we want here. A very large slice can take hours. It's always faster to fsck 10 100gb disks than to fsck the same disk in a single terabyte slice.
"Needlessly splitting of /usr or /home is just setting yourself up for pain when you discover you need more space for /home and less space for /usr than you expected, or vice versa."
That's why man invented the LVM. Your physical slices and logical system-facing slices are two totally different beasts now, and if you need more room on /var and /usr but less on /home than you expected (or vice versa) you just adjust the numbers and make it so without disturbing the physical partitioning in the slightest.
If laughter is the best medicine, who are the best doctors?
(Score: 1) by linuxrocks123 on Monday December 22 2014, @12:22AM
The "a poorly-behaved process can fill the whole hard disk" thing is not a good argument, imo, because the default settings for the ext filesystems is to only let root write to the disk when it's 95% full. I agree with the /home thing if you want to use multiple distros on the same machine, but I typically don't. "It makes fsck run faster" is a poor argument IMO because I have terabyte and larger filesystems and fsck still doesn't take an unreasonable amount of time to run on those. You can also just disable fsck entirely and rely on the journaling to fix any problems if you want.
I'm not sure what your point is about LVM; if you combine a bunch of slices with LVM, you still have a single filesystem on a large virtual device, so you'll still need to either periodically fsck or rely on journaling.