There's something mighty strange going on at mathworks.com: although I can follow up to existing threads, three separate attempts to post a new one to toasters@mathworks.com in the past few days have caused absolutely nothing to appear. Please excuse this attempt to determine whether it is some aspect of the content, subject, etc. that is causing them to disappear into a black hole.
Chris Thompson Email: cet1@cam.ac.uk
Yup, received by devnull /dev/null
Thank you, /dev/null :-)
I have been attempting to post the following with subjects like
Quota usage non-zero but no files to account for it
They have all disappeared into a black hole, with nothing appearing on the list or in the archive at http://teaparty.mathworks.com:1999/toasters/ . I will try yet again to get it out as this reply. Hope springs eternal...
==============================================================
A bit of background: when we cancel user accounts, initially their home directories (which all live in a /home qtree in which there are per-uid quotas) get moved to an accesible-only-to-root location, from which they can be restored intact if the cancellation is reversed. Some months later they are "destroyed", at which time the old home directory is (rm -r)'d. One expects the per-uid usage reported by "quota report" (or the equivalent rquota rpc) to go to zero at this point. Occasionally it doesn't, because there were files with that uid not under the old home directory, which can (rather tediously) be found by a 'find' over the whole of /home.
I now have a case, for the first time ever, where the usage reported by "quota report" (etc) remains at 1376 KB and 896 inodes, and 'find' totally fails to find any responsible files. I can't be quite sure that these values would remain the same after "quota off" and "quota on" on the volume (this would be a rather disruptive experiment), but I strongly suspect so, because the usage value before the "rm -r" (in retrospect, by looking at snapshots of the tree removed, clearly too large be explained by it) was recomputed without change by a "quota off"/"quota on" a couple of months ago.
My feelings are that this strongly suggests a collection of inodes detached from the filing system directory tree, and that wafliron may be the appropriate response. Has anyone else had a comparable experience? Current ONTAP version is 6.3.2 but the filing system mangling (if that is indeed the problem) may have happened years ago, only to come to light now.
I have a case open with NetApp, but my contact there is trying to persuade me that the non-zero usage is due to the fact there are still files for the offending uid in snapshots... which goes against just about everything I (think I) know about NetApp filing systems.
Chris Thompson Email: cet1@cam.ac.uk
Hello,
I am in the process of testing performance with a Win2K machine running Hummingbird Maestro NFS client to a filer.
Does anyone have suggestions for the network settings to maximize throughput. Seems that something is off here and I am seeing pretty dismal numbers.
Thanks,
Joe