Re: [PATCH v4 00/10] Implement device scrub/replace for RAID56

2014-12-02 Thread Chris Mason



On Tue, Dec 2, 2014 at 7:39 AM, Miao Xie mi...@cn.fujitsu.com wrote:
This patchset implement the device scrub/replace function for RAID56, 
the
most implementation of the common data is similar to the other RAID 
type.
The differentia or difficulty is the parity process. The basic idea 
is reading
and check the data which has checksum out of the raid56 stripe lock, 
if the
data is right, then lock the raid56 stripe, read out the other data 
in the
same stripe, if no IO error happens, calculate the parity and check 
the
original one, if the original parity is right, the scrub parity 
passes.
or write out the new one. But if the common data(not parity) that we 
read out
is wrong, we will try to recover it, and then check and repair the 
parity.


And in order to avoid making the code more and more complex, we copy 
some

code of common data process for the parity, the cleanup work is in my
TODO list.

We have done some test, the patchset worked well. Of course, more 
tests

are welcome. If you are interesting to use it or test it, you can pull
the patchset from

  https://github.com/miaoxie/linux-btrfs.git raid56-scrub-replace

Changelog v3 - v4:
- Fix the problem that the scrub's raid bio was cached, which was 
reported

  by Chris.
- Remove the 10st patch, the deadlock that was described in that 
patch doesn't

  exist on the current kernel.
- Rebase the patchset to the top of integration branch


Thanks, I'll try this today.  I need to rebase in a new version of the 
RCU patches, can you please cook one on top of v3.18-rc6 instead?


-chris

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 00/10] Implement device scrub/replace for RAID56

2014-12-02 Thread Wang Shilong

 
 
 
 On Tue, Dec 2, 2014 at 7:39 AM, Miao Xie mi...@cn.fujitsu.com wrote:
 This patchset implement the device scrub/replace function for RAID56, the
 most implementation of the common data is similar to the other RAID type.
 The differentia or difficulty is the parity process. The basic idea is 
 reading
 and check the data which has checksum out of the raid56 stripe lock, if the
 data is right, then lock the raid56 stripe, read out the other data in the
 same stripe, if no IO error happens, calculate the parity and check the
 original one, if the original parity is right, the scrub parity passes.
 or write out the new one. But if the common data(not parity) that we read out
 is wrong, we will try to recover it, and then check and repair the parity.
 And in order to avoid making the code more and more complex, we copy some
 code of common data process for the parity, the cleanup work is in my
 TODO list.
 We have done some test, the patchset worked well. Of course, more tests
 are welcome. If you are interesting to use it or test it, you can pull
 the patchset from
  https://github.com/miaoxie/linux-btrfs.git raid56-scrub-replace
 Changelog v3 - v4:
 - Fix the problem that the scrub's raid bio was cached, which was reported
  by Chris.
 - Remove the 10st patch, the deadlock that was described in that patch 
 doesn't
  exist on the current kernel.
 - Rebase the patchset to the top of integration branch
 
 Thanks, I'll try this today.  I need to rebase in a new version of the RCU 
 patches, can you please cook one on top of v3.18-rc6 instead?
 

BTW, Chris could you please replace with this newer version:
https://patchwork.kernel.org/patch/5359251/

Fengguang reported a build failure regarding this.


 -chris
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Best Regards,
Wang Shilong

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 00/10] Implement device scrub/replace for RAID56

2014-12-02 Thread Miao Xie
On Tue, 2 Dec 2014 08:28:22 -0500, Chris Mason wrote:
 
 
 On Tue, Dec 2, 2014 at 7:39 AM, Miao Xie mi...@cn.fujitsu.com wrote:
 This patchset implement the device scrub/replace function for RAID56, the
 most implementation of the common data is similar to the other RAID type.
 The differentia or difficulty is the parity process. The basic idea is 
 reading
 and check the data which has checksum out of the raid56 stripe lock, if the
 data is right, then lock the raid56 stripe, read out the other data in the
 same stripe, if no IO error happens, calculate the parity and check the
 original one, if the original parity is right, the scrub parity passes.
 or write out the new one. But if the common data(not parity) that we read out
 is wrong, we will try to recover it, and then check and repair the parity.

 And in order to avoid making the code more and more complex, we copy some
 code of common data process for the parity, the cleanup work is in my
 TODO list.

 We have done some test, the patchset worked well. Of course, more tests
 are welcome. If you are interesting to use it or test it, you can pull
 the patchset from

   https://github.com/miaoxie/linux-btrfs.git raid56-scrub-replace

 Changelog v3 - v4:
 - Fix the problem that the scrub's raid bio was cached, which was reported
   by Chris.
 - Remove the 10st patch, the deadlock that was described in that patch 
 doesn't
   exist on the current kernel.
 - Rebase the patchset to the top of integration branch
 
 Thanks, I'll try this today.  I need to rebase in a new version of the RCU 
 patches, can you please cook one on top of v3.18-rc6 instead?

No problem.

Thanks
Miao

 
 -chris
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 00/10] Implement device scrub/replace for RAID56

2014-12-02 Thread Miao Xie
On Tue, 2 Dec 2014 08:28:22 -0500, Chris Mason wrote:
 On Tue, Dec 2, 2014 at 7:39 AM, Miao Xie mi...@cn.fujitsu.com wrote:
 This patchset implement the device scrub/replace function for RAID56, the
 most implementation of the common data is similar to the other RAID type.
 The differentia or difficulty is the parity process. The basic idea is 
 reading
 and check the data which has checksum out of the raid56 stripe lock, if the
 data is right, then lock the raid56 stripe, read out the other data in the
 same stripe, if no IO error happens, calculate the parity and check the
 original one, if the original parity is right, the scrub parity passes.
 or write out the new one. But if the common data(not parity) that we read out
 is wrong, we will try to recover it, and then check and repair the parity.

 And in order to avoid making the code more and more complex, we copy some
 code of common data process for the parity, the cleanup work is in my
 TODO list.

 We have done some test, the patchset worked well. Of course, more tests
 are welcome. If you are interesting to use it or test it, you can pull
 the patchset from

   https://github.com/miaoxie/linux-btrfs.git raid56-scrub-replace

 Changelog v3 - v4:
 - Fix the problem that the scrub's raid bio was cached, which was reported
   by Chris.
 - Remove the 10st patch, the deadlock that was described in that patch 
 doesn't
   exist on the current kernel.
 - Rebase the patchset to the top of integration branch
 
 Thanks, I'll try this today.  I need to rebase in a new version of the RCU 
 patches, can you please cook one on top of v3.18-rc6 instead?

I have updated my raid56-scrub-replace branch, please re-pull it.
  https://github.com/miaoxie/linux-btrfs.git raid56-scrub-replace

The v4 patchset in the mail list can be applied on v3.18-rc6 successfully, so
I don't update it.

Thanks
Miao
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html