Bruce Sterling Woodcock wrote:

From: Joan Pearson jpearson@netapp.com

...

Yes, while a directory is being converted, all access to it should be locked out. Perhaps the nfs client was using information it had already cached before the conversion.

Yeah, but doesn't the cache check something on the directory before it makes assumptions? Access or modify time?

Maybe the filer isn't updating that at the start of the conversion process. I dunno. There's gotta be a way to defeat the client cacheing other than mounting "noac".

This was all "first contact" stuff, from both a freshly rebooted filer and client. No caching as far as I understand it was involved. In our debugging, we tried the "noac" option; it didn't work (for obvious reasons looking back on it now).

The first contact initiates the conversion; unfortunately for us, it was the dirents() from the `rm -rf` returning an incomplete directory listing.

Joan, the call was 83902.

On Wed, 16 Feb 2000, Hal Siegel wrote:

This conversion took close to a day and a half on a 630 full of hundreds of thousands of files of gzipped archive data.

Interesting. I interpreted the docs as saying a single directory with 100,000 files took 9 minutes. I never expected a directory with 20-30 files to be converted in anything more than a negligible time. My expectations were just out of line with the behaviour of the filer.

NetApp folks, perhaps this could be expounded upon in future docs with more warnings and other examples.

Note that you can monitor the conversion taking place by watching sysstat - there's a steady 3-400 disk reads per second going on while the conversion is being done.

Looking at our MRTG data a few days later, I figured that out. Doh!

Eyal Traitel wrote:

Can one of you explain the need for this anyway ?

It's really only a concern in a mixed CIFS/NFS environment, which we are heavily. The docs can explain the wafl ucode options much better than I can. But, one problem with not having the unicode information in the directory structure is this, which we ran into all the time:

o create a directory via an NFS client o do not access this directory from a CIFS client o create a snapshot o try to access this directory via a CIFS client via the snapshot

You will get "permission denied." The CIFS access tries to create the unicode information in the directory upon creation or access, but, since it's in a read-only snapshot, it can't. The wafl ucode options allow you to create directories with the unicode information already there, even if created via an NFS client, or to convert the directories upon any access, NFS or CIFS. It is the latter case that takes a non-trivial amount of time, enough to impact normal behavior.

Until next time...

The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---