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
«Note: dt now
supports re-read logic on DC’s, and a history mechanism.
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.
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 needs, and most modern day OS’s now support POSIX AIO. 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.