Feature #83
openmds: rename over old files should flush data or revert to old contents?
0%
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. :(
Updated by Sage Weil over 13 years ago
- Estimated time set to 8:00 h
- Source set to 3
Updated by Sage Weil over 12 years ago
- Target version deleted (
52) - Translation missing: en.field_position deleted (
211) - Translation missing: en.field_position set to 838
Updated by Sage Weil over 12 years ago
- 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
Updated by Greg Farnum almost 8 years ago
- 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.
Updated by John Spray almost 8 years ago
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.
Updated by Greg Farnum almost 8 years ago
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.