On Mon, 2010-10-18 at 17:32 -0400, Edward Ned Harvey wrote:
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Marty Scholes
> >
> > Would it make sense for scrub/resilver to be more aware of operating in
> > disk order instead of zfs order
On Wed, Oct 20, 2010 at 2:50 PM, Edward Ned Harvey wrote:
> One of the above mentioned disks needed to be resilvered yesterday.
> (Actually a 2T disk.) It has now resilvered 1.12T in 18.5 hrs, and has 10.5
> hrs remaining. This is a mirror. The problem would be several times worse
> if it were
> From: Edward Ned Harvey [mailto:sh...@nedharvey.com]
>
> Let's crunch some really quick numbers here. Suppose a 6Gbit/sec
> sas/sata bus, with 6 disks in a raid-5. Each disk is 1TB, 1000G, and
> each disk is capable of sustaining 1 Gbit/sec sequential operations.
> These are typical measureme
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Marty Scholes
>
> Would it make sense for scrub/resilver to be more aware of operating in
> disk order instead of zfs order?
It would certainly make sense. As mentioned, even if you do the en
> Richard wrote:
> Yep, it depends entirely on how you use the pool. As soon as you
> come up with a credible model to predict that, then we can optimize
> accordingly :-)
You say that somewhat tongue-in-cheek, but Edward's right. If the resliver
code progresses in slab/transaction-group/whatev
On Mon, 18 Oct 2010, Edward Ned Harvey wrote:
sec to resilver = 133min. So whenever people have resilver times longer
than that ... It's because ZFS resilver code for raidzN is inefficient.
You keep using the term "code" and using terms like "code is
inefficient" when it seems that you are ta
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> > This is one of the reasons the raidzN resilver code is inefficient.
> > Since you end up waiting for the slowest seek time of any one disk in
> > the vdev, and when that's done, the amount of data you were able to
> > process was at mo
On Oct 17, 2010, at 6:38 AM, Edward Ned Harvey wrote:
> The default blocksize is 128K. If you are using mirrors, then each block on
> disk will be 128K whenever possible. But if you're using raidzN with a
> capacity of M disks (M disks useful capacity + N disks redundancy) then the
> block si
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/17/2010 9:38 AM, Edward Ned Harvey wrote:
>
> The default blocksize is 128K. If you are using mirrors, then
> each block on disk will be 128K whenever possible. But if you're
> using raidzN with a capacity of M disks (M disks useful capacity
On Sun, 17 Oct 2010, Edward Ned Harvey wrote:
The default blocksize is 128K. If you are using mirrors, then each
block on disk will be 128K whenever possible. But if you're using
raidzN with a capacity of M disks (M disks useful capacity + N disks
redundancy) then the block size on each in
The default blocksize is 128K. If you are using mirrors, then each block on
disk will be 128K whenever possible. But if you're using raidzN with a
capacity of M disks (M disks useful capacity + N disks redundancy) then the
block size on each individual disk will be 128K / M. Right? This is one
11 matches
Mail list logo
