DocFileAttributes

File Attribute Handling

Currently SLASH2 has two ways of updating attributes:

• the client can issue a SETATTR RPC to the MDS.
• the I/O server can issue a CRC_UPDATE RPC, piggybacking st_size and st_mtime.

To avoid these two RPCs crossing path with each other, we have a "utimes(2) generation" ("utimegen") mechanism so that an attribute update is only allowed by the CRC_UPDATE path if it has the right utimegen. This generation number is stored in the ZFS layer (zp_s2utimgen) and transmitted in the srt_stat sst_utimgen field and is bumped each time the st_mtime is bumped; utimegen only applies to mtime.

Using a generation number means that the CRC_UPDATE path has to compete to get the right to update the attributes. Instead, we should really update attributes based on when the corresponding operation (chmod(2), write(2), etc.) happened on the client. Because utimegen only applies to mtime, the CRC_UPDATE path may only ever increases the file size, which could be a problem as well. Imagine that a client writes some data to increase the file size and then decides to truncate the file size. The final file size could be incorrect.

Note: this scheme only applies when there is at least one writer and one reader of the file. If the file is not being changed, obviously the attributes will not become stale. If there is one thread and he is performing writes, he locally caches his activity so he has an accurate st_size.

Note in this situation, st_blocks is difficult to track.

If multiple writers are in play (or one writer and at least one reader), all clients downgraded to direct I/O (DIO) mode, and the remarks in this document apply. In this situation, the ION is solely knowledgeable of the file size in regard to the bmap seeing write activity.

Another issue with the current mechanism is that the most recent attributes of a file can be at either MDS or IOS. When the fchm (file cache entry) of a client needs to be refreshed, where does it get attributes from? The most recent attributes might still be en route to MDS from IOS.

We could make the current scheme work by adding tricks here and there. But to make things robust, we need a simpler way. We will let client be the only one that can update the attributes. It should work regardless of network delays and service outage.