2012-01-18 20:36, Nico Williams wrote:
On Wed, Jan 18, 2012 at 4:53 AM, Jim Klimov wrote:
2012-01-18 1:20, Stefan Ring wrote:
I don’t care too much if a single document gets corrupted – there’ll
always be a good copy in a snapshot. I do care however if a whole
directory branch or old snapshots
On Wed, Jan 18, 2012 at 4:53 AM, Jim Klimov wrote:
> 2012-01-18 1:20, Stefan Ring wrote:
>> I don’t care too much if a single document gets corrupted – there’ll
>> always be a good copy in a snapshot. I do care however if a whole
>> directory branch or old snapshots were to disappear.
>
> Well, as
2012-01-18 1:20, Stefan Ring wrote:
The issue is definitely not specific to ZFS. For example, the whole OS
depends on relable memory content in order to function. Likewise, no one
likes it if characters mysteriously change in their word processing
documents.
I don’t care too much if a single
On Tue, 17 Jan 2012, Stefan Ring wrote:
Additionally, consider that Joyent’s port of KVM supports only Intel
systems, AFAIK.
Hopefully that will be a short-term issue. 64-core AMD Opteron
systems are affordable now.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesyst
> The issue is definitely not specific to ZFS. For example, the whole OS
> depends on relable memory content in order to function. Likewise, no one
> likes it if characters mysteriously change in their word processing
> documents.
I don’t care too much if a single document gets corrupted – there
On Tue, 17 Jan 2012, Richard Elling wrote:
Agree with the ECC comment :-)
If we can classify this as encouragement to use ECC, then you don't need to
drag ZFS
into the conversation. Interestingly, the only market that doesn't use ECC is
the PeeCee
market. Embedded and enterprise markets use EC
On Jan 16, 2012, at 8:08 AM, David Magda wrote:
> On Mon, January 16, 2012 01:19, Richard Elling wrote:
>
>>> [1] http://www.usenix.org/event/fast10/tech/full_papers/zhang.pdf
>>
>> Yes. Netapp has funded those researchers in the past. Looks like a FUD
>> piece to me.
>> Lookout everyone, the me
On Sun, 2012-01-15 at 16:28 +0400, Jim Klimov wrote:
> 2012-01-14 18:36, Stefan Ring wrote:
> > Inspired by the paper "End-to-end Data Integrity for File Systems: A
> > ZFS Case Study" [1], I've been thinking if it is possible to devise a way,
> > in which a minimal in-memory data corruption would
On 01/16/12 11:08, David Magda wrote:
The conclusions are hardly unreasonable:
While the reliability mechanisms in ZFS are able to provide reasonable
robustness against disk corruptions, memory corruptions still remain a
serious problem to data integrity.
I've heard the same thing said ("use
On Mon, January 16, 2012 01:19, Richard Elling wrote:
>> [1] http://www.usenix.org/event/fast10/tech/full_papers/zhang.pdf
>
> Yes. Netapp has funded those researchers in the past. Looks like a FUD
> piece to me.
> Lookout everyone, the memory system you bought from Intel might suck!
>From the pa
On Jan 14, 2012, at 6:36 AM, Stefan Ring wrote:
> Inspired by the paper "End-to-end Data Integrity for File Systems: A
> ZFS Case Study" [1], I've been thinking if it is possible to devise a way,
> in which a minimal in-memory data corruption would cause massive data
> loss.
For enterprise-class
On Sun, 15 Jan 2012, Jim Klimov wrote:
It does seem possible that in-memory corruption of data payload
and/or checksum of a block before writing it to disk would render
it invalid on read (data doesn't match checksum, ZFS returns EIO) .
Maybe even worse if the in-memory block is corrupted before
2012-01-14 18:36, Stefan Ring wrote:
Inspired by the paper "End-to-end Data Integrity for File Systems: A
ZFS Case Study" [1], I've been thinking if it is possible to devise a way,
in which a minimal in-memory data corruption would cause massive data
loss. I could imagine a scenario where an enti
13 matches
Mail list logo
