Hi Chris,
I had assumed that atime was stored in the directory entry itself (which would have a pointer to an inode that was a simple list of data blocks), which would have explained the behaviour reported by Jeff Burton in his post. TR2002 ("Filesystem Design for an NFS file server appliance") doesn't specify anything about directory entry contents. The testing you show below seems to nails it, but I will go and have a play when I get a moment just fo see it for myself.
Now, even if the directory entry doesn't contain the attributes but is simply a name with a pointer to an inode that contains the file attributes, a change in the file attributes will still require the pointer in the directory entry to be changed to point to the new inode. (WAFL NEVER makes changes to existing inodes, it always writes new ones). Therefore the block containing that directory entry will still need to be rewritten (you seem to imply that it won't).
The directory entry does not need to be changed because it contains an inode number (index into the inode table). This is not a pointer to a specific disk block. It is an offset from the beginning of the inode file to a particular inode.
The inode table is simply a sequential list of inodes, i.e., an array. When an inode is modified, you are correct that wafl must replace the disk block that contains the old inode with a new disk block with the updated inode. But this is a bookkeeping detail. Logically, the inode is updated in place. Therefore its offset (inode number) does not change, so the directory entry does not change either.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support