11/17/2007
Data Test Program (dt)
48
Future Enhancements?
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.