On 18-May-07, at 4:39 PM, Ian Collins wrote:
David Bustos wrote:
... maybe Sun should make more of the
cost savings in storage ZFS offers to gain a cost advantage over the
competition,
Cheaper AND more robust+featureful is hard to beat.
--T
___
zf
David Bustos wrote:
> Quoth Steven Sim on Thu, May 17, 2007 at 09:55:37AM +0800:
>
>>Gurus;
>>I am exceedingly impressed by the ZFS although it is my humble opinion
>>that Sun is not doing enough evangelizing for it.
>>
>
> What else do you think we should be doing?
>
>
Send
Quoth Steven Sim on Thu, May 17, 2007 at 09:55:37AM +0800:
>Gurus;
>I am exceedingly impressed by the ZFS although it is my humble opinion
>that Sun is not doing enough evangelizing for it.
What else do you think we should be doing?
David
_
HL>> And to clear things - meta data are updated also in a spirit of COW -
HL>> so metadata are written to new locations and then uber block is
HL>> atomically updated pointing to new meta data
Victor Latushkin wrote:
Well, to add to this, uber-blocks are also updated in COW fashion -
there is a
If I understand correctly, then the parity block for RAID-Z are also
written in two different atomic operations. As per RAID-5. (the only
difference being each can be of a different stripe size).
HL> As with Raid-5 on a four disk stripe, there are four independant
HL> writes, and they
Hello Henk,
Friday, May 18, 2007, 12:09:40 AM, you wrote:
>> If I understand correctly, then the parity block for RAID-Z are also
>> written in two different atomic operations. As per RAID-5. (the only
>> difference being each can be of a different stripe size).
HL> As with Raid-5 on a four
Steven Sim wrote:
I understand RAID-5 quite well and from both of your RAID-Z description,
I see that the RAID-Z parity is also a separate block on a separate
disk. Very well. This is just like RAID-5.
Yup. But there's a little bit of magic, which I'll
try to explain below. With more ascii a
Hi Steven,
Steven Sim wrote:
My confusion is simple. Would this not then give rise also to the
write-hole vulnerability of RAID-5?
Jeff Bonwick states "/that there's no way to update two or more disks
atomically, so RAID stripes can become damaged during a crash or power
outage./"
If I und
Steven Sim wrote:
Darren and Henk;
Firstly, thank you very much for both of your replies. I am very
grateful indeed for you all taking time off to answer my questions.
I understand RAID-5 quite well and from both of your RAID-Z description,
I see that the RAID-Z parity is also a separate b
Darren and Henk;
Firstly, thank you very much for both of your replies. I am very
grateful indeed for you all taking time off to answer my questions.
I understand RAID-5 quite well and from both of your RAID-Z
description, I see that the RAID-Z parity is also a separate block on a
separate di
I'll make an attempt to keep it simple, and tell what is true in 'most'
cases. For some values of 'most' ;-)
The words used are at times confusing. "Block" mostly refers to
a logical filesystem block, which can be variable in size.
There's also "checksum" and "parity", which are completely
ind
> RAID-Z is a data/parity scheme like RAID-5, but it uses
> dynamic stripe width.
> Every block is its own RAID-Z stripe, regardless of blocksize. This
> means
> that every RAID-Z write is a full-stripe write. This, when
> combined with the
> copy-on-write transactional semantics of ZFS, completely
Gurus;
I am exceedingly impressed by the ZFS although it is my humble opinion
that Sun is not doing enough evangelizing for it.
But that's beside the point.
I am writing to seek help in understanding the RAID-Z concept.
Jeff Bonwick's weblog states the following;
"
RAID-Z is a data/parity
13 matches
Mail list logo