Description of problem: NFS mounts with '-o strictatime' fail -- mount.nfs rejects 'strictatime' as an incorrect option. Version-Release number of selected component (if applicable): nfs-utils-1.2.0-16.fc12 nfs-utils-1.2.0-5.fc11 How reproducible: 100% Steps to Reproduce: (Problem can be seen with localhost or remote server.) 1. service nfs start # if not already 2. exportfs -iv localhost:/var/tmp 3. mkdir -p /mnt/nfs 4. mount.nfs localhost:/var/tmp /mnt/nfs -v -o strictatime Actual results: mount.nfs: timeout set for Sat Oct 10 02:48:23 2009 mount.nfs: text-based options: 'strictatime,addr=127.0.0.1' mount.nfs: mount(2): Invalid argument mount.nfs: an incorrect mount option was specified Expected results: Something similar to the results when '-o strictatime' is not given: mount.nfs: timeout set for Sat Oct 10 02:51:09 2009 mount.nfs: text-based options: 'addr=127.0.0.1' localhost:/var/tmp on /mnt/nfs type nfs Additional info: The results above are with F11/F11 server/client. Results with F12/F12 are similar, but more verbose. Results with a remote server are the same. Remember that mount.nfs is very fussy about args/options order. To test the prerequisites and args/options order, try this; it should succeed: mount.nfs localhost:/var/tmp /mnt/nfs -v -o ro I used /var/tmp instead of /tmp in the examples to avoid complications if /tmp happens to be tmpfs . strictatime would not be necessary if someone would kindly nuke the relatime kludge/misfeature, and fix the brain-damaged apps that use it as a crutch. At best, relatime should be opt-in, not opt-out.
Not sure what you are refering to as the 'relatime kludge/misfeature'
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping