can you guess? wrote:
>> can you guess? wrote:
>>
>>> This is a bit weird: I just wrote the following
>>>
>> response to a dd-b post that now seems to have
>> disappeared from the thread. Just in case that's a
>> temporary aberration, I'll submit it anyway as a new
>> post.
>>
>>>
>>>
>> Strange things certainly happen here now and then.
>>
>> The post you're replying to is one I definitely did
>> send in. Could I
>> have messed up and sent it just to you, thus causing
>> confusion when you
>> read it, deleted it, remembered it as in the group
>> rather than direct?
>>
>
> I used the forum's 'quote original' feature in replying and then received a
> screen-full of Java errors saying that the parent post didn't exist when I
> attempted to submit it.
>
> Most of the balance of your post isn't addressed in any detail because it
> carefully avoids the fundamental issues that I raised:
>
Not true; and by selective quoting you have removed my specific
responses to most of these issues.
> 1. How much visible damage does a single-bit error actually do to the kind
> of large photographic (e.g., RAW) file you are describing? If it trashes the
> rest of the file, as you state is the case with jpeg, then you might have a
> point (though you'd still have to address my second issue below), but if it
> results in a virtually invisible blemish they you most certainly don't.
>
I addressed this quite specifically, for two cases (compressed raw vs.
uncompressed raw) with different results.
> 2. If you actually care about your data, you'd have to be a fool to entrust
> it to *any* single copy, regardless of medium. And once you've got more than
> one copy, then you're protected (at the cost of very minor redundancy
> restoration effort in the unlikely event that any problem occurs) against the
> loss of any one copy due to a minor error - the only loss of non-negligible
> likelihood that ZFS protects against better than other file systems.
>
You have to detect the problem first. ZFS is in a much better position
to detect the problem due to block checksums.
> If you're relying upon RAID to provide the multiple copies - though this
> would also arguably be foolish, if only due to the potential for trashing all
> the copies simultaneously - you'd probably want to schedule occasional
> scrubs, just in case you lost a disk. But using RAID as a substitute for
> off-line redundancy is hardly suitable in the kind of archiving situations
> that you describe - and therefore ZFS has absolutely nothing of value to
> offer there: you should be using off-line copies, and occasionally checking
> all copies for readability (e.g., by copying them to the null device - again,
> something you could do for your on-line copy with a cron job and which you
> should do for your off-line copy/copies once in a while as well.
>
You have to detect the problem first. ZFS block checksums will detect
problems that a simple read-only pass through most other filesystems
will not detect.
> In sum, your support of ZFS in this specific area seems very much knee-jerk
> in nature rather than carefully thought out - exactly the kind of
> 'over-hyping' that I pointed out in my first post in this thread.
>
And your opposition to ZFS appears knee-jerk and irrational, from this
end. But telling you that will have no beneficial effect, any more than
what you just told me about how my opinions appear to you. Couldn't we
leave personalities out of this, in future?
> ...
>
>
>>>> And yet I know many people who have lost data in
>>>>
>> ways
>>
>>>> that ZFS would
>>>> have prevented.
>>>>
>>>>
>>> Specifics would be helpful here. How many? Can they
>>>
>> reasonably be characterized as consumers (I'll remind
>> you once more: *that's* the subject to which your
>> comments purport to be responding)? Can the data loss
>> reasonably be characterized as significant (to
>> 'consumers')? Were the causes hardware problems that
>> could reasonably have been avoided ('bad cables'
>> might translate to 'improperly inserted, overly long,
>> or severely kinked cables', for example - and such a
>> poorly-constructed system will tend to have other
>> problems that ZFS cannot address)?
>>
>>>
>>>
>> "Reasonably avoided" is irrelevant; they *weren't*
>> avoided.
>>
>
> While that observation has at least some merit, I'll observe that you jumped
> directly to the last of my questions above while carefully ignoring the three
> questions that preceded it.
>
>
You'll notice (since you responded) that I got to at least one of them
by the end of the message. And you cut out of your quotes what I
specifically said about cables; that's cheating. So I responded to *at
least* two of the things you say I didn't respond to.
> ...
>
>
>> Nearly everybody I can think of who's used a computer
>> for more than a
>> couple of years has stories of stuff they've lost.
>>
>
> Of course they have - and usually in ways that ZFS would have been no help
> whatsoever in mitigating.
>
ZFS will help detect problems with marginal drives, cables, power
supplies, controllers, memory, and motherboards. The block checksumming
will show corruptions earlier on, and less ambiguously, giving you a
warning that there's a problem to find and fix that you mostly didn't
get before. This will on average reduce the amount of damage done
before the problem is fixed.
And, of course, since ZFS can be used for data redundancy, it can help
protect against more drastic problems like whole drives going bad, or
tracks going bad.
Those cover the majority of ways people I know have lost data. (Other
ways include theft and user error, neither of which ZFS helps with very
much.)
> I
>
>> knew a lot of
>> people who lost their entire hard drive at one point
>> or other especially
>> in the 1985-1995 timeframe.
>>
>
> Fine example of a situation where only redundancy can save you, and where
> good old vanilla-flavored RAID (with scrubbing - but, as I noted, that's
> hardly something that ZFS has any corner on) provides comparable protection
> to ZFS-with-mirroring.
>
Agreed. But ZFS *is* applicable to that case, just not *uniquely*
applicable.
> The people were quite
>
>> upset by the loss;
>> I'm not going to accept somebody else deciding it's
>> "not significant".
>>
>
> I never said such situations were not significant, David: I simply observed
> (and did so again above) that in virtually all of them ZFS offered no
> particular advantage over more conventional means of protection.
>
And I disagree, I hope finally in enough detail for you to understand my
reasoning.
> You need to get a grip and try to understand the *specifics* of what's being
> discussed here if you want to carry on a coherent discussion about it.
>
>
You need to make your language less personal and emotional when engaging
in public technical discussions.
--
David Dyer-Bennet, [EMAIL PROTECTED]; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
