linux.git/fs/btrfs/ordered-data.h, branch v4.0

Btrfs: collect only the necessary ordered extents on ranged fsync

2014-11-21T19:59:56+00:00

Instead of collecting all ordered extents from the inode's ordered tree
and then wait for all of them to complete, just collect the ones that
overlap the fsync range.

Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason

Btrfs: make sure logged extents complete in the current transaction V3

2014-11-21T19:58:32+00:00

Liu Bo pointed out that my previous fix would lose the generation update in the
scenario I described.  It is actually much worse than that, we could lose the
entire extent if we lose power right after the transaction commits.  Consider
the following

write extent 0-4k
log extent in log tree
commit transaction
	< power fail happens here
ordered extent completes

We would lose the 0-4k extent because it hasn't updated the actual fs tree, and
the transaction commit will reset the log so it isn't replayed.  If we lose
power before the transaction commit we are save, otherwise we are not.

Fix this by keeping track of all extents we logged in this transaction.  Then
when we go to commit the transaction make sure we wait for all of those ordered
extents to complete before proceeding.  This will make sure that if we lose
power after the transaction commit we still have our data.  This also fixes the
problem of the improperly updated extent generation.  Thanks,

cc: stable@vger.kernel.org
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

btrfs: disable strict file flushes for renames and truncates

2014-08-15T14:43:42+00:00

Truncates and renames are often used to replace old versions of a file
with new versions.  Applications often expect this to be an atomic
replacement, even if they haven't done anything to make sure the new
version is fully on disk.

Btrfs has strict flushing in place to make sure that renaming over an
old file with a new file will fully flush out the new file before
allowing the transaction commit with the rename to complete.

This ordering means the commit code needs to be able to lock file pages,
and there are a few paths in the filesystem where we will try to end a
transaction with the page lock held.  It's rare, but these things can
deadlock.

This patch removes the ordered flushes and switches to a best effort
filemap_flush like ext4 uses. It's not perfect, but it should fix the
deadlocks.

Signed-off-by: Chris Mason

btrfs: Cleanup the "_struct" suffix in btrfs_workequeue

2014-03-10T19:17:16+00:00

Since the "_struct" suffix is mainly used for distinguish the differnt
btrfs_work between the original and the newly created one,
there is no need using the suffix since all btrfs_workers are changed
into btrfs_workqueue.

Also this patch fixed some codes whose code style is changed due to the
too long "_struct" suffix.

Signed-off-by: Qu Wenruo 
Tested-by: David Sterba 
Signed-off-by: Josef Bacik

btrfs: Replace fs_info->endio_* workqueue with btrfs_workqueue.

2014-03-10T19:17:08+00:00

Replace the fs_info->endio_* workqueues with the newly created
btrfs_workqueue.

Signed-off-by: Qu Wenruo 
Tested-by: David Sterba 
Signed-off-by: Josef Bacik

btrfs: Replace fs_info->flush_workers with btrfs_workqueue.

2014-03-10T19:17:07+00:00

Replace the fs_info->submit_workers with the newly created
btrfs_workqueue.

Signed-off-by: Qu Wenruo 
Tested-by: David Sterba 
Signed-off-by: Josef Bacik

Btrfs: don't mix the ordered extents of all files together during logging the inodes

2014-03-10T19:15:36+00:00

There was a problem in the old code:
If we failed to log the csum, we would free all the ordered extents in the log list
including those ordered extents that were logged successfully, it would make the
log committer not to wait for the completion of the ordered extents.

This patch doesn't insert the ordered extents that is about to be logged into
a global list, instead, we insert them into a local list. If we log the ordered
extents successfully, we splice them with the global list, or we will throw them
away, then do full sync. It can also reduce the lock contention and the traverse
time of list.

Signed-off-by: Miao Xie 
Signed-off-by: Josef Bacik

Btrfs: don't wait for the completion of all the ordered extents

2013-11-12T03:13:44+00:00

It is very likely that there are lots of ordered extents in the filesytem,
if we wait for the completion of all of them when we want to reclaim some
space for the metadata space reservation, we would be blocked for a long
time. The performance would drop down suddenly for a long time.

Signed-off-by: Miao Xie 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: return an error from btrfs_wait_ordered_range

2013-11-12T03:07:35+00:00

I noticed that if the free space cache has an error writing out it's data it
won't actually error out, it will just carry on.  This is because it doesn't
check the return value of btrfs_wait_ordered_range, which didn't actually return
anything.  So fix this in order to keep us from making free space cache look
valid when it really isnt.  Thanks,

Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: kill delay_iput arg to the wait_ordered functions

2013-09-21T15:05:27+00:00

This is a left over of how we used to wait for ordered extents, which was to
grab the inode and then run filemap flush on it.  However if we have an ordered
extent then we already are holding a ref on the inode, and we just use
btrfs_start_ordered_extent anyway, so there is no reason to have an extra ref on
the inode to start work on the ordered extent.  Thanks,

Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason