On Mon, 29 Nov 2010 19:09:46 +0200 (EET)
Kai Makisara <Kai.Makisara@xxxxxxxxxxx> wrote:
> > This same behaviour appears when we're doing a few incremental backups;
> > after a while, it just isn't possible to use the tape drives anymore -
> > every I/O operation gives an I/O Error, even a simple dd bs=64k
> > count=10. After a restart, the system behaves correctly until
> > -seemingly- another memory pressure situation occured.
> >
> This is predictable. The maximum number of scatter/gather segments seems
> to be 128. The st driver first tries to set up transfer directly from the
> user buffer to the HBA. The user buffer is usually fragmented so that one
> scatter/gather segment is used for each page. Assuming 4 kB page size, the
> maximu size of the direct transfer is 128 x 4 = 512 kB.
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 */
}
--
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
