Feature #83
open
mds: rename over old files should flush data or revert to old contents?
Added by Sage Weil almost 14 years ago.
Updated almost 8 years ago.
Category:
Correctness/Safety
Description
write to foo.conf.tmp
close
rename foo.conf.tmp to foo.conf
<crash before flushing new file content>
foo.conf now 0 bytes. :(
- Estimated time set to 8:00 h
- Source set to 3
- Target version deleted (
52)
- Translation missing: en.field_position deleted (
211)
- Translation missing: en.field_position set to 838
- Translation missing: en.field_position deleted (
849)
- Translation missing: en.field_position set to 1
- Translation missing: en.field_position changed from 1 to 860
- Project changed from Ceph to CephFS
- Category set to Correctness/Safety
- Priority changed from Low to Normal
I don't suppose POSIX says anything about this...
I think I vote for requiring a flush before renaming over existing (non-zero-sized) files.
The original ticket is describing a real bug (that no longer exists), right? It's not clear to me that there's still a correctness issue in how we handle renames.
I think it does still exist?
We have an existing foo.conf, inode x
Write to foo.conf.tmp, inode y
rename foo.conf.tmp -> foo.conf
crash
We now have inode x in the stray directory, foo.conf pointing at inode y, but no RADOS objects backing up y.
In a local FS this isn't strictly safe either (without the syncing foo.conf.tmp first), but you're a lot more likely to be okay because most local FS implementations (either deliberately or just in practice) will flush those modifications in order. With our separate paths and writeback, we don't.
Also available in: Atom
PDF