All of lore.kernel.org
 help / color / mirror / Atom feed
* bi_vcnt checks for repair
@ 2016-11-10 20:06 Christoph Hellwig
  2016-11-11 19:31 ` Liu Bo
  0 siblings, 1 reply; 3+ messages in thread
From: Christoph Hellwig @ 2016-11-10 20:06 UTC (permalink / raw)
  To: linux-btrfs; +Cc: Miao Xie, Jan Schmidt

Hi all,

btrfs_check_repairable and bio_readpage_error have somewhat odd
looking check for bi_vcnt, checking on how to proceed based on that.

Does anyone remember what they actually are checking for?  Depending
on the exact devices merging bi_vcnt can mean quite a few different
things, and we should probably check for what people actually intended
to check.

The suspect for adding these checks are in Cc, although the commit
history is a bit murky.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: bi_vcnt checks for repair
  2016-11-10 20:06 bi_vcnt checks for repair Christoph Hellwig
@ 2016-11-11 19:31 ` Liu Bo
  2016-11-12 17:34   ` Christoph Hellwig
  0 siblings, 1 reply; 3+ messages in thread
From: Liu Bo @ 2016-11-11 19:31 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-btrfs, Miao Xie, Jan Schmidt

On Thu, Nov 10, 2016 at 12:06:01PM -0800, Christoph Hellwig wrote:
> Hi all,
> 
> btrfs_check_repairable and bio_readpage_error have somewhat odd
> looking check for bi_vcnt, checking on how to proceed based on that.
> 
> Does anyone remember what they actually are checking for?  Depending
> on the exact devices merging bi_vcnt can mean quite a few different
> things, and we should probably check for what people actually intended
> to check.

(These two guys have been silent for some time. :) )

Try to explain it a bit, the following assumes that the data that's
being read has at least one copy in another device,

if a read bio contains two pages and the second one is failing on
checksum check, then we get into bio_readpage_error, in which it finds
this bio has two pages, so it creats a new bio (so-called validation
request) which only includes the fail-on-checksum victim page and issues
it with REQ_FAILFAST_DEV to read the page again in hope of passing the
checksum check, if it stills fails somehow, it comes into
bio_readpage_error again to do another try but along with a different
copy.

Overall, this bi_vcnt is to tell whether the bio is a normal one and a
validation one.  If the validation bio got merged somehow, then we need
to do something to prevent that from happening.

Thanks,

-liubo

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: bi_vcnt checks for repair
  2016-11-11 19:31 ` Liu Bo
@ 2016-11-12 17:34   ` Christoph Hellwig
  0 siblings, 0 replies; 3+ messages in thread
From: Christoph Hellwig @ 2016-11-12 17:34 UTC (permalink / raw)
  To: Liu Bo; +Cc: Christoph Hellwig, linux-btrfs, Miao Xie, Jan Schmidt

On Fri, Nov 11, 2016 at 11:31:51AM -0800, Liu Bo wrote:
> Try to explain it a bit, the following assumes that the data that's
> being read has at least one copy in another device,
> 
> if a read bio contains two pages and the second one is failing on
> checksum check, then we get into bio_readpage_error, in which it finds
> this bio has two pages, so it creats a new bio (so-called validation
> request) which only includes the fail-on-checksum victim page and issues
> it with REQ_FAILFAST_DEV to read the page again in hope of passing the
> checksum check, if it stills fails somehow, it comes into
> bio_readpage_error again to do another try but along with a different
> copy.
> 
> Overall, this bi_vcnt is to tell whether the bio is a normal one and a
> validation one.  If the validation bio got merged somehow, then we need
> to do something to prevent that from happening.

Can't we just set a different end_io handler for the two cases?

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-11-12 17:34 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-10 20:06 bi_vcnt checks for repair Christoph Hellwig
2016-11-11 19:31 ` Liu Bo
2016-11-12 17:34   ` Christoph Hellwig

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.