[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: Re: Skipping fsck during boot with systemd?

Path: eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!bofh.it!news.nic.it!robomod
From: Ric Moore <wayward4now@gmail.com>
Newsgroups: linux.debian.user
Subject: Re: Skipping fsck during boot with systemd?
Date: Mon, 29 Dec 2014 19:50:02 +0100
Message-ID: <oCNya-7Vl-11@gated-at.bofh.it>
References: <ou9Hz-41a-3@gated-at.bofh.it> <owhrk-1AL-19@gated-at.bofh.it> <oCa3M-6Xf-5@gated-at.bofh.it> <oCk37-5oc-11@gated-at.bofh.it> <oCoJs-3Xr-3@gated-at.bofh.it> <oCCjn-7wk-9@gated-at.bofh.it> <oCHj5-70U-11@gated-at.bofh.it>
X-Original-To: debian-user@lists.debian.org
Old-Return-Path: <wayward4now@gmail.com>
X-Amavis-Spam-Status: No, score=-6.989 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FOURLA=0.1, FREEMAIL_FROM=0.001, LDO_WHITELIST=-5, T_TO_NO_BRKTS_FREEMAIL=0.01] autolearn=ham
X-Policyd-Weight: using cached result; rate: -7
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=gmail.com; s=20120113;        h=message-id:date:from:mime-version:to:subject:references:in-reply-to         :content-type:content-transfer-encoding;        bh=Ct1vvY2fbx8jBh/Hc08uYClnwRaNmlKmpDbl26M7OqE=;        b=JAXOXJAZ3U/Bm+eIr4nIgh8hAWfLsYidoczlzuVR+Iyp/I+AO1G1JH39g/pQzpcT5z         VXLthqUKXFlOrAgxz1EV1kUnYHrIZkM5Bbrfm7/eh+OvTCLoEVMwSuY0cqjksvsTqJzW         5XKVw41ojQzZdxugMfZ9RBe8axd+qbXKoIlubdNIF8GSeRvMn2iWd9UfBdD3Bvmi3bkp         QCVM+9qaftzjaHlM1wmX8mk3J34zO4IA6SCb8iReo+bkoPf8VI46cbrZ3zRNCjB9eVqW         UAe3lCdSS4VOP88x0V7zZRqtb/tp1J47opwR9Ca460b0sioA1UkN4WMZ9q/mVKT5cP6V         ecjw==
X-Received: by with SMTP id bv4mr74736371pad.15.1419877803735;        Mon, 29 Dec 2014 10:30:03 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailing-List: <debian-user@lists.debian.org> archive/latest/685146
List-ID: <debian-user.lists.debian.org>
List-URL: <http://lists.debian.org/debian-user/>
Approved: robomod@news.nic.it
Lines: 105
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
X-Original-Date: Mon, 29 Dec 2014 13:27:59 -0500
X-Original-Message-ID: <[🔎] 54A19D2F.1040503@gmail.com>
X-Original-References: <[🔎] 20141205190650.09a4404d@ron.cerrocora.org> <[🔎] 5489EA5C.9030404@gmail.com> <[🔎] 20141227192020.0c672b297977b244762d391b@gmail.com> <[🔎] 201412281054.24677.lisi.reisz@gmail.com> <[🔎] 54A028B1.9020305@gmail.com> <[🔎] 54A0F323.5050900@gmail.com> <[🔎] 54A13E95.9060407@gmail.com>
Xref: mx02.eternal-september.org linux.debian.user:140641

>On 12/29/2014 06:44 AM, Jerry Stuckle wrote:
>> On 12/29/2014 1:22 AM, Ric Moore wrote:
>>> On 12/28/2014 10:58 AM, Jerry Stuckle wrote:
>>>> On 12/28/2014 5:54 AM, Lisi Reisz wrote:
>>>>> On Sunday 28 December 2014 00:20:20 Celejar wrote:
>>>>>> On Thu, 11 Dec 2014 14:02:52 -0500
>>>> Lisi,
>>>> While I agree it's only a way around a problem and not a solution, I do
>>>> appreciate people trying to help out.
>>>> And while I would prefer a solution, it looks like that's not going to
>>>> happen.  So, unfortunately, after many years as a Debian user, I'm
>>>> looking at other options.  My clients are looking, also, although not
>>>> every one has made the decision to switch yet.
>>> What's wrong with sticking with Wheezy for the next couple of years?? I
>>> haven't had my ext4 file system want to fsck in eons. Several times I
>>> have MADE it do a check on the next boot, just to check, and a Tbyte of
>>> storage was fscked in about 10-15 seconds.
>> Not as easy as you think.  I write device drivers; for instance, one of
>> my customers manufacturers microprocessor-based systems.  Right now they
>> are using Debian, but are now looking for another distro.  It's not
>> something they do lightly or quickly; even now they may not have time
>> before service is dropped for Wheezy.  And I need to be running the same
>> software they are.
>>> Besides, I never did buy that bit about doing a complete dist-upgrade to
>>> Jessie (testing!) and then expecting to do a presentation to clients
>>> without a complete shakedown. I'd shoot myself first. I know you know
>>> better.
>> Where did I ever say I wouldn't do a complete shakedown?  But this is
>> the type of bug which can bite you weeks or months after the install.
>> It doesn't occur minutes, hours or even days later.  And Murphy says it
>> will happen at the worst possible time.
>>> Can we not let this pitiful excuse for a thread JUST DIE?? :/ Ric
>> This is a Debian User list.  Why don't you want bugs which affect Debian
>> users discussed here?  And that's what I have seen here - at least until
>> you started complaining about the thread.
>There we differ. You consider it a bug, and I consider it a feature. 
>When I googled on the topic there was a Hail Mary chorus shouting "DO 
>not interrupt fsck! It's BAD!". Ergo the consensus of opinion that if it 
>is critical enough, do not allow it to be interrupted. Tough titties, as 
>the process is for your own good.
>It's a small price to pay when you look back at the days when a Windows 
>server HAD to go down at 3AM "for maintenance" (defrag, which took quite 
>awhile) while we laughed and laughed at the stupid lamers who used it 
>and suffered. I know I did.
So, debian becoming more like Windows in its impossible behaviour is a
feature, not a bug?

I agree that if there is an fsck of the / partition because of
corruption, you should not interrupt it. 
On the other hand, a "periodic" fsck should at least ask for permission
to run, not automatically run, because, as said, it will always occur at
the most inconvenient time. Also, while an fsck on / should quite
probably not be interruptable, one on /home, or /other should be, or at
least should not interrupt the boot. Ie, it should run in the
background, not the foreground. 

>But, you sure as hell wouldn't interrupt a Windows full defrag process 
>half-way through, would you? We've had it easy, so I consider it a 
>feature. I'll take a 20 second inconvenience any day. :) Ric

Now imagine it is a 20 min inconvenience, not a 20 sec. That is what
happens if the partition is say a 2TB partition. 
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. 
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. 


Reply to: