At 04/01/2017 01:26 AM, David Sterba wrote:
On Fri, Mar 31, 2017 at 10:03:28AM +0800, Qu Wenruo wrote:
At 03/30/2017 06:31 PM, David Sterba wrote:
On Thu, Mar 30, 2017 at 09:03:21AM +0800, Qu Wenruo wrote:
+static int lock_full_stripe(struct btrfs_fs_info *fs_info, u64 bytenr)
+{
+
On Fri, Mar 31, 2017 at 10:03:28AM +0800, Qu Wenruo wrote:
>
>
> At 03/30/2017 06:31 PM, David Sterba wrote:
> > On Thu, Mar 30, 2017 at 09:03:21AM +0800, Qu Wenruo wrote:
> +static int lock_full_stripe(struct btrfs_fs_info *fs_info, u64 bytenr)
> +{
> +struct
At 03/30/2017 06:31 PM, David Sterba wrote:
On Thu, Mar 30, 2017 at 09:03:21AM +0800, Qu Wenruo wrote:
+static int lock_full_stripe(struct btrfs_fs_info *fs_info, u64 bytenr)
+{
+ struct btrfs_block_group_cache *bg_cache;
+ struct btrfs_full_stripe_locks_tree *locks_root;
+
On Thu, Mar 30, 2017 at 09:03:21AM +0800, Qu Wenruo wrote:
> >> +static int lock_full_stripe(struct btrfs_fs_info *fs_info, u64 bytenr)
> >> +{
> >> + struct btrfs_block_group_cache *bg_cache;
> >> + struct btrfs_full_stripe_locks_tree *locks_root;
> >> + struct full_stripe_lock *existing;
> >>
At 03/30/2017 08:34 AM, Liu Bo wrote:
On Wed, Mar 29, 2017 at 09:33:18AM +0800, Qu Wenruo wrote:
Unlike mirror based profiles, RAID5/6 recovery needs to read out the
whole full stripe.
And if we don't do proper protect, it can easily cause race condition.
Introduce 2 new functions:
On Wed, Mar 29, 2017 at 09:33:18AM +0800, Qu Wenruo wrote:
> Unlike mirror based profiles, RAID5/6 recovery needs to read out the
> whole full stripe.
>
> And if we don't do proper protect, it can easily cause race condition.
>
> Introduce 2 new functions: lock_full_stripe() and
Unlike mirror based profiles, RAID5/6 recovery needs to read out the
whole full stripe.
And if we don't do proper protect, it can easily cause race condition.
Introduce 2 new functions: lock_full_stripe() and unlock_full_stripe()
for RAID5/6.
Which stores a rb_tree of mutex for full stripes, so
