A question about "raizn_write" function

[foreverbi]

As shown in Figure 1，if leading_substripe_sectors！=0，the function “raizn_stripe_buffer_parity” will calculate parity and the result will be stored in sh->parity_bufs

But in the next judge：if (bio_sectors(sh->orig_bio) > leading_substripe_sectors + trailing_substripe_sectors) ，If it is true，the function “raizn_bio_parity” will calculate parity and the parameter is still sh->parity_bufs.As shown in Figure 2:

The sh->parity_bufs already has the calculation result of Figure 1,but in the Figure 2,it seems that sh->parity_bufs is not updated,the parameter is still sh->parity_bufs，will this cause the calculation results of Figure 2 to overwrite the results of Figure 1?

[Thomas-Kim]

Sorry for the delay in response, I have been (and still am) a bit ill as of late. I believe this may be a bug, though it does not affect the performance of the system (which is the primary objective of this artifact). I will get around to investigating and fixing it when I have some time.

Thanks,

Thomas

[foreverbi]

Thank you for your reply. I also want to ask what is the capacity of the zone of the disk you use? How does it relate to the size of the stripe unit?

I wish you an early recovery！

[Thomas-Kim]

Thank you for your reply. I also want to ask what is the capacity of the zone of the disk you use? How does it relate to the size of the stripe unit?

I wish you an early recovery！

The capacity of the zones in our drives is around a gigabyte, and it has no bearing on the choice of stripe unit size. Stripe unit size is based on the expected workload.