Re: [zfs-discuss] I/O patterns during a zpool replace: why writetothe disk being replaced?

[Erblichs]

Bill Sommerfield,

Because, first, I have seen alot of I/O
occur while a snapshot is being aged out
of a system.

I don't think that during the resilvering process 
accesses (read, writes) are completely
stopped to the orig_dev.

I expect at least some meta reads are
going on.

With some normal sporadic read failure, accessing
the whole spool may force repeated reads for
the replace.

So, I was thinking that a read access
that could ALSO be updating the znode. This newer
time/date stamp is causing alot of writes.

Depending on how the fs meta and blocks are
being accessed, the orig_dev may also 
have some normal writes until it is offlined.

Mitchell Erblich
-

Bill Sommerfeld wrote:
 
 On Wed, 2006-11-08 at 01:54 -0800, Erblichs wrote:
 
  Bill Sommerfield,
 
 that's not how my name is spelled
 
Are their any existing snaps?
 no.  why do you think this would matter?
 
Can you have any scripts that may be
removing aged files?
 no; there was essentially no other activity on the pool other than the
 replace.
 
 why do you think this would matter?
 
 - Bill
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] I/O patterns during a zpool replace: why writetothe disk being replaced?

[Bill Sommerfeld]

On Thu, 2006-11-09 at 19:18 -0800, Erblichs wrote:
 Bill Sommerfield,

Again, that's not how my name is spelled.

   With some normal sporadic read failure, accessing
   the whole spool may force repeated reads for
   the replace.

please look again at the iostat I posted:

  capacity operationsbandwidth
poolused  avail   read  write   read  write
-  -  -  -  -  -  -
z   306G   714G  1.43K658  23.5M  1.11M
  raidz1109G   231G  1.08K392  22.3M   497K
replacing  -  -  0   1012  0  5.72M
  c1t4d0   -  -  0753  0  5.73M
  c1t5d0   -  -  0790  0  5.72M
c2t12d0-  -339177  9.46M   149K
c2t13d0-  -317177  9.08M   149K
c3t12d0-  -330181  9.27M   147K
c3t13d0-  -352180  9.45M   146K
  raidz1100G   240G117101   373K   225K
c1t3d0 -  - 65 33  3.99M  64.1K
c2t10d0-  - 60 44  3.77M  63.2K
c2t11d0-  - 62 42  3.87M  63.4K
c3t10d0-  - 63 42  3.88M  62.3K
c3t11d0-  - 65 35  4.06M  61.8K
  raidz1   96.2G   244G234164   768K   415K
c1t2d0 -  -129 49  7.85M   112K
c2t8d0 -  -133 54  8.05M   112K
c2t9d0 -  -132 56  8.08M   113K
c3t8d0 -  -132 52  8.01M   113K
c3t9d0 -  -132 49  8.16M   112K

there were no (zero, none, nada, zilch) reads directed to the failing
device.  there were a lot of WRITES to the failing device; in fact, the
the same volume of data was being written to BOTH the failing device and
the new device.

   So, I was thinking that a read access
   that could ALSO be updating the znode. This newer
   time/date stamp is causing alot of writes.

that's not going to be significant as a source of traffic; again, look
at the above iostat, which was representative of the load throughout the
resilver.


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss