summaryrefslogtreecommitdiffstats
path: root/xlators/meta
diff options
context:
space:
mode:
authorKrutika Dhananjay <kdhananj@redhat.com>2018-03-29 17:21:32 +0530
committerPranith Kumar Karampuri <pkarampu@redhat.com>2018-06-13 09:57:14 +0000
commitc30aca6a5b25223e36b4ea812af544e348952138 (patch)
treeec851479d54cb892e8e76d8f811a42bca2924630 /xlators/meta
parent5702ff3012f6b97f6b497b5c2e89e8700caf8bc1 (diff)
features/shard: Introducing ".shard/.remove_me" for atomic shard deletion (part 1)
PROBLEM: Shards are deleted synchronously when a sharded file is unlinked or when a sharded file participating as the dst in a rename() is going to be replaced. The problem with this approach is it makes the operation really slow, sometimes causing the application to time out, especially with large files. SOLUTION: To make this operation atomic, we introduce a ".remove_me" directory. Now renames and unlinks will simply involve two steps: 1. creating an empty file under .remove_me named after the gfid of the file participating in unlink/rename 2. carrying out the actual rename/unlink A synctask is created (more on that in part 2) to scan this directory after every unlink/rename operation (or upon a volume mount) and clean up all shards associated with it. All of this happens in the background. The task takes care to delete the shards associated with the gfid in .remove_me only if this gfid doesn't exist in backend, ensuring that the file was successfully renamed/unlinked and its shards can be discarded now safely. Change-Id: Ia1d238b721a3e99f951a73abbe199e4245f51a3a updates: bz#1568521 Signed-off-by: Krutika Dhananjay <kdhananj@redhat.com>
Diffstat (limited to 'xlators/meta')
0 files changed, 0 insertions, 0 deletions