On 29-Nov-06, at 8:53 AM, Brian Hechinger wrote:
On Tue, Nov 28, 2006 at 10:48:46PM -0500, Toby Thain wrote:
Her original configuration wasn't redundant, so she should expect
this kind of manual recovery from time to time. Seems a logical
conclusion to me? Or is this one of those once-in-a-li
On Tue, Nov 28, 2006 at 10:48:46PM -0500, Toby Thain wrote:
>
> Her original configuration wasn't redundant, so she should expect
> this kind of manual recovery from time to time. Seems a logical
> conclusion to me? Or is this one of those once-in-a-lifetime strikes?
That's not an entirely tr
Christopher Scott wrote:
I currently have a server that has a much higher rate of checksum
errors than what you describe to be "normal." I knew it wasn't good
but I figured if zfs is fixing it for me why mess with it?
Is there anything I can do to troubleshoot where the problem might be
com
Anton B. Rang wrote:
Clearly, the existence of a high error rate (say, more than one error every two
weeks on a server pushing 100 MB/second) would point to a hardware or software
problem; but fewer errors may simply be “normal” for standard hardware
I currently have a server that has a much
On 28-Nov-06, at 10:35 PM, Anton B. Rang wrote:
No, you still have the hardware problem.
What hardware problem?
There seems to be an unspoken assumption that any checksum error
detected by ZFS is caused by a relatively high error rate in the
underlying hardware.
There are at least two
> No, you still have the hardware problem.
What hardware problem?
There seems to be an unspoken assumption that any checksum error detected by
ZFS is caused by a relatively high error rate in the underlying hardware.
There are at least two classes of hardware-related errors. One class are those
>> With zfs, there's this ominous
>> message saying "destroy the filesystem and restore
>> from tape". That's not so good, for one corrupt
>> file.
> It is strictly correct that to restore the data you'd need
> to refer to a backup, in this case.
It is not, however, correct that to restore the d