Is the data written to disk during an NDMP restore not reflected in sysstat? If not, why not?
(See sysstat output below. About 8MB/sec is coming in from tape, but the write to disk is never reflected in sysstat)
Thanks, Tom
CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 29% 0 878 0 597 583 522 0 8809 0 27 38% 0 1535 0 294 503 348 0 8589 0 27 33% 0 1503 0 380 252 176 0 8516 0 27 21% 0 772 0 173 236 212 0 8847 0 27 26% 0 691 0 132 251 360 0 8903 0 27 26% 0 921 0 190 351 192 0 8709 0 27 22% 0 790 0 161 226 176 0 8589 0 27 27% 0 1140 0 246 905 344 0 8387 0 27 19% 0 677 0 138 139 268 0 8007 0 27 24% 0 732 0 148 139 236 992 8193 0 27 30% 0 760 0 178 651 996 3715 8847 0 27 20% 0 767 0 150 167 212 0 7870 0 27 20% 0 792 0 147 147 184 0 8266 0 27 20% 0 703 0 135 143 192 0 8709 0 27 23% 0 798 0 161 146 176 0 8524 0 27 22% 0 845 0 171 177 168 0 8580 0 27 22% 0 834 0 157 172 232 0 8847 0 27 33% 0 1350 0 246 231 188 0 8580 0 27 36% 0 1515 0 283 351 220 0 8589 0 27 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 32% 0 974 0 182 216 480 0 8516 0 27 40% 0 1254 0 217 308 358 0 8297 0 27 40% 0 1416 0 261 257 566 2112 8809 0 27 34% 0 1432 0 253 250 188 0 8524 0 27 38% 0 1450 0 264 298 212 0 8709 0 27 36% 0 1418 0 263 265 184 0 8912 0 27 37% 0 1581 0 288 273 156 0 8774 0 27 38% 0 1610 0 303 295 160 0 8709 0 27 35% 0 1459 0 273 261 188 0 8460 0 27 37% 0 1622 0 306 274 124 0 8645 0 27 41% 0 1756 0 341 341 180 0 8782 0 27 40% 0 1644 0 308 308 200 0 8451 0 27 40% 0 1473 0 284 258 123 0 7783 0 27 34% 0 1255 0 238 220 357 1600 8429 0 27 26% 0 974 0 257 282 136 0 8718 0 27 49% 0 1459 0 291 950 1336 0 8645 0 27 38% 0 1268 0 259 977 680 0 8718 0 27 39% 0 1411 0 262 238 352 0 8709 0 27 40% 0 1293 0 280 266 248 0 8589 0 27 42% 0 1676 0 360 1277 204 0 8838 0 27
Tom, If you are not doing a full restore, a lot of the tape read you see is just data being passed over until the tape comes to data that has been requested. A good example of this would be the spurt you see here:
19% 0 677 0 138 139 268 0 8007 0 27 24% 0 732 0 148 139 236 992 8193 0 27 30% 0 760 0 178 651 996 3715 8847 0 27 20% 0 767 0 150 167 212 0 7870 0 27
As the tape comes to data that needs to be restored, the data gets written to tape, then the tape moves on and the there is no more data to be written from this portion of the tape. Of course, if this is a full restore, then this makes no sense whatsoever.
Geoff Hardin Dallas Semiconductor MIS UNIX geoff.hardin@dalsemi.com
Is the data written to disk during an NDMP restore not reflected in sysstat? If not, why not?
(See sysstat output below. About 8MB/sec is coming in from tape, but the write to disk is never reflected in sysstat)
Thanks, Tom
Tom --
Are you running a full restore?
If you are only extracting a subtree or file from the tape, then you may be reading the tape, searching for the files you want to write.
Another possibility would be if you are running a "verification" restore. This type of restore reads through the entire tape, to make sure that everything is kosher. It does everything a normal restore would, short of actually writing the data to the file system.
Stephen Manley DAM and NDMP Disco King
CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 29% 0 878 0 597 583 522 0 8809 0 27 38% 0 1535 0 294 503 348 0 8589 0 27 33% 0 1503 0 380 252 176 0 8516 0 27 21% 0 772 0 173 236 212 0 8847 0 27 26% 0 691 0 132 251 360 0 8903 0 27 26% 0 921 0 190 351 192 0 8709 0 27 22% 0 790 0 161 226 176 0 8589 0 27 27% 0 1140 0 246 905 344 0 8387 0 27 19% 0 677 0 138 139 268 0 8007 0 27 24% 0 732 0 148 139 236 992 8193 0 27 30% 0 760 0 178 651 996 3715 8847 0 27 20% 0 767 0 150 167 212 0 7870 0 27 20% 0 792 0 147 147 184 0 8266 0 27 20% 0 703 0 135 143 192 0 8709 0 27 23% 0 798 0 161 146 176 0 8524 0 27 22% 0 845 0 171 177 168 0 8580 0 27 22% 0 834 0 157 172 232 0 8847 0 27 33% 0 1350 0 246 231 188 0 8580 0 27 36% 0 1515 0 283 351 220 0 8589 0 27 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 32% 0 974 0 182 216 480 0 8516 0 27 40% 0 1254 0 217 308 358 0 8297 0 27 40% 0 1416 0 261 257 566 2112 8809 0 27 34% 0 1432 0 253 250 188 0 8524 0 27 38% 0 1450 0 264 298 212 0 8709 0 27 36% 0 1418 0 263 265 184 0 8912 0 27 37% 0 1581 0 288 273 156 0 8774 0 27 38% 0 1610 0 303 295 160 0 8709 0 27 35% 0 1459 0 273 261 188 0 8460 0 27 37% 0 1622 0 306 274 124 0 8645 0 27 41% 0 1756 0 341 341 180 0 8782 0 27 40% 0 1644 0 308 308 200 0 8451 0 27 40% 0 1473 0 284 258 123 0 7783 0 27 34% 0 1255 0 238 220 357 1600 8429 0 27 26% 0 974 0 257 282 136 0 8718 0 27 49% 0 1459 0 291 950 1336 0 8645 0 27 38% 0 1268 0 259 977 680 0 8718 0 27 39% 0 1411 0 262 238 352 0 8709 0 27 40% 0 1293 0 280 266 248 0 8589 0 27 42% 0 1676 0 360 1277 204 0 8838 0 27
Is it also possible, perhaps, that blocks are compared to those already on disk and identical blocks are not written out? So even if you were doing a complete restore of a filesystem, if the filesystem currently on disk is an earlier version the WAFL layer might actually be smart enough not to write out unchanged data. Just a guess. It's possible that the filer doesn't have this optimization or that you gain very little from implementing it.
Bruce
-
Bruce Sterling Woodcock -
Geoff Hardin -
Stephen Manley -
Tom "Mad Dog" Yergeau