Ceph » CephFS

What if another file is renamed in the other direction? Do a partial commit first? Tricky.

I think this is going to be much ahrder than I originally imagined. For example:

- mv /a/foo /b/foo
- mv /b/bar /a/bar

Which do we write first? We could:
- force dir /b flush in between the renames?
- flush them later, but in multiple stages.... e.g. flush /b/foo, /a/*, /b/bar removal

I haven't gotten too far into it yet, but my current line of attack is to see how feasible it is to place "holds" on dentries (linked to their parent CDir) which requires that that dentry not be written to disk until another dentry has been written. Then, when a CDir commit occurs, if any dentries have holds, request the blocking dentry get written to disk. Then attempt to write the whole CDir, but if you can't (ie, you have a hold) just commit the blocking dentry. So:
1) mv a/foo -> b/foo
2) a/foo (null dentry, right?) gets hold linked to b/foo
3) mv b/bar -> a/bar
4) b/bar gets hold linked to a/bar
5) commit a comes in
6) a asks b to commit "foo"
7) b commits just "foo" because there is a hold on "bar"
8) a commits
9) commit b comes in
10) b asks a to commit "bar"
11) a commits full dir
12) b commits

There are some obvious options for optimization here, but I think that if this is feasible to get working then any optimizations will be simple add-ons. I haven't dug into the commit code much more than I have previously but I think this should work?

Err, I guess actually that should read:
8) a commits
9) hold on b/bar gets removed
10) commit b comes in
11) b commits

Or alternatively, depending on data structures in place:
8) a commits
9) commit b comes in
10) b asks a to commit "bar"
11) a says "already committed that dentry at that version!"
12) b commits