Appendix D: Supported Platforms and Servers

D.1 Supported Platforms

SGI/IRIX:

No known problems.

Solaris:

No known problems.

HP-UX:

No known problems.

SunOS:

Sharity does not work on all versions of SunOS. There are versions where the mount() system call fails for no apparent reason.

Apple MacOS X (Server):

Carbon applications (e.g. Finder) don't list all files in directories containing inaccessible files.

Linux:

Write performance is less than it could be due to the very simple NFS client implementation in the 2.0 kernel. 2.2 kernels have much better performance, but the new NFS code is still somewhat buggy (at least in the early 2.2 releases).

FreeBSD:

No known problems.

NetBSD:

No known problems.

OpenBSD:

No known problems.

BSDI:

No known problems.

OSF/1 (DEC Unix):

No known problems.

AIX:

Works well, except on AIX 3.x, where the performance is too low by an order of magnitude due to UDP buffer problems.

NEXTSTEP, Openstep/Mach:

Sharity has been developed on this platform. Nevertheless, there are bugs in the kernel's NFS implementation which may cause the machine to hang.

Unixware:

Not currently tested.

General Notes:
For the transfer of big files, Sharity should be roughly as fast as the network allows, if you have a reasonably fast CPU (not with a 486). If it is notably slower, your operating system may not be using overlapped writes for NFS. On some systems, the number of parallel writes (number of biods) can be configured. Don't make the number too big to avoid buffer overflows.

If the performance is too low by an order of magnitude, you probably have a driver/hardware problem on your network, or your server is much too slow and loses network data packets. If the server is too slow, throughput can be dramatically improved by slowing down the client!

D.2 Supported CIFS Servers

Windows NT (3.51, 4.0 + any SP):

Is the best tested server platform. There are no known problems, except that file sizes may be listed incorrectly if the server is under high load. This does not affect reads and writes and should therefore be harmless. Sharity has a workaround for this bug which works almost always.

Windows 2000 (Pro):

This server is essentially the same code as Windows NT. All comments for NT apply accordingly.

Samba:

No known problems except a possible performance bug: Samba may trigger the fflush() performance bug on Linux which can make writes to large files extremely slow. If you suffer from this bug, read Samba's documentation for suggestions on workarounds and patches. Seems to be fixed with newer Linux kernels (the 2.2 series).

It looks as if Samba did not send breaks of opportunistic locks as required by the specification. OPLOCK support is therefor disabled by default. This may change with newer releases of Samba.

Windows 95/98:

Windows 9X has obviously not been designed as a server platform. It uses very small transfer buffer sizes and allows for little overlap of requests. These features combined with the long average response time for write requests result in bad write performance. Furthermore Windows 9X does not allow files open for write to be write protected. If this is requested by the client (Unix does allow it), the file is silently un-writeprotected. Windows 9X does not allow setting the modification date of a file. Any attempt to do so will result in an error. Windows 9X also has the "wrong file size bug" described in the NT section, but the workaround does not work as well as for NT because Windows 9X does not support opportunistic locks.

Windows ME:

This server is essentially the same as Windows 98. All comments for Windows 98 apply accordingly.

Windows for Workgroups:

It has been reported that Sharity works with Windows for Workgroups 3.11 servers. There has been no intensive testing, though, so enjoy with care.

OS/2:

Sharity works (more or less) with OS/2, but it does not pass the test suites. A lot more work would be required to fix these problems.

FacetWin:

This version of Sharity is interoperable with FacetWin. However, no reliability tests have been performed and there are known problems in setting file attributes.

AppleShare IP:

This version of Sharity is interoperable with AppleShare IP 6.2 (and probably other versions). However, AppleShare IP is only a very basic implementation of the CIFS protocol. Sharity does not pass the fstorture test with AppleShare IP because the server can't rename write-protected files. AppleShare IP also seems to run out of file handles under the load of fstorture.