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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
