Lonnie,
Honestly speaking I don't know what PEBCAK means. Request, If you can
explain. I am new to your world, the language and the ways.
I thought I have already replied but let me respond again to all the
messages regarding backups.
Backup was there and we restored but the day's work was lost, since
backup happend during the night.
At the cost of again being labelled who is spreading FUD, let me
repeat.
The question really is how much vulnerable a product can be to
potential problem. Yes we do take backup but that does not mean we
totally ignore system's relaibility.
I had accepted my fault earlier of running on an "ancient" code. But
Aman who is running on the code of April-03 (pls correct me Aman), a
similar problem has occurred.
Guys, I am not pointing fingers to anybody. I know nothing is 100%
perfect. But a provocation NOW can lead us to improvement,
Best Regards,
Mahesh
______________________________ Reply Separator _________________________________
Subject: Re: Data Corruption Problem
Author: netllama (netllama@xxxxxxxxxxxxx) at internet
Date: 7/30/2003 10:07 PM
Please do us all a favor, and learn how to use your mail client. This is
the 4th copy of this that i've received from you Mahesh, all without any
new content from you. Your actions thus far on this list indicate PEBCAK.
On Wed, 30 Jul 2003 mahesh.babbar@xxxxxx wrote:
>
>
>
>
> > 1. I have lost a big chunk of data. In the range of GBs. It was
> > commercially important data.
> >
>
> But apparently not "commercially important" enough to have backup
> copies of it made.
>
> >> Was restored from backup but a day's work lost. That apart,
> >> point is not really this. I understand, no file system is 100%
> >> perfect . After all, why do we take backups.
>
> >> Point really is Vulnerability Factor.
>
> No filesystem is perfect. All software has bugs. No version of XFS
> "WORKS" (to use your emphasis), they all strive to be perfect but will
> fail under some circumstances. The best the XFS team can do is to find
> those circumstances, replicate the problem and craft a solution. When
> a new combination of circumstances arises (and the fact that the XFS
> team is targeting a moving kernel project with significant changes
> happening all the time), the XFS code may exhibit a new type of
> unwanted behavior. That is life.
>
> If your data is important, you cannot trust any filesystem, on any
> operating system, on any piece of hardware, to hold the _sole_ copy of
> that data. If you put yourself in that position, then you have only
> yourself to blame. It could have been a hardware failure or an
> operating system malfunction that caused your data loss as easily as
> it could have been XFS.
>
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lonni J Friedman netllama@xxxxxxxxxxxxx
Linux Step-by-step & TyGeMo http://netllama.ipfox.com
|