Re: Skipping fsck during boot with systemd?
On 12/29/2014 10:05 PM, Ric Moore wrote:
> On 12/29/2014 08:51 PM, Jerry Stuckle wrote:
>> On 12/29/2014 1:27 PM, Ric Moore wrote:
>>> 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
>>>>>>>>
>>>>>>>> Jerry Stuckle <stucklejerry@gmail.com> wrote:
>>>>>>>>> On 12/11/2014 1:23 PM, Brian wrote:
>>>>>>>>>> On Thu 11 Dec 2014 at 12:11:26 -0500, Jerry Stuckle wrote:
>>>>>>>>>>> I often give presentations with my notebook. If I'm lucky, I
>>>>>>>>>>> get
>>>>>>>>>>> 10-15 minutes to set up. If I'm not, less than 5 minutes (i.e.
>>>>>>>>>>> another presenter ahead of me). I use Linux whenever possible,
>>>>>>>>>>> but
>>>>>>>>>>> since my time slot is limited, I can't wait for fsck to
>>>>>>>>>>> complete.
>>>>>>>>>>
>>>>>>>>>> Your type of situation is well understood and there is sympathy
>>>>>>>>>> for it.
>>>>>>>>>
>>>>>>>>> I appreciate that - but unfortunately, sympathy doesn't solve the
>>>>>>>>> problem
>>>>>>>>> :)
>>>>>>>>
>>>>>>>> Someone may have suggested this, and I know it doesn't really
>>>>>>>> solve the
>>>>>>>> core problem, but perhaps consider suspending (to disk or ram)
>>>>>>>> instead
>>>>>>>> of shutting down when you have a presentation scheduled?
>>>>>>>
>>>>>>> Again, that is a way round the problem not a solution to it.
>>>>>>>
>>>>>>> A facility that was available no longer is. Whether it should be,
>>>>>>> is an
>>>>>>> entirely different question.
>>>>>>>
>>>>>>> Lisi
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> 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.
>>>
>>
>> I agree it's not a good idea to interrupt fsck WHEN IT IS FIXING A
>> PROBLEM. A routine test when there is no indication of a problem is a
>> completely different story.
>>
>>> 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.
>>>
>>
>> It can be a HUGE problem. For instance - maybe I'm getting ready to
>> make a presentation to a VP of a client's company. The success of this
>> project depends on my presentation being more successful than another
>> consultants. fsck running right then can easily cost me tens of
>> thousands of dollars over the course of the contract.
>>
>> Are YOU willing to reimburse me for that loss?
>>
>>> 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
>>>
>>>
>>>
>>
>> I can, and I have, when it runs at an inconvenient time. Windows allows
>> this, and terminates the defrag gracefully. That's one thing Windows
>> has on Debian.
>>
>> Just because it's OK for YOU to have fsck to run any time it wants does
>> NOT mean it's ok for everyone else.
>
> Running ext4, the only time it has run fsck for me is when it had to.
> Otherwise I run it manually just to be sure.
>
>> And that's what this thread is all about - how to stop it from happening.
>>
>> But it will probably not matter to me, anyway. My clients are looking
>> for alternatives to Debian just because of crap like this. And we're
>> talking a lot of Debian systems running in dedicated controllers.
>
> Why not run zfs?? Have you not considered it?? It STILL runs file
> maintenance but it runs while the file system is alive and running. It
> just slows down things unless you use a cron job when file service is
> more idle. Like at night. Give that a whirl. Problem solved. The average
> user has no need to interrupt fsck since fsck knows more about the need
> to run than the user does. It will run when it has to. Thank $DEITY$ for
> that.
>
> "If the file system is found to have a problem at the booting time non
> interactive fsck is run and all errors which are considered safe to
> correct are corrected. But if still file system has problems the system
> boots in single user mode asking for user to manually run the fsck to
> correct the problems in file system."
>
> You seriously want to mess with that? The logic escapes me. And, on top
> of that, to blame systemd? That's where we really part ways. Please read
> this:
> http://utcc.utoronto.ca/~cks/space/blog/unix/FsckHistory
> :/ Ric
>
Ric, as others have indicated - this is NOT the only time fsck runs on
Jessie. It's the times it runs unannounced at boot when there are no
problems indicated which is the problem here.
And I don't have a say as to what my clients run for a filesystem. They
have their own reasons for running what they do.
Jerry
Reply to: