On 08/17/2012 11:37 AM, James Bottomley wrote:
On Fri, 2012-08-17 at 10:50 -0400, Rob Evers wrote:
Wondering if this would be an acceptable interim solution
to increasing the limit on the number of tape drives
while http://marc.info/?l=linux-scsi&m=134212042809524&w=2
gets sorted out.
Signed-off-by: Rob Evers<revers@xxxxxxxxxx>
---
drivers/scsi/st.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/st.h b/drivers/scsi/st.h
index b548923..408d24f 100644
--- a/drivers/scsi/st.h
+++ b/drivers/scsi/st.h
@@ -76,7 +76,7 @@ struct st_modedef {
#define ST_MODE_SHIFT (7 - ST_NBR_MODE_BITS)
#define ST_MODE_MASK ((ST_NBR_MODES - 1)<< ST_MODE_SHIFT)
-#define ST_MAX_TAPES 128
+#define ST_MAX_TAPES 1024
This is going to cause an order 2 GFP_ATOMIC allocation (on 64 bit
platforms) for the contiguous scsi_tapes array ... if large numbers of
tapes are genuinely required, shouldn't we fix this first and then
expand the number quite a bit more?
James
Pre allocation of cdevs during init time needs addressing as well
to increase ST_MAX_TAPES quite a bit more, right?
Would leaving out Lee's sysfs updates out be ok, if ST_MAX_TAPES were
significantly increased?
Rob
--
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
