Ubuntu 9.04 with file issues Cross posted by intent- we're supposed to compare notes on such problems - I hope.
Hi- I have a system in front of me with Ubuntu 9.04 on it- it was installed ext3. the part that is escapingmy understanding is recovering from a file corruption of some sort. Duplicate or bad blocks is the error message. The automatic run- in recovery mode- of fsck dies with exit status 4. A manual run of fsck shows a list of what it calls multiply-claimed blocks in several inodes. and there's aprompt asking yor no about cloning them. Needless to say- I am quite aware that my lack of understanding risks avoidable data loss. Any suggestions both on what to do and the best training document/s so I can understand why/how this issue happened in the first place will be appreciated. This is one of those gaps in my understanding of Linux admin skills. Either this is so drop dead simple that I will feel more of an idiot for not having "known" what is going on..Or it's going to be non-trivial to recover from. My first suggested fix was using Puppy etc and an external drive to simply grab any unique personal files that are intact- then DBAN wipe that drive before starting over. Which is what I cal a "Last Resort First" tactic . I hate having to use them, but LRF type methods have become a major mental hygiene tool for me :) Of course- I am deeply curious if my oft preached model for data protection- keeping the OS and Userdata on physically separate drives would have helped here -or not.. -- Oren Beck 816.729.3645
Status 4 simply means fsck didn't fix all the errors. Some errors can't be fixed automatically. Hence it simply gave you notice of that. It doesn't mean it died, or didn't fix everything it could have. The exit statuses are listed in the man page, I believe. The issue with multiply claimed blocks is that you have several files pointing to the same location. Cloning them will make all the files point to separate locations, and you'll wind up with multiple copies of whatever data is in the affected inodes. The downside is, cloning those blocks is something like order fn(O^n). So it's geometrically slow. Most likely anything in those inodes is garbage. This looks like an inode corruption issue. It's possible the data is fine in those inodes. Cloning is the safe (preserve all data), method, the other method is to not clone and just delete the affected inodes. Get paper and pencil ready and record any filenames, so you know what you lost/preserved. Record the inodes also. You can use "ls -i" to list the inode of a file. You can use "find -inum n" to find a file with a particular inode. Curious which kernel and ext3 version you are running? Regards, Jack --- On Tue, 8/31/10, Oren Beck <orenbeck@gmail.com> wrote:
From: Oren Beck <orenbeck@gmail.com> Subject: Ubuntu 9.04 with file issues Cross posted by intent- we're supposed to compare notes on such problems - I hope. To: "KCLUG" <kclug@kclug.org>, ccckc@googlegroups.com Date: Tuesday, August 31, 2010, 2:50 PM Hi- I have a system in front of me with Ubuntu 9.04 on it- it was installed ext3. the part that is escapingmy understanding is recovering from a file corruption of some sort. Duplicate or bad blocks is the error message. The automatic run- in recovery mode- of fsck dies with exit status 4.
A manual run of fsck shows a list of what it calls multiply-claimed blocks in several inodes. and there's aprompt asking yor no about cloning them.
Needless to say- I am quite aware that my lack of understanding risks avoidable data loss. Any suggestions both on what to do and the best training document/s so I can understand why/how this issue happened in the first place will be appreciated. This is one of those gaps in my understanding of Linux admin skills. Either this is so drop dead simple that I will feel more of an idiot for not having "known" what is going on..Or it's going to be non-trivial to recover from.
My first suggested fix was using Puppy etc and an external drive to simply grab any unique personal files that are intact- then DBAN wipe that drive before starting over. Which is what I cal a "Last Resort First" tactic . I hate having to use them, but LRF type methods have become a major mental hygiene tool for me :)
Of course- I am deeply curious if my oft preached model for data protection- keeping the OS and Userdata on physically separate drives would have helped here -or not.. -- Oren Beck
816.729.3645 _______________________________________________ KCLUG mailing list KCLUG@kclug.org http://kclug.org/mailman/listinfo/kclug
fsck -y
Dude, you're insane. "Fsck -y" is like having unprotected sex with the entire adult entertainment industry. Please, anyone paying attention to this thread do not run "fsck -y". That is just flat out dangerous, and could really screw up your fs. Seriously, why did they ever add that option? In fact, I'd recommend everyone download the source and disable that sick bit of code and recompile. this is an absolute total last resort option, before doing a complete wipe of the filesystem. I would never run this option. But that's just me. Brian --- On Wed, 9/1/10, Jonathan Hutchins <hutchins@tarcanfel.org> wrote:
From: Jonathan Hutchins 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.org Date: Wednesday, September 1, 2010, 12:23 PM fsck -y _______________________________________________
On Friday 03 September 2010 09:32:39 am Jack wrote:
Seriously, why did they ever add that option?
Because it's a useful option which is used frequently with no worse trouble than the original corruption warrants. Not everybody is pedanticly obsessive about fixing individual file nodes, and it's usually not worth the additional work for the small increase in perceived "safety". Remember, if we're that smart, we have backups.
On Fri, Sep 03, 2010 at 07:32:39AM -0700, Jack wrote:
Dude, you're insane.
"Fsck -y" is like having unprotected sex with the entire adult entertainment industry.
Please, anyone paying attention to this thread do not run "fsck -y". That is just flat out dangerous, and could really screw up your fs. Seriously, why did they ever add that option? In fact, I'd recommend
Something to do with not wanting to press "y" 10,000 times, I expect.
everyone download the source and disable that sick bit of code and recompile. this is an absolute total last resort option, before doing a complete wipe of the filesystem. I would never run this option. But that's just me.
Brian
Thanks, -- Hal
--- On Fri, 9/3/10, Hal Duston hal wrote:
From: Hal Duston 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.org Date: Friday, September 3, 2010, 8:31 AM On Fri, Sep 03, 2010 at 07:32:39AM -0700, Jack wrote:
Dude, you're insane.
"Fsck -y" is like having unprotected sex with the entire adult entertainment industry.
Please, anyone paying attention to this thread do not run "fsck -y". That is just flat out dangerous, and could really screw up your fs. Seriously, why did they ever add that option? ...
Something to do with not wanting to press "y" 10,000 times, I expect.
Lol, well if you have 10,000 multiply linked inodes, your time would be better used in running fdisk rather than fsck. It was my impression the original poster only had a few multiply linked inodes. 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. For an ext2/ext3 fs the "fsck -p" gives almost the same result. This will automatically fix any error that is "safe" to fix, without assuming an answer of "yes" to *every* question. Now if you know every question that fsck might possibly ask and know that you want to answer "yes" to all of those questions then it makes sense to use he "-y". I'm simply not that confident that I know all the questions should be answered "yes". But if you miss one question and it winds up deleting grub or some other system critical file like fsck, you might be totally screwed. Brian
On Fri, Sep 3, 2010 at 2:33 PM, Jack <quiet_celt@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
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@gmail.com> wrote: From: Christofer C. Bell <christofer.c.bell@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@kclug.org> Date: Friday, September 3, 2010, 7:06 PM On Fri, Sep 3, 2010 at 2:33 PM, Jack <quiet_celt@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@kclug.org http://kclug.org/mailman/listinfo/kclug
Perhaps there's a gem of good information hidden in here, but you've shrouded it in so much dramatic language that I find myself lacking the will to follow up on it. Seriously Jack, cut out the hyperbole and dramatics. You're sounding like Chicken Little. For most people who encounter filesystem corruption, fsck -y is perfectly fine. Yes, you're right, in certain circumstances it can make things worse. But then again, in those circumstances a sysadmin would just restore from backup. If there's no backup and the data is important then I don't think a lay person needs to be messing with it at all - they ought to pay the money to have a pro recover it. Either way, speak more factually and less dramatically. Jeffrey. On Sun, Sep 5, 2010 at 1:34 AM, Jack <quiet_celt@yahoo.com> wrote:
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
Jeffrey, I'm not being dramatic, merely stating the facts. Feel free to point out which of my statements is not factual, and correct me if you find an error in anything I said. Please be specific and quote verifiable sources for your proofs. While fsck -y is usually safe or fine if you are getting errors strictly because of a power outage or the system didn't do an orderly shutdown, it is not safe if there is a real hardware issue. It is probably never safe to do on a reiserfs. There are other more obscure filesystems where it isn't safe. Also, being "fine" is not equal to "no data loss". The original request was to know how to prevent "data loss". Not what was fine. So calling "fsck -y" fine is not even on point and irrelevatnt to the question at hand, and may cause the person asking how to preserve data to lose the very data they are seeking to save. Why use it, when there are safer alternatives? You like using it, fine go ahead. But just because you think it's fine and safe, but offer no proof, don't chide me for trying to answer a question seeking detailed knowledge of the fsck command with facts. I believe I've given references for my statements. I've not seen anyone else offer anything other than personal opinions, generic praise of how wonderful the "-y" option is, and slams on my level of paranoia. Please feel free to correct me, if I'm wrong. But at least have the courtesy of providing references that can be checked to back up your statements. General references such "for most people..." or "IBM says .." provides no provable or disprovable information. At least a clue where to find the "IBM says ..." reference. Maybe you should stop being so nonchalent and offer more factual answers. Because, I'm fairtly sure that saying something is fine to run that might cause data loss is not 100% factually correct if one is trying to prevent data loss. Jack --- On Sun, 9/5/10, Jeffrey Watts <jeffrey.w.watts@gmail.com> wrote: From: Jeffrey Watts <jeffrey.w.watts@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: "Jack" <quiet_celt@yahoo.com> Cc: "Kclug" <kclug@kclug.org> Date: Sunday, September 5, 2010, 2:32 PM Perhaps there's a gem of good information hidden in here, but you've shrouded it in so much dramatic language that I find myself lacking the will to follow up on it. Seriously Jack, cut out the hyperbole and dramatics. You're sounding like Chicken Little. For most people who encounter filesystem corruption, fsck -y is perfectly fine. Yes, you're right, in certain circumstances it can make things worse. But then again, in those circumstances a sysadmin would just restore from backup. If there's no backup and the data is important then I don't think a lay person needs to be messing with it at all - they ought to pay the money to have a pro recover it. Either way, speak more factually and less dramatically. Jeffrey. On Sun, Sep 5, 2010 at 1:34 AM, Jack <quiet_celt@yahoo.com> wrote: 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, Sep 10, 2010 at 3:34 PM, Jack <quiet_celt@yahoo.com> wrote:
I'm not being dramatic, merely stating the facts. Feel free to point out which of my statements is not factual, and correct me if you find an error in anything I said. Please be specific and quote verifiable sources for your proofs.
Oh please, give me a break. Sources for my proofs? LOL, I didn't realize that you were defending your dissertation. I'm not asserting that your statements have no merit, I'm arguing that your presentation was flawed. You quickly turned the thread away from the original poster's intent and turned it into a discussion on your strange hatred of a command line option on a rather mundane tool. I really could have done without that. Since you wanted examples, here are some of the statements you made that struck me as dubious or hyperbolic: * "Fsck -y" is like having unprotected sex with the entire adult entertainment industry. (I actually laughed at this one, but despite its fun factor it's clearly hyperbolic) * Please, anyone paying attention to this thread do not run "fsck -y". That is just flat out dangerous, and could really screw up your fs. Seriously, why did they ever add that option? In fact, I'd recommend everyone download the source and disable that sick bit of code and recompile (LOL, let me get right on that one...) * 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. (in this example I'd argue that the exact OPPOSITE is true) There is some good information contained in your posts, and I agree that the original poster was probably looking for more information than just "fsck -y". However I didn't like that you felt that you needed to go on this crusade about the -y option. You could have made your point with much less hot air. I also stand by my assertion that for the majority of people, in the majority of cases of file system corruption, "fsck -y" is the best option. It's also what is generally recommended by others in this profession. Remember, most folks facing this problem aren't experts and don't have the knowledge, tools, or inclination to do a thorough recovery. My "source" for this opinion is my experience in working with Linux for sixteen years~ Jeffrey.
On Fri, Sep 10, 2010 at 5:28 PM, Jeffrey Watts <jeffrey.w.watts@gmail.com>wrote:
On Fri, Sep 10, 2010 at 3:34 PM, Jack <quiet_celt@yahoo.com> wrote:
I'm not being dramatic, merely stating the facts. Feel free to point out which of my statements is not factual, and correct me if you find an error in anything I said. Please be specific and quote verifiable sources for your proofs.
My "source" for this opinion is my experience in working with Linux for sixteen years~
My source for Sun's opinion is the Tier 3 storage support engineer I was on the phone with trying to recover a failed Veritas volume on a Sun V880 a couple of years ago. My source for HP's opinion are the other admins in the office who have been administering HP-UX systems in production (anything from old workstations to Superdomes, to Integrity RX8640s, 2000+ servers) for a reasonable length of time[1]. My source for IBM's opinion is a guy I used to work with who is sort of the lead architect of the company's AIX deployment (1000+ servers) and has been working with AIX for a reasonable length of time[1]. My source for Linux information is my own 16 years of experience (since October of 1994) in using and administering Linux systems, both personally and professionally, and having to perform filesystem recovery from time to time. Obviously none of my sources are verifiable as I'm not about to give out company phone numbers on this mailing list (nor would my coworkers appreciate the call) and while I can't remember the name of the Sun storage engineer, even if I did, you'd not be able to speak with him without a valid Sun support contract (and I'm sure he'd not appreciate the call, either). [1] "a reasonable length of time" is defined here as "employed professionally in this role for a period of time in excess of 10 years." -- Chris
On Fri, Sep 10, 2010 at 7:05 PM, Christofer C. Bell < christofer.c.bell@gmail.com> wrote:
On Fri, Sep 10, 2010 at 5:28 PM, Jeffrey Watts <jeffrey.w.watts@gmail.com>wrote:
On Fri, Sep 10, 2010 at 3:34 PM, Jack <quiet_celt@yahoo.com> wrote:
I'm not being dramatic, merely stating the facts. Feel free to point out which of my statements is not factual, and correct me if you find an error in anything I said. Please be specific and quote verifiable sources for your proofs.
My "source" for this opinion is my experience in working with Linux for sixteen years~
My source for Sun's opinion is the Tier 3 storage support engineer I was on the phone with trying to recover a failed Veritas volume on a Sun V880 a couple of years ago.
I should add that my source for SGI's opinion is the Tier 3 storage engineer I was on the phone with earlier this year (nice guy from Texas, can't remember his name, either) while I was troubleshooting a rather nasty failure in a TP9500 storage array attached to an SGI Origin 300 cluster of 2 nodes. The filesystem in this case is xfs under IRIX 6.5. I'm sure Jeffrey will get a kick out of that one, too. :-P -- Chris
On Fri, 03 Sep 2010 12:33:13 -0700, Jack wrote:
--- On Fri, 9/3/10, Hal Duston hal wrote:
From: Hal Duston 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.org Date: Friday, September 3, 2010, 8:31 AM On Fri, Sep 03, 2010 at 07:32:39AM -0700, Jack wrote:
Dude, you're insane.
"Fsck -y" is like having unprotected sex with the entire adult entertainment industry.
Please, anyyour paying attention to this thread do not run "fsck -y". That is just flat out dangerous, and could really screw up your fs. Seriously, why did they ever add that option? ...
Something to do with not wanting to press "y" 10,000 times, I expect.
Lol, well if you have 10,000 multiply linked inodes, your time would be better used in running fdisk rather than fsck. It was my impression the original poster only had a few multiply linked inodes.
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.
For an ext2/ext3 fs the "fsck -p" gives almost the same result. This will automatically fix any error that is "safe" to fix, without assuming an answer of "yes" to *every* question. Now if you know every question that fsck might possibly ask and know that you want to answer "yes" to all of those questions then it makes sense to use he "-y". I'm simply not that confident that I know all the questions should be answered "yes". But if you miss your question and it winds up deleting grub or some other system critical file like fsck, you might be totally screwed.
So, if your find yourself at the point of pressing 'y' thousands of times and don't have a the budget to hire an expert to carefully research out the proper response to each of the questions nor the knowledge to do the research yourself, and don't have a backup of your data; you would be better served by packing up your system, returning it to the place of purchase and going back to using a pencil, pen or at the most a Smith-Corona as you are clearly to stupid to own a computer. Thanks, -- Hal hald@kc.rr.com
--- On Fri, 9/10/10, Hal Duston wrote: ...
thread do not
run "fsck -y".
That is just flat out dangerous, and could really screw up your fs. Seriously, why did they ever add that option? ...
Something to do with not wanting to press "y" 10,000 times, I expect.
Lol, well if you have 10,000 multiply linked inodes, your time would be better used in running fdisk rather than fsck. It was my impression the original poster only had a few multiply linked inodes.
...
So, if your find yourself at the point of pressing 'y' thousands of times and don't have a the budget to hire an expert to carefully research out the proper response to each of the questions nor the knowledge to do the research yourself, and don't have a backup of your data; you would be better served by packing up your system, returning it to the place of purchase and going back to using a pencil, pen or at the most a Smith-Corona as you are clearly to stupid to own a computer.
I wouldn't necessarily say that. If your system is so messed up the you have thousands of multiply linked errors, it's clearly a sign of something seriously wrong. Considering the filesystem is the lifeblood of any system, it would be wise to get someone who is experienced with filesystems to help, when a serious issue like that crop up. I fiddle with my own car, but wouldn't begin to try to rebuild/repair the engine myself, even though I know what all the major parts are and where they go. Just because an option exists for a program doesn't mean it's a good idea to use it, without knowing what you're doing. But, quite a few listers think it's fine. I don't. But, I guess, I did make some statements that were taken more seriously than they were meant to be. If I had a system reporting thousands of fs errors, I'd dd it to another device, wipe the drive/partition, do some serious forensics on the device, (buy a new drive,) and try to retrieve any salvageable files from the (too little too late backup). The "y" option might be fine 9 times out of 10 or 999:1000, but what about that other time? I guess it really all depends on how important your files are to you. Although, if you know what you're doing the "y" option is ok. I don't see much purpose to it, in most cases. There are safer less destructive alternatives. But then, if the files were important you backed them up right? Although, that's not always a fix either. Several years back, my production disk died, suddenly without warning. Then my alternate died within a few days, and my secondary backup right after. I failed to make a new backup after the first crash. By the second crash it was too late. Then my final DVD back up was unreadable. All I had left were very old backups and partials. Months of important stuff gone. Jack
On Fri, Sep 10, 2010 at 6:08 PM, Hal Duston <hald@kc.rr.com> wrote:
So, if your find yourself at the point of pressing 'y' thousands of times and don't have a the budget to hire an expert to carefully research out the proper response to each of the questions nor the knowledge to do the research yourself, and don't have a backup of your data; you would be better served by packing up your system, returning it to the place of purchase and going back to using a pencil, pen or at the most a Smith-Corona as you are clearly to *[sic]* stupid to own a computer.
Muphry's Law strikes!
participants (7)
-
Christofer C. Bell -
Hal Duston -
Jack -
Jeffrey Watts -
Jonathan Hutchins -
Monty J. Harder -
Oren Beck