Project

General

Profile

Feature #83

mds: rename over old files should flush data or revert to old contents?

Added by Sage Weil over 12 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Correctness/Safety
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Reviewed:
Affected Versions:
Component(FS):
Labels (FS):
Pull request ID:

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. :(

History

#1 Updated by Sage Weil about 12 years ago

  • Estimated time set to 8.00 h
  • Source set to 3

#2 Updated by Sage Weil over 11 years ago

  • Target version set to 52

#3 Updated by Sage Weil over 11 years ago

  • Target version deleted (52)
  • translation missing: en.field_position deleted (211)
  • translation missing: en.field_position set to 838

#4 Updated by Sage Weil over 11 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

#5 Updated by Loïc Dachary over 8 years ago

  • Project changed from Ceph to CephFS

#6 Updated by Greg Farnum over 6 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.

#7 Updated by John Spray over 6 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.

#8 Updated by Greg Farnum over 6 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.

Also available in: Atom PDF