Talk:FAQ

From btrfs Wiki
(Difference between revisions)
Jump to: navigation, search
(crash guarantees of rename)
 
(Explain how sync fixes the lost content on rename problem)
Line 13: Line 13:
  
 
--[[User:Flickmontana|Flickmontana]] 02:17, 14 January 2011 (UTC)
 
--[[User:Flickmontana|Flickmontana]] 02:17, 14 January 2011 (UTC)
 +
 +
I've just read the linked thread, so I think I can explain. The short answer is that when you add the sync, the guarantee is that at your crash point, file contains either the old contents of file, or "content".
 +
 +
The longer answer follows:
 +
<pre>
 +
# Start a metadata operation to create file.tmp, and start a data operation to fill file.tmp with "content".
 +
echo "content" > file.tmp
 +
 +
# Wait for previous operations to complete. Outside shell, you could just use fsync( file_tmp_fd ) to wait for the data operation to complete.
 +
sync
 +
 +
# Wait for previous metadata operations on file.tmp to complete, then start a metadata operation to rename file.tmp to file.
 +
mv file.tmp file
 +
 +
# *crash*
 +
</pre>
 +
 +
Remember that you're building up two queues of operations, metadata and data. The sequence above creates the following metadata queue:
 +
 +
1. Create a file object, currently called "file.tmp".
 +
2. Rename "file.tmp" to "file", losing the old "file".
 +
 +
It also creates the following data queue:
 +
 +
1. In the file object created in metadata operation 1, store the data "content".
 +
 +
The data operation queue can't be processed until metadata operation 1 has created the file object, as it depends on the results of that operation.
 +
 +
Without the sync, these three operations give you three possible sequences to disk:
 +
 +
1. Metadata operation 1 completed
 +
2. Data operation 1 completed
 +
3. Metadata operation 2 completed.
 +
 +
or:
 +
 +
1. Data operation 1 completed
 +
2. Metadata operation 1 completed
 +
3. Metadata operation 2 completed.
 +
 +
or:
 +
 +
1. Metadata operation 1 completed
 +
2. Metadata operation 2 completed
 +
3. Data operation 1 completed.
 +
 +
If the crash happens just before the final operation completes, the first sequence results in file.tmp containing content, and file being unaltered. The second results in file.tmp being present, with data in it, and file being unaltered, while the third results in file being empty, and the data lost. With the sync, the third sequence is illegal; metadata operation 2 isn't even queued for btrfs to think about until metadata operation 1 and data operation 1 have completed. With the fsync, metadata operation 2 won't be queued until data operation 1 has completed, so again, the third option is impossible.
 +
 +
[[User:Farnz|Farnz]]

Revision as of 11:05, 14 January 2011

In the "What are the crash guarantees of rename?" section, what if we sync the file to the disk before renaming?

echo "content" > file.tmp

# make sure content is on disk
sync

mv file.tmp file

# *crash*

--Flickmontana 02:17, 14 January 2011 (UTC)

I've just read the linked thread, so I think I can explain. The short answer is that when you add the sync, the guarantee is that at your crash point, file contains either the old contents of file, or "content".

The longer answer follows:

# Start a metadata operation to create file.tmp, and start a data operation to fill file.tmp with "content".
echo "content" > file.tmp

# Wait for previous operations to complete. Outside shell, you could just use fsync( file_tmp_fd ) to wait for the data operation to complete.
sync

# Wait for previous metadata operations on file.tmp to complete, then start a metadata operation to rename file.tmp to file.
mv file.tmp file

# *crash*

Remember that you're building up two queues of operations, metadata and data. The sequence above creates the following metadata queue:

1. Create a file object, currently called "file.tmp".
2. Rename "file.tmp" to "file", losing the old "file".

It also creates the following data queue:

1. In the file object created in metadata operation 1, store the data "content".

The data operation queue can't be processed until metadata operation 1 has created the file object, as it depends on the results of that operation.

Without the sync, these three operations give you three possible sequences to disk:

1. Metadata operation 1 completed
2. Data operation 1 completed
3. Metadata operation 2 completed.

or:

1. Data operation 1 completed
2. Metadata operation 1 completed
3. Metadata operation 2 completed.

or:

1. Metadata operation 1 completed
2. Metadata operation 2 completed
3. Data operation 1 completed.

If the crash happens just before the final operation completes, the first sequence results in file.tmp containing content, and file being unaltered. The second results in file.tmp being present, with data in it, and file being unaltered, while the third results in file being empty, and the data lost. With the sync, the third sequence is illegal; metadata operation 2 isn't even queued for btrfs to think about until metadata operation 1 and data operation 1 have completed. With the fsync, metadata operation 2 won't be queued until data operation 1 has completed, so again, the third option is impossible.

Farnz

Personal tools