2012-01-18 20:36, Nico Williams wrote:
On Wed, Jan 18, 2012 at 4:53 AM, Jim Klimovjimkli...@cos.ru 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
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 Wed, Jan 18, 2012 at 4:53 AM, Jim Klimov jimkli...@cos.ru 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.
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 cause
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 memory system
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
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’ll
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,
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 paper:
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
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
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
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
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 entire directory branch
drops off the tree
14 matches
Mail list logo
