November 17, 200916 yr Noticed a problem when running a bonnie++ test on a user NFS share. The aame test on a disk share (no shfs) runs with no problems. # bonnie++ -u 0 -r 1024 Using uid:0, gid:0. Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start 'em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...Bonnie: drastic I/O error (rmdir): File exists Cleaning up test directory after error. Here is what in the syslog: Nov 17 09:02:44 Tower shfs: shfs_rmdir: rmdir: /mnt/disk4/backup/test/Bonnie.12773 (39) Directory not empty
November 17, 200916 yr Might want to also make a post in the "Announcement" forum thread for 4.5beta11 about this test not working as expected with NFS. (I know you are not running the most current release, but Tom will see it there and I'm pretty sure he will be interested) The beta-8 to beta-11 changes are probably not involved in what you found in your test, but who knows... he did make some changes in handling of symbolic links. Joe L.
November 17, 200916 yr Noticed a problem when running a bonnie++ test on a user NFS share. The aame test on a disk share (no shfs) runs with no problems. # bonnie++ -u 0 -r 1024 Using uid:0, gid:0. Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start 'em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...Bonnie: drastic I/O error (rmdir): File exists Cleaning up test directory after error. Here is what in the syslog: Nov 17 09:02:44 Tower shfs: shfs_rmdir: rmdir: /mnt/disk4/backup/test/Bonnie.12773 (39) Directory not empty The 'shfs' file system is FUSE-based & I think this is due to the way Fuse handles file deletions. Please try a test for me. Download the attached 'extra.cfg' file and copy to the 'config' directory of your Flash. Then Stop array and Start array (the stop/start will cause the file to be read & take effect). Next re-run your bonnie test & see if it now works. I have not analyzed whether this option must be omitted, or is ok to be included, for general use with 'shfs' file system. Here is what the Fuse README has to say about it: hard_remove The default behavior is that if an open file is deleted, the file is renamed to a hidden file (.fuse_hiddenXXX), and only removed when the file is finally released. This relieves the filesystem implementation of having to deal with this problem. This option disables the hiding behavior, and files are removed immediately in an unlink operation (or in a rename operation which overwrites an existing file). It is recommended that you not use the hard_remove option. When hard_remove is set, the following libc functions fail on unlinked files (returning errno of ENOENT): - read() - write() - fsync() - close() - f*xattr() - ftruncate() - fstat() - fchmod() - fchown()
November 18, 200916 yr .. 'extra.cfg' file and copy to the 'config' directory of your Flash. Unrelated question... I am just curious, what else can go into that 'extra.cfg' file?
Archived
This topic is now archived and is closed to further replies.