nSome of the features requested include (not
prioritized):
uDevelop corruption analysis logic.
What is this? Folks familiar
with HP’s Hazard know how
valuable this is: data re-read logic, I/O history, metadata prowlers, and detailed analysis of expected and received data. A lot of work is involved here, especially with file system prowlers, which are
responsible for converting file system data structures to physical underlying LBA’s, to help
identify bad data in analyzer traces. See http://web.rtp.netapp.com/~rtmiller/prowlers.html
uImproved file system testing.
Although not developed as a file system exerciser, many folks use it this way. Multiple processes creating unique data
files generates a data load,
but many file system specific features, such as truncating files, file locking, creating lots of metadata (via subdirectories),
and many more are not tested. Major effort here!
uSupporting multiple devices in one dt invocation (perhaps a comma separated list). Although multiple processes or threads could accomplish
this, it does add complexity
requiring locking and switching to reentrant library API’s, and the savings in shared code is minimal (I think) since most of the
address space is data buffers.
uMultiple threads for I/O is likely to be implemented one day. This hasn’t been implemented (to date) since POSIX AIO provided for my
need, and most modern day OS’s
now support POSIX AIO. Interestingly
enough, the Linux AIO library is implemented
via POSIX threads! Threads are
lightweight processes so improve system resource utilization (reduce process slots, less
paging/swap space, etc).
uSupport 64-bit LBA encoding for large disk capacity testing.
uImplement block tagging. Encodes
more information than prefix strings.