Here is something that is probably not as widely known as it couldbe: ZFS scrubs and resilvers are not done with sequential IO, theway conventional RAID resynchronization and checking is done.

Conventional RAID resyncs run in linear order from the start of eachdisk to the end. This means that they're strictly sequential IO ifthey're left undisturbed by user IO (which is one reason that you candestroy conventional RAID resync performance by doing enough random userIO).

ZFS scrubs and resilvers don't work

A recent thread on the ZFS mailing list concerned inaccurate ormisleading reports from zpool status about the progress of scrubs(both bad time estimates and a scrub that wasn't finishing despiteclaiming to be 100% done). As it happens, I know something about howthis works because I recently went digging into what information thekernel actually reports to userland.

The kernel reports the following information:

• the number of bytes currently allocated in the pool and in each vdev.

• how many bytes in the pool have been

Here is a thesis, or at least a theory: any email address that getstoo much noise (spam, bounces, autoresponder replies, and so on) iseffectively dead. This is especially so if the noise reaches real peopleand must be filtered by hand.

(This thesis underlies my belief that postmaster is a dead address .)

The problem with hand filtering is twofold. First, hand filtering isan unpleasant task (and a pain), which means that it will likely bedone reluctantly and as little