dbench cleanup bug

[Steve French]

tridge at samba.org wrote:
> Steve,
>
>  > Both Shirish and one of our testers has, and the newer version of dbench 
>  > from the download site (by the way, I like that version much better) 
>  > does not appear to make a difference for the open file - but adding a 
>  > wait before the client process deletes the files does.
>
> then please look at why, don't just add a wait.
>
>   
OK - I debugged through this myself a few minutes ago.  Interestingly 
the testers
had not noticed that the directory is left over when run locally as well 
(not just
cifs).   In any case a wait should never have helped anything.    Turns out
dbench clearly leaves data files open during cleanup and this is not a 
cifs bug.
just an obvious part of dbench behavior so even if rmdir were being issued
during cleanup (which it is not) rmdir would have failed to Windows 
servers.  
Interesting that current dbench, unlike older dbench, does not do rmdir 
at all (which
turns out to be a minor bug in the dbench version at 
http://samba.org/~tridge/dbench).
fileio.c is missing a call to:
    rmdir(dname);
at the end of the function nb_deltree() in dbench/fileio.c and the 
redundant line
    rmdir(dname);
at the next to last line of nb_cleanup in the same file (which would 
have removed
the top directory if the child directories had been removed) is 
redundant and
can be deleted.

Depending on where it is in client.txt, most of the time dbench leaves 
various data
files open of course because the test case can end while various
data files are open, but never get to execute the client.txt operation 
"Unlink" which may
follow a few lines lower in client.txt.  For example, running lsof
I clearly see 4 data files open (after the test is complete, checking 
open files at
the end of nb_cleanup) in this typical dbench run:

dbench    12045     stevef    5u      REG       0,16      4096  101164 
/mnt/tmp1/clients/client0/~dmtmp/PARADOX/ANSWER.MB (deleted)
dbench    12045     stevef    6u      REG       0,16         0  101166 
/mnt/tmp1/clients/client0/~dmtmp/PARADOX/ANSWER.DB (deleted)
dbench    12045     stevef   18u      REG       0,16      4096  101158 
/mnt/tmp1/clients/client0/~dmtmp/PARADOX/__40D6B.DB (deleted)
dbench    12045     stevef   19u      REG       0,16      4096  101160 
/mnt/tmp1/clients/client0/~dmtmp/PARADOX/__414F2.DB (deleted)

Note that after cleanup completes no files are left over  even when run 
over cifs - cifs marks
the files delete-on-close and after the dbench process exits the last 
reference to these open data
files closes and they (which were marked "delete on close" earlier 
during cleanup
by the cifs client) do go away.   To Windows servers, there is not much 
any client can do
to remove a directory when a file is open so I don't see any obvious 
workarounds but
with the new posix open/posix unlink at least it does not happen to Samba.

> The delete of a file is always done by the same process that has the
> file open, so sleeping before the delete will make no difference as to
> whether the file is open or not. 
>
> If the wait causes dbench to work better with cifsfs then I suspect a
> bug in cifsfs.
>
> Cheers, Tridge
>
>