Re: [PATCH REPOST 1/2] xfs: drop minlen before tossing alignment on bmap allocs

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

 



> > > > aligned.
> > > > 
> > > 
> > > I agree that this addresses the reported issue, but I can reproduce
> > > other corner cases affected by the original patch that aren't affected
> > > by this one. For example, if the allocation request happens to be
> > > slightly less than blen but not enough to allow for alignment, minlen
> > > isn't dropped and we can run through the same allocation retry sequence
> > > that kills off alignment before success.
> > 
> > But isn't that just another variation of the initial conditions
> > (minlen/maxlen) not being set up correctly for alignment when the AG
> > is empty?
> > 
> 
> Perhaps, though I don't think it's exclusive to an empty AG.
> 
> > i.e. Take the above condition and change it like this:
> > 
> >  	/*
> >  	 * Adjust for alignment
> >  	 */
> > -	if (blen > args.alignment && blen <= args.maxlen)
> > +	if (blen > args.alignment && blen <= args.maxlen + args.alignment)
> >  		args.minlen = blen - args.alignment;
> >  	args.minalignslop = 0;
> > 
> > and now we cover all the cases when blen covers an aligned maxlen
> > allocation...
> > 
> 
> Do we want to consider whether minlen goes to 1? Otherwise that looks
> reasonable to me. What I was trying to get at is just that we should
> consider whether there are any other corner cases (that we might care
> about) where this particular allocation might not behave as expected vs.
> just the example used in the original commit log.
> 
> If somebody wants to send a finalized patch or two with these fixes
> along with the bma.total one (or I can tack it on in reply..?), I'll
> think about it further on review as well..

I didn't realize the conversation was already going on before I replied for the
first time, my apologies for unnecessary emails.

I've been working on some patches about this issue since I had this chat with
Dave, but I do not have anything 'mature' yet, exactly because some of the
issues you mentioned above, like the behavior not being exclusive to an empty
AG, and the fact the generic/223 was still failing after the 'fix' has been
applied (the single large fallocated file worked, but generic/223 no), so I was
kind of chasing my own tails on Friday :D

I'll get back to it today and see what I can do with fresh eyes.

Thanks Dave and Brian.

> 
> Brian
> 
> > Cheers,
> > 
> > Dave.
> > -- 
> > Dave Chinner
> > david@xxxxxxxxxxxxx

-- 
Carlos



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux