Ubuntu 9.04 with file issues Cross posted by intent- we're supposed to compare notes on such problems - I hope.

Jack quiet_celt at yahoo.com
Sun Sep 5 01:34:47 CDT 2010


I will continue to disagree with this option, until someone can prove to me that fsck -y is *always* safe to run on ext3 filesystems. When in fact it is known that it can cause further corruption of the filesystem. If the messages are the result of an improper shutdaown, it may be safe, but if the messages are the result of imminent disk failure fsck -y *usuallly* does more damage. Fsck -y is, and was, designed for use by system administrators who know what they are doing. It's not meant to be the lazy man's alternate to safe fs recovery. I'm sorry, I think the response "fsck -y" to a question about wanting to know more about how fsck and the fs work is bad advise at best, and a copout.

Nowhere has the OP said this is the result of an improper shutdown, and he specifically wanted to know how he can find out why he is getting the messages and the safest way to fix it. Whether it was safe to have fsck clone the multiply linked files or not, and what the dangers were. To simply say "fsck -y" is an irresponsible response which gives the OP no clues as to what has happened and why.

You said three organizations say it's safe, but provide no proof of that and name only two.  There are numerous people who disagree with you. The simple fact is fsck -y in this particular case *will* result in data loss. While it may be inevitable, it may also make it worse, depending on the cause. We also, don't know if there are still further errors.

However, if my opinion is deemed to be paranoid, and the OP wishes to do the quick and , potentially, easy fix, I would suggest adding a -v to the command so you get a list of the "fixes" in the process., and if you have a alternate disk pipe it to a file as well as the screen. Just know that I am telling you, it can do more damage to the fs and make later recovery even worse. Although, apparently, Oracle disagrees with me, and they're ever so trustworthy and probably smarter than me.

Also, make sure you never, ever run fsck -y on a mounted filesystem. Although, maybe, someone here will say that's totally safe too. Now we are also talking here specifically about exzt2/3 filesystems. 

Jack

--- On Fri, 9/3/10, Christofer C. Bell <christofer.c.bell at gmail.com> wrote:

From: Christofer C. Bell <christofer.c.bell at gmail.com>
Subject: Re: Ubuntu 9.04 with file issues Cross posted by intent- we're supposed to compare notes on such problems - I hope.
To: "Kclug" <kclug at kclug.org>
Date: Friday, September 3, 2010, 7:06 PM

On Fri, Sep 3, 2010 at 2:33 PM, Jack <quiet_celt at yahoo.com> wrote:



My major issue with -y is that it takes control out of your hands, and if your goal is to attempt to preserve as much as possible, the -y option isn't likely to be helpful there. Remember the original poster wanted to do the least destructive path. Sometimes the right answer is to sit there and press yes 10,000 times (and bill accordingly). After all, fsck already does the best it can to fix the filesystem in the default configuration.


Third tier storage support for the following 3 vendors disagree with you: Oracle (Solaris), Hewlett-Packard (HP-UX), SGI (IRIX).  I don't know what IBM and Red Hat recommend, I've not supported systems running their products and haven't had to contact them.

The short of it is, if your filesystem is so screwed up that it's not "safe" to do fsck -y, then you need to restore from backup regardless of outcome.
To the OP,

Run fsck -y on the device repeatedly until it stops complaining (ie; runs without fixing anything).  You'll end up being fine.
-- 
Chris





-----Inline Attachment Follows-----

_______________________________________________
KCLUG mailing list
KCLUG at kclug.org
http://kclug.org/mailman/listinfo/kclug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kclug.org/pipermail/kclug/attachments/20100904/b816fa1b/attachment.htm>


More information about the KCLUG mailing list