Re: [zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-20 Thread Edward Ned Harvey
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 measurements

Re: [zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-20 Thread Trond Michelsen
On Wed, Oct 20, 2010 at 2:50 PM, Edward Ned Harvey sh...@nedharvey.com 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

Re: [zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-20 Thread Erik Trimble
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? It

Re: [zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-18 Thread Edward Ned Harvey
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 most 128K. 

Re: [zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-18 Thread Marty Scholes
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

Re: [zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-18 Thread Edward Ned Harvey
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 entire

[zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-17 Thread Edward Ned Harvey
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

Re: [zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-17 Thread Bob Friesenhahn
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

Re: [zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-17 Thread Kyle McDonald
-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 +

Re: [zfs-discuss] RaidzN blocksize ... or blocksize in general ... and resilver

2010-10-17 Thread Richard Elling
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 size