du(1) and df(1) support

Support for st_blocks in struct stat has been implemented to support utilities such as du(1) and statvfs(2) now more usefully reflects a mount_slash client’s preferred I/O system for supporting utilities such as df(1).

The statvfs(2) implementation simply tracks each I/O node’s backend file system through updates sent to the MDS whenever convenient. Then, when a mount_slash client issues a STATFS request to the MDS to get file system stats such as free blocks, the MDS returns the statvfs(2) pertaining to this client’s preferred I/O system.

Future improvements: persistently store the statvfs data somewhere in the MDS.

The st_blocks implementation is a bit more involved but works in an somewhat analogous fashion: whenever a sliod sends CRC or REPLWK updates, which happens after I/O has been issued from the client or a replica has been made/updated, the st_blocks for the file involved is sent along to the MDS. This value is tracked in the inode for each I/O system replica and, in the case of CRC updates, the delta from the previous value in the inode to the new value for this I/O system is applied to the file’s st_blocks.

Specifically, st_blocks in SLASH2 means the number of 512-byte blocks in use by a file across all non-replicated regions of data, wherever these regions may reside. Replicas update only their per-IOS count of blocks and not the aggregate st_blocks whereas WRITE updates affect both the per-IOS count as well as the aggregate st_blocks value returned to mount_slash clients.