I was going though this posting and it seems that were is some personal
tension :).
However going back to the technical problem of scrubbing a 200 TB pool I think
this issue needs to be addressed.
One warning up front: This writing is rather long, and if you like to jump to
the part dealing
sata
disks don't understand the prioritisation, so
Er, the point was exactly that there is no
discrimination, once the
request is handed to the disk.
So, do you say that SCSI drives do understand prioritisation (i.e. TCQ supports
the schedule from ZFS), while SATA/NCQ drives
On Mar 16, 2010, at 4:41 PM, Tonmaus wrote:
Are you sure that you didn't also enable
something which
does consume lots of CPU such as enabling some sort
of compression,
sha256 checksums, or deduplication?
None of them is active on that pool or in any existing file system. Maybe the
On that
occasion: does anybody know if ZFS reads all parities
during a scrub?
Yes
Wouldn't it be sufficient for stale corruption
detection to read only one parity set unless an error
occurs there?
No, because the parity itself is not verified.
Aha. Well, my understanding was that a
On Thu, Mar 18, 2010 at 05:21:17AM -0700, Tonmaus wrote:
No, because the parity itself is not verified.
Aha. Well, my understanding was that a scrub basically means reading
all data, and compare with the parities, which means that these have
to be re-computed. Is that correct?
A scrub
Hello Dan,
Thank you very much for this interesting reply.
roughly speaking, reading through the filesystem does
the least work
possible to return the data. A scrub does the most
work possible to
check the disks (and returns none of the data).
Thanks for the clarification. That's what I
On Thu, Mar 18, 2010 at 09:54:28PM -0700, Tonmaus wrote:
(and the details of how much and how low have changed a few times
along the version trail).
Is there any documentation about this, besides source code?
There are change logs and release notes, and random blog postings
along the way
On Tue, 16 Mar 2010, Tonmaus wrote:
None of them is active on that pool or in any existing file system.
Maybe the issue is particular to RAIDZ2, which is comparably recent.
On that occasion: does anybody know if ZFS reads all parities during
a scrub? Wouldn't it be sufficient for stale
Hi,
I got a message from you off-list that doesn't show up in the thread even after
hours. As you mentioned the aspect here as well I'd like to respond to, I'll do
it from here:
Third, as for ZFS scrub prioritization, Richard
answered your question about that. He said it is
low priority
Ugh! I meant that to go to the list, so I'll probably re-send it for the
benefit
of everyone involved in the discussion. There were parts of that that I
wanted
others to read.
From a re-read of Richard's e-mail, maybe he meant that the number of I/Os
queued to a device can be tuned lower and
For those following along, this is the e-mail I meant to send to the list
but
instead sent directly to Tonmaus. My mistake, and I apologize for having to
re-send.
=== Start ===
My understanding, limited though it may be, is that a scrub touches ALL data
that
has been written, including the
Hi Richard,
- scrubbing the same pool, configured as raidz1
didn't max out CPU which is no surprise (haha, slow
storage...) the notable part is that it didn't slow
down payload that much either.
raidz creates more, smaller writes than a mirror or
simple stripe. If the disks are slow,
In following this discussion, I get the feeling that you and Richard are
somewhat
talking past each other. He asked you about the hardware you are currently
running
on, whereas you seem to be interested in a model for the impact of scrubbing
on
I/O throughput that you can apply to some
Well...i can only say well said.
BTW i have a raidz2 with 9 vdevs with 4 disks each (sata enterprise
disks) and the scrub of the pool takes between 12 to 39 hours..depends
on the workload of the server.
So far it's acceptable but each case is a case i think...
Bruno
On 16-3-2010 14:04, Khyron
On Tue, 16 Mar 2010, Tonmaus wrote:
This wasn't mirror vs. raidz but raidz1 vs. raidz2, whereas the
latter maxes out CPU and the former maxes out physical disc I/O.
Concurrent payload degradation isn't that extreme on raidz1 pools,
as it seems. Hence, the CPU theory that you still seem to be
Even if it might not be the best technical solution, I think what a lot of
people are looking for when this comes up is a knob they can use to say I only
want X IOPS per vdev (in addition to low prioritization) to be used while
scrubbing. Doing so probably helps them feel more at ease that they
On Tue, March 16, 2010 11:53, thomas wrote:
Even if it might not be the best technical solution, I think what a lot of
people are looking for when this comes up is a knob they can use to say I
only want X IOPS per vdev (in addition to low prioritization) to be used
while scrubbing. Doing so
The issue as presented by Tonmaus was that a scrub was negatively impacting
his RAIDZ2 CIFS performance, but he didn't see the same impact with RAIDZ.
I'm not going to say whether that is a problem one way or the other; it
may
be expected behavior under the circumstances. That's for ZFS
Hello,
In following this discussion, I get the feeling that
you and Richard are somewhat talking past each
other.
Talking past each other is a problem I have noted and remarked earlier. I have
to admit to have got frustrated about the discussion narrowing down to a
certain perspective that
If CPU is maxed out then that usually indicates some
severe problem
with choice of hardware or a misbehaving device
driver. Modern
systems have an abundance of CPU.
AFAICS the CPU loads are only high while scrubbing a double parity pool. I have
no indication of a technical misbehaviour
On Tue, 16 Mar 2010, Tonmaus wrote:
AFAICS the CPU loads are only high while scrubbing a double parity
pool. I have no indication of a technical misbehaviour with the
exception of dismal concurrent performance.
This seems pretty weird to me. I have not heard anyone else complain
about this
Are you sure that you didn't also enable
something which
does consume lots of CPU such as enabling some sort
of compression,
sha256 checksums, or deduplication?
None of them is active on that pool or in any existing file system. Maybe the
issue is particular to RAIDZ2, which is comparably
Hello again,
I am still concerned if my points are being well taken.
If you are concerned that a
single 200TB pool would take a long
time to scrub, then use more pools and scrub in
parallel.
The main concern is not scrub time. Scrub time could be weeks if scrub just
would behave. You may
On Mar 14, 2010, at 11:25 PM, Tonmaus wrote:
Hello again,
I am still concerned if my points are being well taken.
If you are concerned that a
single 200TB pool would take a long
time to scrub, then use more pools and scrub in
parallel.
The main concern is not scrub time. Scrub time
Hi Richard,
these are
- 11x WD1002fbys (7200rpm SATA drives) in 1 raidz2 group
- 4 GB RAM
- 1 CPU L5410
- snv_133 (where the current array was created as well)
Regards,
Tonmaus
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
On Mar 14, 2010, at 12:16 AM, Tonmaus wrote:
Hi Richard,
these are
- 11x WD1002fbys (7200rpm SATA drives) in 1 raidz2 group
- 4 GB RAM
- 1 CPU L5410
- snv_133 (where the current array was created as well)
These are slow drives and the configuration will have poor random
read
Hi Richard,
thanks for the answer. I think I am aware on the properties of my configuration
and how it will scale. Let me please stress that this is not the point in the
discussion.
The target of this discussion should rather be if scrubbing can co-exist with
payload or if we are thrown back
On Mar 14, 2010, at 11:45 AM, Tonmaus wrote:
Hi Richard,
thanks for the answer. I think I am aware on the properties of my
configuration and how it will scale. Let me please stress that this is not
the point in the discussion.
The target of this discussion should rather be if scrubbing
Dear zfs fellows,
during a specific test I have got the impression that scrub may have quite an
impact on other I/O. CIFS throughput is down to 7 MB/s from 100 MB/s while
scrub on my main NAS. That is not a surprise as scrub of my raidz2 pool maxes
out CPU on that machine. (1 Xeon L5410).
I
29 matches
Mail list logo
