A bit about DOS modes / attributes.
DOS modes are visible in Windows if you right-click on a file or folder and hit 'properties'. They consist of 'Read-only, Hidden, System, and Archive'. As is implied in their name, these attributes are from the good old days of DOS. Samba has two different ways of dealing with them. By default and when not configured as an AD domain controller (when an AD DC samba will automatically enable 'store DOS attributes') samba uses the "map" parameters mentioned in the smb.conf manpage. The "map*" parameters work by manipulating the unix file permissions in the following ways:
dos readonly is represented in unix by removing everyone's write bit
dos archive is represented in unix by the user's execute bit
dos system is represented in unix by the group's execute bit
dos hidden is represented in unix by the other's execute bit
The above operations are carried out through chmod. Unfortunately, this has a tendency to mess up ZFS access control lists (ACLs). Since FreeBSD 9.2.1.6 the zfs aclmode is set to "restricted" on CIFS shares with ACL type set to "windows". The "restricted" aclmode prevents people from nuking their ACEs through a drive-by chmod. It also prevents the "map *" parameters from working. Simply put, the "map *" parameters are a no-go if you're using windows ACLs.
Alternatively, samba can store this information in EAs and SECDESCs. This is the way I believe that samba development is headed. Comments in the samba source regarding the "map *" parameters say things like
I'd like to see the following options go away and always use EAs and SECDESCs
Which makes sense because EAs and SECDESCs are able to store much more information than just these DOS modes. For instance, samba also stores create time in the DOSATTRIB EA. Extended attributes are necessary for the vfs_streams_xattr module, which provides compatibility with NTFS alternate datastreams, to work (user.DosStream). They may also be necessary in order for the upcoming vfs_fruit module (which may fix a lot of problems that Mac users have) to work properly.
Unfortunately, extended attributes are sometimes treated like second class citizens. XATTR operations appear to be quite slow on FreeBSD 9.x. Every time that you open a directory, samba will retrieve the user.DOSATTRIB EA of every file and folder in that directory. This results in very slow uncached browsing via Windows explorer.
Which means that if you have slow browsing performance you have the following options to mitigate it:
1) Add ARC or L2ARC. Standard advice applies here. It is best to max out RAM before considering L2ARC. Adding L2ARC on a system with 8GB RAM is a bad idea.
2) As mentioned in this thread disable "ea support" and "store dos attributes". Note that the DOS modes mentioned above will cease working, which may cause strange behaviour and prevent backup software from functioning properly. Programs, embedded devices, and network scanners / multi-function units may attempt to utilize the archive bit and fail unpredictably. Additionally, it may break some functionality for Mac users.
3) Run a cronjob to cache the extended attributes. An example of such a cronjob would be running the following command
Code:
find /mnt/Tank/Media/ -exec getextattr -x -q user DOSATTRIB {} \;
Note that this command assumes that you have enough ARC / L2ARC to keep the EA cached. It's hard to gauge how much is needed. I've seen between 8KB -18KB per file. If you scale this to 500,000 files, then you're looking at about 3.7GiB- 8.35GiB of
metadata. Since by default 25% of the ARC is dedicated to metadata, you're looking at a minimum arc size of 15-34GB to keep this cached.
(3) is theoretical. I also don't know how frequently you need to run it (since it is a rather intensive process, the less the better). If you're having this problem and feel like being a guinea pig, test it and report back your findings. :)
Edit: my experience with (3) is that it works okay for a few days to a week, but then the data gets flushed from ARC. Not a good solution.
