On Jan 15, 2012, at 8:49 PM, Bob Friesenhahn wrote:
> On Sun, 15 Jan 2012, Edward Ned Harvey wrote:
>>
>> Such failures can happen undetected with or without ECC memory. It's simply
>> less likely with ECC. The whole thing about ECC memory... It's just doing
>> parity. It's a very weak checks
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 Jan 15, 2012, at 7:04 AM, Jim Klimov wrote:
> "Does raidzN actually protect against bitrot?"
> That's a kind of radical, possibly offensive, question formula
> that I have lately.
Simple answer: no. raidz provides data protection. Checksums verify
data is correct. Two different parts of the st
On Sun, 15 Jan 2012, Edward Ned Harvey wrote:
Such failures can happen undetected with or without ECC memory. It's simply
less likely with ECC. The whole thing about ECC memory... It's just doing
parity. It's a very weak checksum. If corruption happens in memory, it's
I am beginning to be
On Sun, 15 Jan 2012, Edward Ned Harvey wrote:
While I'm waiting for this to run, I'll make some predictions:
The file is 2GB (16 Gbit) and the disk reads around 1Gbit/sec, so reading
the initial sequential file should take ~16 sec
After fragmentation, it should be essentially random 4k fragments
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Gary Mills
>
> There's actually no such thing as bitrot on a disk. Each sector on
> the disk is accompanied by a CRC that's verified by the disk
> controller on each read. It will either retu
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
> 2012-01-15 19:38, Edward Ned Harvey wrote:
> >> 1) How does raidzN protect agaist bit-rot without known full
> >>death of a component disk, if it at all does?
> > zfs can
> From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us]
>
> On Thu, 12 Jan 2012, Edward Ned Harvey wrote:
> > Suppose you have a 1G file open, and a snapshot of this file is on disk
from
> > a previous point in time.
> > for ( i=0 ; i<1trillion ; i++ ) {
> > seek(random integer in range[
On 15/01/12 10:38 AM, Edward Ned Harvey wrote:
...
Linux is going with btrfs. MS has their own thing. Oracle continues with
ZFS closed source. Apple needs a filesystem that doesn't suck, but they're
not showing inclinations toward ZFS or anything else that I know of.
Rumours have long circu
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-15 20:43, Gary Mills пишет:
On Sun, Jan 15, 2012 at 04:06:33PM +, Peter Tribble wrote:
On Sun, Jan 15, 2012 at 3:04 PM, Jim Klimov wrote:
"Does raidzN actually protect against bitrot?"
That's a kind of radical, possibly offensive, question formula
that I have lately.
Yup, it does
Gary Mills wrote:
On Sun, Jan 15, 2012 at 04:06:33PM +, Peter Tribble wrote:
On Sun, Jan 15, 2012 at 3:04 PM, Jim Klimov wrote:
"Does raidzN actually protect against bitrot?"
That's a kind of radical, possibly offensive, question formula
that I have lately.
Yup, it does. Th
On Sun, Jan 15, 2012 at 04:06:33PM +, Peter Tribble wrote:
> On Sun, Jan 15, 2012 at 3:04 PM, Jim Klimov wrote:
> > "Does raidzN actually protect against bitrot?"
> > That's a kind of radical, possibly offensive, question formula
> > that I have lately.
>
> Yup, it does. That's why many of us
2012-01-15 20:06, Peter Tribble wrote:
(Try writing over one
half of a zfs mirror with dd and watch it cheerfully repair your data
without an actual error in sight.)
Are you certain it always works?
AFAIK, mirror reads are round-robined (which leads to parallel
read performance boosts). Only if
On Sun, 15 Jan 2012, Jim Klimov wrote:
1) How does raidzN protect agaist bit-rot without known full
death of a component disk, if it at all does?
Or does it only help against "loud corruption" where the
disk reports a sector-access error or dies completely?
Here is a layman's answer sinc
2012-01-15 19:38, Edward Ned Harvey wrote:
>> 1) How does raidzN protect agaist bit-rot without known full
>>death of a component disk, if it at all does?
> zfs can read disks 1,2,3,4... Then read disks 1,2,3,5...
> Then read disks 1,2,4,5... ZFS can figure out which disk
> returned the faul
On Sun, Jan 15, 2012 at 3:04 PM, Jim Klimov wrote:
> "Does raidzN actually protect against bitrot?"
> That's a kind of radical, possibly offensive, question formula
> that I have lately.
Yup, it does. That's why many of us use it.
> The way I get it, RAID5/6 generally has no mechanism to detect
2012-01-15 19:16, Edward Ned Harvey пишет:
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
boun...@opensolaris.org] On Behalf Of Jim Klimov
2) In particular, if I wanted to make a mirror of raidzN's,
can it be done in one ZFS pool, or would I have to play
with iSCSI and ZVOLs?
A
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
> 1) How does raidzN protect agaist bit-rot without known full
> death of a component disk, if it at all does?
> Or does it only help against "loud corruption" where the
>
Does ZFS currently attempt to group metadata in large sector-ranges
on the disk? Can this be expected to happen "automagically" - i.e.
during each TXG close we have to COW-update whole branches of the
blockpointer tree, so these new blocks might "just happen" to always
coalesce into larger sector
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
> 2) In particular, if I wanted to make a mirror of raidzN's,
> can it be done in one ZFS pool, or would I have to play
> with iSCSI and ZVOLs?
Although you can probably do someth
"Does raidzN actually protect against bitrot?"
That's a kind of radical, possibly offensive, question formula
that I have lately.
Reading up on theory of RAID5, I grasped the idea of the write
hole (where one of the sectors of the stripe, such as the parity
data, doesn't get written - leading to
How nested can be the VDEV tree? All the examples I've
seen suggested 3 layers - root vdev, striping over some
top-level vdevs (if present), made (redundantly) of some
physical/leaf vdevs.
In trivial cases this goes down to two levels (a root
striping over non-redundant leaf vdevs) or one lev
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
24 matches
Mail list logo