Re: [PATCH] Format Unit can take many hours

[Jens Axboe]

On Tue, May 11 2004, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Tue, May 11 2004, Kurt Garloff wrote:
> >
> >>Hi,
> >>
> >>the timeout for FORMAT_UNIT should be much longer; I've seen 8hrs
> >>already (75Gig). I've increased the timeout from 2hrs to 12hrs.
> >>
> >>Regards,
> >>-- 
> >>Kurt Garloff  <garloff@xxxxxxx>                            Cologne, DE 
> >>SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)
> >
> >
> >>--- linux-2.6.5.orig/drivers/scsi/scsi_ioctl.c	2004-04-04 
> >>05:38:20.000000000 +0200
> >>+++ linux-2.6.5/drivers/scsi/scsi_ioctl.c	2004-05-11 
> >>08:59:12.837421215 +0200
> >>@@ -26,12 +26,12 @@
> >>#include "scsi_logging.h"
> >>
> >>#define NORMAL_RETRIES			5
> >>-#define IOCTL_NORMAL_TIMEOUT			(10 * HZ)
> >>-#define FORMAT_UNIT_TIMEOUT		(2 * 60 * 60 * HZ)
> >>+#define IOCTL_NORMAL_TIMEOUT		(10 * HZ)
> >>+#define FORMAT_UNIT_TIMEOUT		(12 * 60 * 60 * HZ)
> >>#define START_STOP_TIMEOUT		(60 * HZ)
> >>#define MOVE_MEDIUM_TIMEOUT		(5 * 60 * HZ)
> >>#define READ_ELEMENT_STATUS_TIMEOUT	(5 * 60 * HZ)
> >>-#define READ_DEFECT_DATA_TIMEOUT	(60 * HZ )  /* ZIP-250 on parallel 
> >>port takes as long! */
> >>+#define READ_DEFECT_DATA_TIMEOUT	(60 * HZ)  /* ZIP-250 on parallel 
> >>port takes as long! */
> >>
> >>#define MAX_BUF PAGE_SIZE
> >
> >
> >block/scsi_ioctl.c should likely receive similar treatment then.
> 
> 
> This timeout is dependent on media size, I should think...
> 
> Is there any reason to think that this timeout will _not_ be continually 
> patched in the future, as larger and larger sizes are used?

I think the timeout is only used for ancient programs that use the old
sg interface. Newer programs should pass in the timeout themselves, or
set IMMED as somebody else in this thread noted.

So I do think the easiest is just to patch this define for the odd case,
and forget about it.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/