Fwd: Re: Skipping fsck during boot with systemd?

Ric Moore wayward4now at gmail.com
Mon Dec 29 23:59:28 UTC 2014


On 12/29/2014 03:04 PM, William Unruh wrote:

> Now imagine it is a 20 min inconvenience, not a 20 sec. That is what
> happens if the partition is say a 2TB partition.

I wrote that a one TB drive took around 20 seconds.

> Your argument style is very strange. You say Windows behaves horribly so
> we should expect Linux to behave that way as well. And then you minimize
> the problem.

What?? I said that they had to go down for hours every night at 3AM. So, 
20-30 seconds of annoyance, once in a blue moon if you use ext4, is our 
tradeoff for file system maintenance.

> It is a valid concern, and the answer is neither to give up on Linux, or
> to just say "suck it up". It is to make systemd as responsive and
> configurable as one can.

Horse apples. fsck has been with us since the dawn of UNIX (1). Are you 
saying that after almost every file has been wiped and replaced by a 
dist-upgrade from wheezy to jessie, where it is almost a guarantee that 
every file size has changed, that an fsck ISN'T in order after the file 
system took that MASSIVE pounding?? I would think that if it didn't 
happen someone would take a drubbing. I fail to see where systemd is 
even an issue here. So, the average Joe or Jane Lunchbucket Debian user 
should be able to cntl C the process that might save his file system?? 
And, that we need more complexity?

Again, every google search on "interrupt fsck" said "Don't Do It!"
Where's the beef?? "A rule of thumb, automate where you can make 
mistakes."

"    Faster file system checking

     In ext4, unallocated block groups and sections of the inode table 
are marked as such. This enables e2fsck to skip them entirely on a check 
and greatly reduces the time it takes to check a file system of the size 
ext4 is built to support."
http://unix.stackexchange.com/questions/24727/significant-difference-in-speed-between-fsck-using-ext3-and-ext4-on-debian-squee

There ya have it.
Use ext4 (or ZFS with scrub, which is run on a live file system).
Automate where you can make mistakes.
Don't interrupt fsck. If it is forced to run, it knows better than you 
why. :) Ric

(1) http://utcc.utoronto.ca/~cks/space/blog/unix/FsckHistory


-- 
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256




More information about the D-community-offtopic mailing list