Re: [Xen-users] Cheap IOMMU hardware and ECC support importance

[lee <lee@xxxxxxxxxxxxxxx>]

Gordan Bobic <gordan@xxxxxxxxxx> writes:

> On 07/06/2014 11:11 AM, lee wrote:
>
>>>>>> Does ZFS do that?  Since it's about keeping the data safe, it might have
>>>>>> a good deal of protection against user errors.
>>>>>
>>>>> I don't think it's possible to guard against user errors. If you're
>>>>> concerned about user errors, get someone else to manage your machines
>>>>> and not give you the root password.
>>>>
>>>> It is possible to guard.  It's not possible to prevent them.
>>>
>>> Sacrificing productivity for hand holding  is not the *nix
>>> paradigm. It's competence of bust. I for one don't want every command
>>> I type to ask "are you sure" before it does what I told it to. All it
>>> achieves it desensitizes you to the question and you end up saying y
>>> automatically after a while, without considering what it even said.
>>
>> All the commands you issue are such that they destroy whole file
>> systems?
>
> Of course not, but there are few if any commands that have the ability
> to destroy a FS which ask for confirmation before doing so.

And that would be a good thing?

>> Why isn't there a command to uncompress the compressed data?
>
> Why would there be?

It would make sense and make it easy to uncompress the data.  Of course
you can use a light switch that requires you to move the light bulbs
into different lights to turn off the lights, or hire someone to move
them for you.  Just don't be surprised when someone else finds that a
bit inconvenient and suggests that the lights might be turned off by the
very same light switch.

>>> systems. ZFS is the only file system I have used for the data on which
>>> I never had to reach for backups.
>>
>> One of the reasons for this may very well be that you know ZFS so well.
>> I don't know it at all.
>
> I knew other file systems at least as well if not better, yet it
> didn't help.

What makes you expect better results from a file system you don't know
at all?

>> If I was to switch to this file system, I'd much more likely than you
>> make user errors because I don't know this complicated file system, and
>> I might run into problems or bugs I might not be able to recover from
>> because I don't have access to the developers or supporters.  The
>> unknown file system would have the advantage that it could prevent
>> silent data corruption, which is a problem I haven't noticed yet.  Such
>> a switch isn't very appealing, as great as this file system might be.
>
> And without a file system that detects said corruption for you, you
> will never notice it either.

The user errors, bugs and problems I might make or run into could easily
be far worse than an undetectable issue.

> You are the one that implied that not having the package in the
> distribution repository was such a big deal.

I never said it's a big deal.  Since you mention it, it could be one ---
I do not know this.  How closely does this source for ZFS
Debian-packages track what Debian packages do, the kernel packages
probably being the most relevant ones?

I'm using a Debian kernel from Debian backports which is far more recent
than what's in stable.  Now which kernel version are these ZFS packages
compatible with?

I merely assume that if there were such ZFS packages in Debian that
chances these packages work with other things in Debian are greater than
they are with packages from external sources because they have been
tested.  Perhaps the assumption is wrong, perhaps Debian doesn't do any
testing.  Yet if they do some testing to make sure that things work
(together), I find that a good reason to prefer packages that come in
the distribution over packages that don't.

Do you have a good reason to suggest that it's no "big deal" to use
these ZFS packages?  Have they been tested with the backports kernel?

> SMART numbers SHOULD give you the answer, unless the manufacturer has
> deliberately made the firmware lie about it in the interest of
> reducing warranty return rates.

Reducing warranty return rates certainly is in the interest of the
manufacturer.

>> I was thinking of errors detected by ZFS, though.  What if you see a
>> few:  Do you replace the disk, or do you wait until there are so many?
>
> Depends on the rate at which they are showing up. If every week the
> same disk throws a few errors, then yes, it is a good candidate for
> replacing. But usually there are other indications in SMART and
> syslog, e.g. command timeouts, bus resets, and similar.

Hm, interesting ... Would you say that there is a correlation between
timeouts/bus resets and errors detected by ZFS?  Like no significant
numbers of ZFS-detected errors showing up before the timeouts/resets
happen?

>>>> or does ZFS keep a list of sectors not to use anymore?
>>>
>>> As I said before, disk's handle their own defects, and have done for
>>> the past decade or two. File systems have long had no place in keeping
>>> track of duff sectors on disks.
>>
>> So ZFS may silently loose redundancy (and in a bad case data), depending
>> on what the disks do.  And there isn't any way around that, other than
>> increasing redundancy.
>
> How do you define "silently"?

"Silently" as in "not noticed" because ZFS doesn't detect the errors
before attempting to read.  When a disk behaves badly, ZFS would have to
assume that data has been written correctly while it hasn't.  For that
data, there is no redundancy because it has been "silently" lost (or
never existed).

> How would you detect disk failure with any traditional (hardware or
> software) RAID arrangement? You have to configure some kind of
> monitoring, appropriate to your system. ZFS is no different.

You wouldn't be off any better or worse with other things than ZFS when
your disks behave sufficiently badly.


-- 
Knowledge is volatile and fluid.  Software is power.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users