summaryrefslogtreecommitdiff
path: root/fs/ceph/caps.c
AgeCommit message (Collapse)Author
2009-12-23ceph: include transaction id in ceph_msg_header (protocol change)Sage Weil
Many (most?) message types include a transaction id. By including it in the fixed size header, we always have it available even when we are unable to allocate memory for the (larger, variable sized) message body. This will allow us to error out the appropriate request instead of (silently) dropping the reply. Signed-off-by: Sage Weil <sage@newdream.net>
2009-12-23ceph: do not touch_caps while iterating over caps listSage Weil
Avoid confusing iterate_session_caps(), flag the session while we are iterating so that __touch_cap does not rearrange items on the list. All other modifiers of session->s_caps do so under the protection of s_mutex. Signed-off-by: Sage Weil <sage@newdream.net>
2009-12-21ceph: hex dump corrupt server data to KERN_DEBUGSage Weil
Also, print fsid using standard format, NOT hex dump. Signed-off-by: Sage Weil <sage@newdream.net>
2009-12-03ceph: whitespace cleanupSage Weil
Signed-off-by: Sage Weil <sage@newdream.net>
2009-11-12ceph: fix page invalidation deadlockSage Weil
We occasionally want to make a best-effort attempt to invalidate cache pages without fear of blocking. If this fails, we fall back to an async invalidate in another thread. Use invalidate_mapping_pages instead of invalidate_inode_page2, as that will skip locked pages, and not deadlock. Signed-off-by: Sage Weil <sage@newdream.net>
2009-11-10ceph: remove recon_gen logicSage Weil
We don't get an explicit affirmative confirmation that our caps reconnect, nor do we necessarily want to pay that cost. So, take all this code out for now. Signed-off-by: Sage Weil <sage@newdream.net>
2009-11-09ceph: do not confuse stale and dead (unreconnected) capsSage Weil
We were using the cap_gen to track both stale caps (caps that timed out due to temporarily losing touch with the mds) and dead caps that did not reconnect after an MDS failure. Introduce a recon_gen counter to track reconnections to restarted MDSs and kill dead caps based on that instead. Rename gen to cap_gen while we're at it to make it more clear which is which. Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-27ceph: allocate and parse mount args before client instanceSage Weil
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-15ceph: move dirty caps code aroundSage Weil
Cleanup only. Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-15ceph: flush dirty caps via the cap_dirty listSage Weil
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-14ceph: move generic flushing code into helperSage Weil
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 Weil
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>