Re: After memory pressure: can't read from tape anymore

[Lukas Kolbe <lkolbe@techfak.uni-bielefeld.de>]

Am Freitag, den 03.12.2010, 09:06 -0600 schrieb James Bottomley:
> On Fri, 2010-12-03 at 16:59 +0200, Kai Mäkisara wrote:
> > On 12/03/2010 02:27 PM, FUJITA Tomonori wrote:
> > >
> > > Can we make enlarge_buffer friendly to the memory alloctor a bit?
> > >
> > > His problem is that the driver can't allocate 2 mB with the hardware
> > > limit 128 segments.
> > >
> > > enlarge_buffer tries to use ST_MAX_ORDER and if the allocation (256 kB
> > > page) fails, enlarge_buffer fails. It could try smaller order instead?
> > >
> > > Not tested at all.
> > >
> > >
> > > diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
> > > index 5b7388f..119544b 100644
> > > --- a/drivers/scsi/st.c
> > > +++ b/drivers/scsi/st.c
> > > @@ -3729,7 +3729,8 @@ static int enlarge_buffer(struct st_buffer * STbuffer, int new_size, int need_dm
> > >   		b_size = PAGE_SIZE<<  order;
> > >   	} else {
> > >   		for (b_size = PAGE_SIZE, order = 0;
> > > -		     order<  ST_MAX_ORDER&&  b_size<  new_size;
> > > +		     order<  ST_MAX_ORDER&&
> > > +			     max_segs * (PAGE_SIZE<<  order)<  new_size;
> > >   		     order++, b_size *= 2)
> > >   			;  /* empty */
> > >   	}
> > 
> > You are correct. The loop does not work at all as it should. Years ago,
> > the strategy was to start with as big blocks as possible to minimize the 
> > number s/g segments. Nowadays the segments must be of same size and the 
> > old logic is not applicable.
> > 
> > I have not tested the patch either but it looks correct.
> > 
> > Thanks for noticing this bug. I hope this helps the users. The question 
> > about number of s/g segments is still valid for the direct i/o case but 
> > that is optimization and not whether one can read/write.
> 
> Realistically, though, this will only increase the probability of making
> an allocation work, we can't get this to a certainty.
> 
> Since we fixed up the infrastructure to allow arbitrary length sg lists,
> perhaps we should document what cards can actually take advantage of
> this (and how to do so, since it's not set automatically on boot).  That
> way users wanting tapes at least know what the problems are likely to be
> and how to avoid them in their hardware purchasing decisions.  The
> corollary is that we should likely have a list of not recommended cards:
> if they can't go over 128 SG elements, then they're pretty much
> unsuitable for modern tapes.

Are you implying here that the LSI SAS1068E is unsuitable to drive two
LTO-4 tape drives? Or is it 'just' a problem with the driver?

I'll test both the above patch if it helps in our situation and report
back.

-- 
Lukas


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