FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-10-2008, 01:36 PM
Eric Sandeen
 
Default RFE: autofsck

Ahmed Kamal wrote:
> I would like to propose
>
> echo AUTOFSCK_DEF_CHECK=yes >> /etc/sysconfig/autofsck
> echo 'AUTOFSCK_OPT="-y"' >> /etc/sysconfig/autofsck
>
> Working with a local ISP in some rural area where there's a lot of power
> cuts! The ISP guys were asking like, "Why is it that Linux boxes need
> manual intervention to get back up after a power cut!" .. "Can't you
> script what you're doing to get it back up" ?!
> Does not having this as the default makes sense in some tangible number
> of cases ?!
>

Adding -y could potentially be dangerous. e2fsck asks when the answer
isn't obvious. In some situations, perhaps, but I probably would not
make this default.

I'm more concerned that you're seeing so many problems; with a
journaling filesystem you really shouldn't have any filesystem metadata
integrity problems on power loss; that is, if you have barriers on
(which ext3 doesn't by default) and if your storage can pass barriers
(which lvm doesn't), or if you have drive write cache disabled (which
hurts performance pretty badly).

I'd rather address the root of the problem and sort out why, if you are
paying the journaling overhead penalty at runtime, it's not saving you
on power loss.

-Eric

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 02:30 PM
"Ahmed Kamal"
 
Default RFE: autofsck

I totally agree we should fix the core cause. If there's anything to prevent file system errors from ever happening, go for it. However, when the inevitable
Filesystem errors, Fix(y/n):
appears, when was the last time you pressed "n"! Unless you're Theodore tso there's not so much you could do, eh! So why not make that the default


On Tue, Jun 10, 2008 at 4:36 PM, Eric Sandeen <sandeen@redhat.com> wrote:

Ahmed Kamal wrote:

> I would like to propose

>

> echo AUTOFSCK_DEF_CHECK=yes >> /etc/sysconfig/autofsck

> echo 'AUTOFSCK_OPT="-y"' >> /etc/sysconfig/autofsck

>

> Working with a local ISP in some rural area where there's a lot of power

> cuts! The ISP guys were asking like, "Why is it that Linux boxes need

> manual intervention to get back up after a power cut!" .. "Can't you

> script what you're doing to get it back up" ?!

> Does not having this as the default makes sense in some tangible number

> of cases ?!

>



Adding -y could potentially be dangerous. *e2fsck asks when the answer

isn't obvious. *In some situations, perhaps, but I probably would not

make this default.



I'm more concerned that you're seeing so many problems; with a

journaling filesystem you really shouldn't have any filesystem metadata

integrity problems on power loss; that is, if you have barriers on

(which ext3 doesn't by default) and if your storage can pass barriers

(which lvm doesn't), or if you have drive write cache disabled (which

hurts performance pretty badly).



I'd rather address the root of the problem and sort out why, if you are

paying the journaling overhead penalty at runtime, it's not saving you

on power loss.



-Eric



--

fedora-devel-list mailing list

fedora-devel-list@redhat.com

https://www.redhat.com/mailman/listinfo/fedora-devel-list



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 02:35 PM
Eric Sandeen
 
Default RFE: autofsck

Ahmed Kamal wrote:
> I totally agree we should fix the core cause. If there's anything to
> prevent file system errors from ever happening, go for it. However, when
> the inevitable
> Filesystem errors, Fix(y/n):
> appears, when was the last time you pressed "n"! Unless you're Theodore
> tso there's not so much you could do, eh! So why not make that the default

For the same reason that Ted T'so doesn't think the software itself
should blindly assume -y as the default. You are basically asking
the Fedora scripts to override the e2fsck defaults chosen by Ted as the
safest approach.

If nothing else, forcing the user to press "y" at least alerts them that
something has gone wrong. An unattended box rebooting post-disaster,
running e2fsck -y may move huge swaths of data to lost+found
automatically and leave the user scratching their heads about where on
earth all their email went (or whatever).

If you like the tradeoff by all means set it on your boxes, it may be
the right answer in your situation, but I don't like it for a default.

-Eric

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 03:31 PM
"Bill Crawford"
 
Default RFE: autofsck

2008/6/10 Eric Sandeen <sandeen@redhat.com>:

> For the same reason that Ted T'so doesn't think the software itself
> should blindly assume -y as the default. You are basically asking
> the Fedora scripts to override the e2fsck defaults chosen by Ted as the
> safest approach.

Would making "-p" the default be an acceptable compromise?
[I thought we used to do this, but I could be losing my marbles]

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 04:30 PM
Paul Wouters
 
Default RFE: autofsck

For the same reason that Ted T'so doesn't think the software itself
should blindly assume -y as the default. You are basically asking
the Fedora scripts to override the e2fsck defaults chosen by Ted as the
safest approach.


Who, aside from Ted Tso, can do anything else but re-run with "yes"? You
are just postponing the problem, and thereby adding to the problem.


If nothing else, forcing the user to press "y" at least alerts them that
something has gone wrong.


We already know something is wrong, our box is missing waiting in single
user mode.


An unattended box rebooting post-disaster,
running e2fsck -y may move huge swaths of data to lost+found
automatically and leave the user scratching their heads about where on
earth all their email went (or whatever).


As compared to rebooting post-disaster, being gone, needing the sysadmin
to drive over, find single user mode, run e2fsck, get INCONSISTENT
FILESYSTEM detected, and rerun with e2fsck -y, which puts all files in
lost+found.

How different your scenario from having "-y" or not? Nothing.

However, on the OTHER 99.99% of the scnearios, your box is dead in the
water and boxes with -y are back online. I'd rather scratch my head on
a missing email. Besides, if THAT is what you want to fix, then fix
that by warning the user/root/wheel group upon login if there are files
in lost+found.


If you like the tradeoff by all means set it on your boxes, it may be
the right answer in your situation, but I don't like it for a default.


You're wrong. I had a discussion with Ted himself who sees that the
current way is wrong. You can find me ranting every fedora release that
it is wrong. I run boxes all over the planet, from RH9 to F9 and RHEL.
It's a problem. It's always been a problem.

What would help is to add /etc/sysconfig/autofsck with the line

# AUTOFSCK_OPT="-y"

so at least we don't have to keep reading rc.sysvinit to figure out which
version of fedora we need to change which script/variable to make this
happen.

Though personally, I'd prefer an Anaconda option for it.

"Unselect this option if you want to disable automatic repair
attempts of the filesystem, and have a chance to use a
raw filesystem editor to directly edit raw blocks on disk"

Let's face it. There are 10 people in the world who could and maybe want,
to do this to an ext3 filesystem, and I'm pretty sure they maintain less
then 0.00001% of the Fedora servers ouf there.

Paul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 04:42 PM
"Callum Lerwick"
 
Default RFE: autofsck

2008/6/10 Ahmed Kamal <email.ahmedkamal@googlemail.com>:

Working with a local ISP in some rural area where there's a lot of power cuts! The ISP guys were asking like, "Why is it that Linux boxes need manual intervention to get back up after a power cut!" .. "Can't you script what you're doing to get it back up" ?!


Does not having this as the default makes sense in some tangible number of cases ?!
Seems to me the obvious question is, if you are an ISP and you have a known problem with power dropouts, why are all these boxes not on UPSs and rigged to shut themselves down properly on power fail?


... Not that this is an excuse for journaling not doing its job.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 04:45 PM
Eric Sandeen
 
Default RFE: autofsck

Paul Wouters wrote:


> You're wrong. I had a discussion with Ted himself who sees that the
> current way is wrong.

If Ted thinks it's wrong, perhaps he would accept a patch to make -y the
default instead of having distros work around the upstream defaults via
scripts?

> What would help is to add /etc/sysconfig/autofsck with the line
>
> # AUTOFSCK_OPT="-y"
>
> so at least we don't have to keep reading rc.sysvinit to figure out which
> version of fedora we need to change which script/variable to make this
> happen.

Yep, I agree that if scripts are looking for magic sysconfig files they
should probably exist at least as placeholders...

-Eric

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 05:36 PM
Alan Cox
 
Default RFE: autofsck

On Tue, Jun 10, 2008 at 12:30:53PM -0400, Paul Wouters wrote:
> Who, aside from Ted Tso, can do anything else but re-run with "yes"? You
> are just postponing the problem, and thereby adding to the problem.

Most users.

> Though personally, I'd prefer an Anaconda option for it.
>
> "Unselect this option if you want to disable automatic repair
> attempts of the filesystem, and have a chance to use a
> raw filesystem editor to directly edit raw blocks on disk"

That would suck. For most users you might as well ask them if they wanted
frobnicate the meta-haddock.

> Let's face it. There are 10 people in the world who could and maybe want,
> to do this to an ext3 filesystem, and I'm pretty sure they maintain less
> then 0.00001% of the Fedora servers ouf there.

There are lots of cases you want that thing to stop. For example if there is
important data on the box and you decide to get advice first. If you follow
the most basic single rule of recovering a damaged file system you want it
to stop so you can make a copy. Indeed you may well need a professional recovery
expert or have a support contract and need to ask the helpdesk...

-y in some cases is also things like:
"Destroy any hope of recovering your PhD Thesis"

Alan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 06:24 PM
Paul Wouters
 
Default RFE: autofsck

On Tue, 10 Jun 2008, Alan Cox wrote:


Date: Tue, 10 Jun 2008 13:36:02 -0400
From: Alan Cox <alan@redhat.com>
To: Development discussions related to Fedora <fedora-devel-list@redhat.com>
Subject: Re: RFE: autofsck

On Tue, Jun 10, 2008 at 12:30:53PM -0400, Paul Wouters wrote:

Who, aside from Ted Tso, can do anything else but re-run with "yes"? You
are just postponing the problem, and thereby adding to the problem.


Most users.


Right. Most users can't even use a command line, let alone a raw disk editor.


Though personally, I'd prefer an Anaconda option for it.

"Unselect this option if you want to disable automatic repair
attempts of the filesystem, and have a chance to use a
raw filesystem editor to directly edit raw blocks on disk"


That would suck. For most users you might as well ask them if they wanted
frobnicate the meta-haddock.


Indeed. We agree there. Hence "unselect". Let's assume that users who don't
know what frobinating a meta-haddock is, will stick to defaults


There are lots of cases you want that thing to stop. For example if there is
important data on the box and you decide to get advice first. If you follow
the most basic single rule of recovering a damaged file system you want it
to stop so you can make a copy. Indeed you may well need a professional recovery
expert or have a support contract and need to ask the helpdesk...


How many people on this list have:

a) paid for root filesystem data recovery
b) answered "no" and hand edited the root fs?


-y in some cases is also things like:
"Destroy any hope of recovering your PhD Thesis"


Don't story your PhD on your root fs. Also, if you want to protect against PhD
thesis for normal users, you should make root's "rm" alias a global setting.

Just to remind you, what people have a problem with is not running manual
fsck's on certain filesystems. People have a problem with machines being stuck
in single user mode waiting for manual intervention leading "fsck -y" anyway
on the root filesystem.

If my remote machine comes back, starts sshd, and then has /home not mounted
because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run fsck -y
manually.

Paul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-10-2008, 06:32 PM
Eric Sandeen
 
Default RFE: autofsck

Paul Wouters wrote:

> Just to remind you, what people have a problem with is not running manual
> fsck's on certain filesystems. People have a problem with machines being stuck
> in single user mode waiting for manual intervention leading "fsck -y" anyway
> on the root filesystem.
>
> If my remote machine comes back, starts sshd, and then has /home not mounted
> because of an INCOSISTENCT FILESYSTEM error, I'm more then happy to run fsck -y
> manually.

As a bit of a tangent, if you see this fairly often, any idea why?
Journaling should in general protect you from needing any sort of fsck
after a power loss or oops; that's what they're for, right. I'd be
curious to know what sorts of corruptions you wind up finding.

How the corruption gets coped with once found is one point worth
discussing, but where's it coming from in the first place? My guess is
it's lack of barrier writes, but it's worth getting to the bottom of it,
and hopefully this will make the choice of e2fsck parameters less
relevant.

-Eric

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 04:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org