On 12/03/2010 02:27 PM, FUJITA Tomonori wrote:
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 */
}
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.
Thanks,
Kai
--
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
