Project

General

Profile

Actions
Copy link

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.

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

Actions
Copy link
 #1

Updated by Sage Weil over 13 years ago

  • Estimated time set to 8:00 h
  • Source set to 3
Actions
Copy link
 #2

Updated by Sage Weil over 12 years ago

  • Target version set to 52
Actions
Copy link
 #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
Actions
Copy link
 #4

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
Actions
Copy link
 #5

Updated by Loïc Dachary over 9 years ago

  • Project changed from Ceph to CephFS
Actions
Copy link
 #6

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.

Actions
Copy link
 #7

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.

Actions
Copy link
 #8

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.

Actions
Copy link

Also available in: Atom PDF