>> So, when I look at StoreData_RXStyle, I am not able to convince myself >> that the actual file data is fsync()'d ... unless fsync() is actually >> called on the client (and from what I see, fsync() IS passed from the >> client to the server). I can believe there is some other fsync()s in >> there, certainly, but I don't think it's doing the bulk data (but hey, >> I've been wrong before when it comes to AFS program flow). > >Huh? There's no RPC for that. And no, I don't think file data is synced, >but metadata is, which is consistent with the behavior of many other >filesystems.
There's no specific RPC for an fsync operation, true. Buuuttt ... Fsync operations at the vnode level end up calling afs_fsync(). afs_fsync() calls afs_StoreAll_Segments() with the third argument of AFS_SYNC. afs_StoreAllSegments() sets the flag AFS_FSYNC in Instatus.Mask when the third argument is AFS_SYNC. InStatus gets transmitted to the fileserver as part of the StoreData RPC. If AFS_FSYNC is seen by the StoreData RPC function on the fileserver, FDH_SYNC is called after the data is written to disk. Assuming IH_DELAY_SYNC is not set on the IHandle (Which I believe it is not in this case), FDH_SYNC() invokes OS_SYNC(), which is defined as fsync(). Given all that, I am reasonably confident that when a user calls fsync() on an AFS file, it is fsync()'d on the fileserver. At least there seems to be a large pile of code that tries to make that happen. --Ken _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
