On Tue, Mar 06, 2018 at 11:22:21AM -0700, Liu Bo wrote: > On Tue, Mar 06, 2018 at 11:47:47AM +0100, David Sterba wrote: > > On Fri, Mar 02, 2018 at 04:10:37PM -0700, Liu Bo wrote: > > > In case of raid56, writes and rebuilds always take BTRFS_STRIPE_LEN(64K) > > > as unit, however, scrub_extent() sets blocksize as unit, so rebuild > > > process may be triggered on every block on a same stripe. > > > > > > A typical example would be that when we're replacing a disappeared disk, > > > all reads on the disks get -EIO, every block (size is 4K if blocksize is > > > 4K) would go thru these, > > > > > > scrub_handle_errored_block > > > scrub_recheck_block # re-read pages one by one > > > scrub_recheck_block # rebuild by calling raid56_parity_recover() > > > page by page > > > > > > Although with raid56 stripe cache most of reads during rebuild can be > > > avoided, the parity recover calculation(xor or raid6 algorithms) needs to > > > be done $(BTRFS_STRIPE_LEN / blocksize) times. > > > > > > This makes it less stupid by doing raid56 scrub/replace on stripe length. > > > > missing s-o-b > > I'm surprised that checkpatch.pl didn't complain.
Never mind, I'm your true checkpatch.cz (http://checkpatch.pl actually exists) -- 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
