summaryrefslogtreecommitdiff
path: root/fs/ceph/caps.c
AgeCommit message (Collapse)AuthorFilesLines
2009-10-27ceph: allocate and parse mount args before client instanceSage Weil1-2/+2
This simplifies much of the error handling during mount. It also means that we have the mount args before client creation, and we can initialize based on those options. Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-16ceph: move dirty caps code aroundSage Weil1-33/+37
Cleanup only. Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-16ceph: flush dirty caps via the cap_dirty listSage Weil1-23/+53
Previously we were flushing dirty caps by passing an extra flag when traversing the delayed caps list. Besides being a bit ugly, that can also miss caps that are dirty but didn't result in a cap requeue: notably, mark_caps_dirty(). Separate the flushing into a separate helper, and traverse the cap_dirty list. This also brings i_dirty_item in line with i_dirty_caps: we are on the list IFF caps != 0. We carry an inode ref IFF dirty_caps|flushing_caps != 0. Lose the unused return value from __ceph_mark_caps_dirty(). Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-15ceph: move generic flushing code into helperSage Weil1-22/+21
Both callers of __mark_caps_flushing() do the same work; move it into the helper. Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06ceph: capability managementSage Weil1-0/+2830
The Ceph metadata servers control client access to inode metadata and file data by issuing capabilities, granting clients permission to read and/or write both inode field and file data to OSDs (storage nodes). Each capability consists of a set of bits indicating which operations are allowed. If the client holds a *_SHARED cap, the client has a coherent value that can be safely read from the cached inode. In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client is allowed to change inode attributes (e.g., file size, mtime), note its dirty state in the ceph_cap, and asynchronously flush that metadata change to the MDS. In the event of a conflicting operation (perhaps by another client), the MDS will revoke the conflicting client capabilities. In order for a client to cache an inode, it must hold a capability with at least one MDS server. When inodes are released, release notifications are batched and periodically sent en masse to the MDS cluster to release server state. Signed-off-by: Sage Weil <sage@newdream.net>