Re: [PATCH V3 1/2] RAID1: a new I/O barrier implementation to remove resync window

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Feb 25, 2017 at 01:06:22AM +0800, Coly Li wrote:
> On 2017/2/24 上午7:14, NeilBrown wrote:
> > On Thu, Feb 23 2017, Coly Li wrote:
> > 
> >> 
> >> I tried to set up a 4 layer stacked md raid1, and reduce I/O
> >> barrier bucket size to 8MB, running for 10 hours, there is no
> >> deadlock observed,
> > 
> > Try setting BARRIER_BUCKETS_NR to '1' and BARRIER_UNIT_SECTOR_BITS
> > to 3 and make sure the write requests are larger than 1 page (and
> > have resync happen at the same time as writes).
> 
> Hi Neil,
> 
> Yes, the above method triggers deadlock easily. After come to
> understand how bios are handled in stacked raid1 and the relationship
> between current->bio_list, plug->pending and conf->pending_bio_list, I
> think I come to understand what you worried and the meaning of your fix.
> 
> I totally agree and understand there will be hash conflict sooner or
> later now. Yes we need this fix.
> 
> Thanks to you and Shaohua, explaining the details to me, and help me
> to catch up your mind :-)

I'm confused. So the deadlock is real? How is it triggered?

Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux