Similarities
- Both DFS and AFS use a volume location server to present many spatially-disparate server volumes in a single tree
- Both DFS and AFS support strongly encrypted authentication methods
Benefits of DFS compared to AFS
- DFS has full incremental snapshot capability instead of AFS’s single backup volumes
- DFS client support is built in and supported by Microsoft on NT-based Windows; the AFS client must be installed and supported separately
- DFS management tools are built in to Microsoft server operating systems
- DFS-compatible SAN appliances are readily available
- DFS has read-write (multi-master) replication and failover; AFS only has read-only replication (though DCE DFS, a derivative of AFS, has read-write replication)
- DFS volumes can be manually parsed and checked using standard filesystem check tools; AFS uses its own file storage mechanisms (namei and inode) that require the AFS salvager to recovery and verify, and in which files and directories appear as nonsense to someone attempting data recovery
Drawbacks compared to AFS
- AFS supports Unix-style symbolic links and same-directory hard links
- AFS has a unified cross-domain namespace (/afs) and standardized AFSDB record to locate servers in other cells
- AFS encrypts transmitted file data using ‘fcrypt’, a variant of DES
- AFS employs a local file cache on the client machine; DFS does not, making it infeasible to run applications or directly manipulate data files that are stored on a network volume
- AFS employs UNIX filesystem semantics with few exceptions (@sys, cross-directory hard links and device files unsupported); DFS employs Windows filesystem semantics, so UNIX applications cannot create case-differentiated file names, create files corresponding to MS-DOS devices (con, aux, prn, lpt[1-9], com[1-9], nul), or create files with reserved characters in the name (such as a colon character)
- AFS users can create and manage their own ACL groups; DFS ACL groups can only be created by domain administrators