Solaris PC NetLink Performance Improvements
Several product changes have resulted in better performance and scaling. In addition to changes to Solaris PC NetLink, new enhancements to the Solaris operating environment have equally contributed to better server performance. Customers upgrading from older versions of Solaris PC NetLink should also upgrade to the latest version of Solaris.
Windows 95/98/ME Clients Versus Windows NT 4.0 Clients
Windows 95/98/ME clients use a different level of the CIFS protocol to access Solaris PC NetLink than Windows NT workstation clients. When the client operating system is requested to access a file for an application, the local operating system running on the client must translate the file request into network protocols that are sent to the server. In Windows 95/98/ME systems, the requests are significantly different from those made by Windows NT 4.0 workstation clients. In previous versions of Solaris PC NetLink software, a limitation with the Windows 95/98/ME CIFS protocol stack forced multiple ~10ms waits to occur during the file write operations. When moving large files, these delays could add up and cause slower performance. This unnecessary wait time is now eliminated.
Individual Windows 95/98/ME clients now experience up to double the performance with PC NetLink 2.0 software than they experienced using previous versions of Solaris PC NetLink software. A patch is available for Solaris PC NetLink 1.2 that incorporates this improvement.
This change only affects Windows 95/98/ME client performance and is not seen in Windows NT 4.0 workstation clients because the protocol used there does not cause the same delay. While individual performance for these clients may improve, the overall server performance for hundreds or thousands of users is unaffected by this change.
Access Control List Support
Support for Windows NT 4.0 ACLs has always been an important feature of the Solaris PC NetLink software. ACLs on Solaris software are compliant with the POSIX 1003.6 specification. They have been implemented for both the UNIXTM file system (UFS), as well as for NFS versions 2 and 3. Unfortunately, there is not a one-for-one mapping of Windows NT style ACLs with the POSIX standard. For this reason, ACLs were initially supported by a separate database that the Solaris PC NetLink 1.0, 1.1, and 1.2 software maintains in parallel with the normal file data access. This ACL database is stored in what is called a binary large object (BLOB) database.
By default, for every directory created by a PC client application through the Solaris PC NetLink software, an ACL entry is saved in the BLOB database. File ACLs are not created by default, but are created when the PC client explicitly requests to do so. While supporting ACLs through this mechanism works well, performance can suffer for applications that conduct numerous directory operations or use file ACLs heavily. Most directory operations require access to the database file, usually located in /var/opt/lanman/datafiles/acl. The ACL database file access may originate from the file read cache located in physical memory. On a busy server, this file read cache may be displaced from physical memory by other applications, which can potentially reduce throughput.
Another problem associated with supporting a parallel database is that the ACLs are not accessible by traditional UNIX backup applications such as tar or dump. When a Solaris PC NetLink created file is accessed by a traditional UNIX based application such as tar, only the file data and attributes in the UFS file system are saved. The tar program has no knowledge of how to access and save the Windows NT style ACL.
Solaris PC NetLink 1.2 software introduced a software module that allows Legato Systems, Inc. backup software, and other backup programs, to save ACLs with the files. While this helped solve the problem of saving the ACLs with the file, it was still limited to just a few backup programs.
Solaris PC NetLink 2.0 software supports Windows NT style ACLs differently. Instead of using a separate database to store the ACLs, it saves the ACL data in a hidden UNIX dot (.) file located in the referring directory. While this does not completely eliminate overhead for storing ACLs, it does limit the impact of ACL support on a full server.
If a significant number of files are being accessed in one directory, the Solaris file read cache will keep the ACL dot (.) file in memory, making it easily accessible. These files are typically small compared to the previously used BLOB file and are distributed throughout the file system.
Previously, a hyperactive ACL BLOB file could potentially cause all users to suffer a performance degradation. With the new architecture, any potential performance degradation is limited to users using the same active disk subsystem.
In addition to performance issues, the elimination of the ACL BLOB file removed the susceptibility to loss of all ACL information if the database file became corrupted.