On Thu, 9 Nov 2006, Erblichs wrote:
>
> Bill, Sommerfeld, Sorry,
>
> However, I am trying to explain what I think is
> happening on your system and why I consider this
> normal.
>
> Most of the reads/FS "replace" are normally
^^^^^
> at the block level.
>
> To copy a FS, some level of reading MUST be done
^^^^^^^^
> at the orig_dev.
> At what level and whether it is recorded as a
> normal vnode read / mmap op for the direct and
^^^^^
> indirect blocks is another story.
>
> But it is being done. It is just not being
> recorded in FS stats. Read stats are normally used
^^^^^
> for normal FS object access requests.
>
> Secondly, maybe starting with the ?uberblock?, the
> rest of the meta data is probably being read. And
^^^^^^^^^^^
> because of the normal asyn access of FSs, it would
> not surprise me that then each znode's access time
> field is updated. Remember, that unless you are just
> touching a FS low-level(file) object, all writes are
> proceeded by at least 1 read.
^^^^^^^^
> Mitchell Erblich
> ----------------
>
Mitchell - Bill is asking about WRITES and you're talking READS!
Your posts are making absolutely no sense to me....
>
>
> Bill Sommerfeld wrote:
> >
> > 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 operations bandwidth
> > pool used avail read write read write
> > ------------- ----- ----- ----- ----- ----- -----
> > z 306G 714G 1.43K 658 23.5M 1.11M
> > raidz1 109G 231G 1.08K 392 22.3M 497K
> > replacing - - 0 1012 0 5.72M
> > c1t4d0 - - 0 753 0 5.73M
> > c1t5d0 - - 0 790 0 5.72M
> > c2t12d0 - - 339 177 9.46M 149K
> > c2t13d0 - - 317 177 9.08M 149K
> > c3t12d0 - - 330 181 9.27M 147K
> > c3t13d0 - - 352 180 9.45M 146K
> > raidz1 100G 240G 117 101 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 244G 234 164 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
>
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
OpenSolaris Governing Board (OGB) Member - Feb 2006
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
