Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs

Pull btrfs fixes from Chris Mason:
 "I've got a revert to fix a regression with btrfs device registration,
  and Filipe has part two of his fsync fix from last week"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Revert "Btrfs: device_list_add() should not update list when mounted"
  Btrfs: set inode's logged_trans/last_log_commit after ranged fsync
This commit is contained in:
Linus Torvalds 2014-09-19 13:10:53 -07:00
commit 46be7b73e8
3 changed files with 19 additions and 21 deletions

View File

@ -234,8 +234,17 @@ static inline int btrfs_inode_in_log(struct inode *inode, u64 generation)
BTRFS_I(inode)->last_sub_trans <=
BTRFS_I(inode)->last_log_commit &&
BTRFS_I(inode)->last_sub_trans <=
BTRFS_I(inode)->root->last_log_commit)
return 1;
BTRFS_I(inode)->root->last_log_commit) {
/*
* After a ranged fsync we might have left some extent maps
* (that fall outside the fsync's range). So return false
* here if the list isn't empty, to make sure btrfs_log_inode()
* will be called and process those extent maps.
*/
smp_mb();
if (list_empty(&BTRFS_I(inode)->extent_tree.modified_extents))
return 1;
}
return 0;
}

View File

@ -4093,18 +4093,8 @@ log_extents:
}
}
write_lock(&em_tree->lock);
/*
* If we're doing a ranged fsync and there are still modified extents
* in the list, we must run on the next fsync call as it might cover
* those extents (a full fsync or an fsync for other range).
*/
if (list_empty(&em_tree->modified_extents)) {
BTRFS_I(inode)->logged_trans = trans->transid;
BTRFS_I(inode)->last_log_commit =
BTRFS_I(inode)->last_sub_trans;
}
write_unlock(&em_tree->lock);
BTRFS_I(inode)->logged_trans = trans->transid;
BTRFS_I(inode)->last_log_commit = BTRFS_I(inode)->last_sub_trans;
out_unlock:
if (unlikely(err))
btrfs_put_logged_extents(&logged_list);

View File

@ -529,12 +529,12 @@ static noinline int device_list_add(const char *path,
*/
/*
* As of now don't allow update to btrfs_fs_device through
* the btrfs dev scan cli, after FS has been mounted.
* For now, we do allow update to btrfs_fs_device through the
* btrfs dev scan cli after FS has been mounted. We're still
* tracking a problem where systems fail mount by subvolume id
* when we reject replacement on a mounted FS.
*/
if (fs_devices->opened) {
return -EBUSY;
} else {
if (!fs_devices->opened && found_transid < device->generation) {
/*
* That is if the FS is _not_ mounted and if you
* are here, that means there is more than one
@ -542,8 +542,7 @@ static noinline int device_list_add(const char *path,
* with larger generation number or the last-in if
* generation are equal.
*/
if (found_transid < device->generation)
return -EEXIST;
return -EEXIST;
}
name = rcu_string_strdup(path, GFP_NOFS);