On 11/20/98 09:45:21 you wrote:
Rick,
We have run into a couple of significant issues with CIFS that may, or may not, be relevant.
First issue is:
Well, it turns out that there is some "feature" in NT that causes IIS to hang if oplocks are on.
To me, this is an issue with IIS. If you use IIS, you'll get this same problem when talking via CIFS to another NT box. The answer is to not use IIS (or NT entirely), or, as you point out, turn off oplocks.
The second issue is a hardcoded limit in the filer that does not allow for more then slightly more then 65K of directories in one directory tree. Most folks wouldn't run into this, but we create an NT folder for every user who uses our site to build their own web pages. This limit is not documented (there is a limit of approx. 300,000 file sin one directory and a maxfiles limit that is dependent on number/capacity of disk drives that are documented).
This does bother me. I don't know when the limit appeared, as it doesn't seem to be a part of the WAFL design, and slipping it in through a "backdoor" without mentioning it is disturbing. As you mentioned, there is a limit on the number of files, or actually directory entries, in one directory, which was set as a matter of performance; however, there is a maxdirsize parameter you can set to increase it. Directories should naturally be treated the same way, so if you're correct that some other limit has been added (maybe it was always there and I just didn't know), it would be nice if someone from Netapp could address why this limit exists and if/when it will be lifted and/or made user-configurable.
Mind you, if you tried to put 65K directories in your NT or UNIX server, you will run into a severe performance degredation. You really should look into setting them in deeper subdirectories. This appears to be another reason NOT to use IIS....
Bruce
On 11/20/98 09:45:21 you wrote:
Rick,
We have run into a couple of significant issues with CIFS that may, or may not, be relevant.
First issue is:
Well, it turns out that there is some "feature" in NT that causes IIS to hang if oplocks are on.
To me, this is an issue with IIS. If you use IIS, you'll get this same problem when talking via CIFS to another NT box. The answer is to not use IIS (or NT entirely), or, as you point out, turn off oplocks.
The second issue is a hardcoded limit in the filer that does not allow for more then slightly more then 65K of directories in one directory tree. Most folks wouldn't run into this, but we create an NT folder for every user who uses our site to build their own web pages. This limit is not documented (there is a limit of approx. 300,000 file sin one directory and a maxfiles limit that is dependent on number/capacity of disk drives that are documented).
This does bother me. I don't know when the limit appeared, as it doesn't seem to be a part of the WAFL design,
It is a part of WAFL:
tooting$ cd ~/p4/ontap/main/prod/common/wafl tooting$ egrep link inode.h ushort nlink; /* Count of hard links. */
That's a 2-byte unsigned quantity, hence a hard limit of 65535 hard links to a file of any sort...
...including a directory.
Every directory has at least two links to it - the link in its parent directory with the directory's name, and the "." link to itself. In addition, each subdirectory of the directory adds *another* link - the ".." link.
Many UNIX file systems impose the same sort of limit, although it may be a limit of ~32767 subdirectories:
tooting$ uname -sr SunOS 5.6 tooting$ egrep nlink /usr/include/sys/fs/ufs_inode.h short ic_nlink; /* 2: number of links to file */
satan$ uname -sr OSF1 V4.0 satan$ egrep nlink /usr/include/ufs/inode.h #define i_nlink i_din.di_nlink * di_nlink incore lock satan$ egrep nlink /usr/include/ufs/dinode.h short di_nlink; /* 2: number of links to file */
(both BSD-derived file systems).
Directories should naturally be treated the same way, so if you're correct that some other limit has been added (maybe it was always there and I just didn't know),
Yup.
it would be nice if someone from Netapp could address why this limit exists
See above.
and if/when it will be lifted
When we redo WAFL to the point of changing the inode format (or steal one of the few spare bits left in the inode...).
-
guy＠netapp.com -
sirbruce＠ix.netcom.com