Hi Drew, > The goal is to make it easy for other file system clients, such as > nfsv3, to be added to filebench. The will supply their own routines to > implement the I/O functions, as well as custom asynchronous flowops. > > See it all at: > > http://cr.opensolaris.org/~dreww/localfs_plugin/
I took a look at the webrev and only have a few code-related nits. I don't like to complain about variable names, since it rarely matters. None the less, in flowop_library.c the the fb_fdesc_t * is named fdesc; however, in fileset.c/h the local variable of the same type is named fd. Since systems programmers often use fd as the integer file descriptor, I wonder if it would be less confusing to use fdesc in this file too? It's not the end of the world, but I thought I'd suggest the change. Can you explain a bit more about how other FS clients will plug into filebench? As the code is written now, it looks like all filesystem clients need to be built with filebench and have their source in the distribution. Is there any desire to create a binary module interface, thereby allowing FS vendors to ship pre-compiled modules? I'm not sure I see a need for this functionality, but I was curious. What's the criteria for becoming a fsplug_func_s function? Is this just based upon the current operations that filebench uses? Operations like symlink(2), link(2), and statvfs(2) aren't in the struct. Does it make sense to have these operations available for other FS clients? Thanks, -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
