[PATCH] Format Unit can take many hours

[PATCH] Format Unit can take many hours

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 301 bytes --]

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@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #1.2: scsi-format-unit-timeout.diff --]
[-- Type: text/plain, Size: 786 bytes --]

--- 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
 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Format Unit can take many hours

[Jens Axboe]

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@suse.de>                            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.

-- 
Jens Axboe

Re: [PATCH] Format Unit can take many hours

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

On Tue, 2004-05-11 at 14:20, Jens Axboe wrote:
> On Tue, May 11 2004, Kurt Garloff wrote:
> > Hi,
> block/scsi_ioctl.c should likely receive similar treatment then.

how about sticking these in a shared header between the 2 files ?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Format Unit can take many hours

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 306 bytes --]

Hi Jens,

On Tue, May 11, 2004 at 02:20:38PM +0200, Jens Axboe wrote:
> block/scsi_ioctl.c should likely receive similar treatment then.

Good point.
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #1.2: scsi-format-unit-timeout.diff --]
[-- Type: text/plain, Size: 1506 bytes --]

--- 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
 
--- linux-2.6.5/drivers/block/scsi_ioctl.c.orig	2004-05-11 00:05:57.000000000 +0200
+++ linux-2.6.5/drivers/block/scsi_ioctl.c	2004-05-11 14:42:30.277083312 +0200
@@ -209,11 +209,11 @@ static int sg_io(request_queue_t *q, str
 	return 0;
 }
 
-#define FORMAT_UNIT_TIMEOUT		(2 * 60 * 60 * 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 )
+#define READ_DEFECT_DATA_TIMEOUT	(60 * HZ)
 #define OMAX_SB_LEN 16          /* For backward compatibility */
 
 static int sg_scsi_ioctl(request_queue_t *q, struct gendisk *bd_disk,

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Format Unit can take many hours

[Jens Axboe]

On Tue, May 11 2004, Arjan van de Ven wrote:
> On Tue, 2004-05-11 at 14:20, Jens Axboe wrote:
> > On Tue, May 11 2004, Kurt Garloff wrote:
> > > Hi,
> > block/scsi_ioctl.c should likely receive similar treatment then.
> 
> how about sticking these in a shared header between the 2 files ?

yep would be best, ala

===== drivers/block/scsi_ioctl.c 1.42 vs edited =====
--- 1.42/drivers/block/scsi_ioctl.c	Tue Apr 27 15:20:34 2004
+++ edited/drivers/block/scsi_ioctl.c	Tue May 11 14:43:51 2004
@@ -209,11 +209,6 @@
 	return 0;
 }
 
-#define FORMAT_UNIT_TIMEOUT		(2 * 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 )
 #define OMAX_SB_LEN 16          /* For backward compatibility */
 
 static int sg_scsi_ioctl(request_queue_t *q, struct gendisk *bd_disk,
===== drivers/scsi/scsi_ioctl.c 1.24 vs edited =====
--- 1.24/drivers/scsi/scsi_ioctl.c	Mon Aug 25 15:37:40 2003
+++ edited/drivers/scsi/scsi_ioctl.c	Tue May 11 14:45:09 2004
@@ -27,11 +27,6 @@
 
 #define NORMAL_RETRIES			5
 #define IOCTL_NORMAL_TIMEOUT			(10 * HZ)
-#define FORMAT_UNIT_TIMEOUT		(2 * 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 MAX_BUF PAGE_SIZE
 
===== include/scsi/scsi.h 1.20 vs edited =====
--- 1.20/include/scsi/scsi.h	Wed Feb 25 12:37:46 2004
+++ edited/include/scsi/scsi.h	Tue May 11 14:45:25 2004
@@ -362,6 +362,14 @@
 #define SCSI_2          3
 #define SCSI_3          4
 
+/*
+ * default timeouts
+ */
+#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 )
 
 /*
  * Here are some scsi specific ioctl commands which are sometimes useful.


-- 
Jens Axboe

Re: [PATCH] Format Unit can take many hours

[Ricky Beam]

On Tue, 11 May 2004, Kurt Garloff wrote:
>the timeout for FORMAT_UNIT should be much longer; I've seen 8hrs
>already (75Gig). I've increased the timeout from 2hrs to 12hrs.

If you execute a FORMAT_UNIT properly, the timeout is irrelevant.  Set the
IMMED bit so the command returns as soon as the drive begins processing it.
Send TEST_UNIT_READY to check the progress.  I'll have to consult the
spec, but I think support for Immed is required.

That's how my (now 8 year old) tool for formating scsi devices (zip, jaz,
hard disks, tapes, etc.) has always worked. [No, it is not published code.
If the script kiddies want to low-level your hard drive, they're gonna have
to learn how to do it themselves.]

--Ricky

PS: That even works under Solaris where one does not have the source code
    to change the command timeouts.

Re: [PATCH] Format Unit can take many hours

[Jeff Garzik]

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@suse.de>                            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?

	Jeff

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@suse.de>                            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

Re: [PATCH] Format Unit can take many hours

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

Hi,

On Tue, May 11, 2004 at 06:14:27PM +0200, Jens Axboe wrote:
> On Tue, May 11 2004, Jeff Garzik wrote:
> > Jens Axboe wrote:
> > >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?

The disks gets faster as well.

But if we have to touch it every three years, I don't see this as a 
huge problem either. If you want some more room, you can set it to 
24hrs now ...

> 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.

If you do use the sg interface, you can specify the timeout.
If you use SCSI_IOCTL_SEND_COMMAND, there's no way to do it and
the value from scsi_ioctl.c applies.

scsiformat is one of the users.

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

Agreed.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Format Unit can take many hours

[Bob Tracy]

Ricky Beam wrote:
> On Tue, 11 May 2004, Kurt Garloff wrote:
> >the timeout for FORMAT_UNIT should be much longer; I've seen 8hrs
> >already (75Gig). I've increased the timeout from 2hrs to 12hrs.
> 
> If you execute a FORMAT_UNIT properly, the timeout is irrelevant.  Set the
> IMMED bit so the command returns as soon as the drive begins processing it.
> Send TEST_UNIT_READY to check the progress.  I'll have to consult the
> spec, but I think support for Immed is required.

Moreover, it simply "feels" wrong to define a constant for something
that isn't...  The quick fix of increasing the timeout doesn't address
the underlying issue of how long a format should take, and as Ricky
implies, that's probably more the concern of the application rather
than the driver.

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: [PATCH] Format Unit can take many hours

[Ricky Beam]

On Tue, 11 May 2004, Bob Tracy wrote:
>Moreover, it simply "feels" wrong to define a constant for something
>that isn't...  The quick fix of increasing the timeout doesn't address
>the underlying issue of how long a format should take, and as Ricky
>implies, that's probably more the concern of the application rather
>than the driver.

The real problem is a lack of being able to specify a timeout for user
supplied commands.  In-kernel drivers can set a command timeout.  The
IOCTL interface does not export that capability.

--Ricky

Re: [PATCH] Format Unit can take many hours

[Jens Axboe]

On Tue, May 11 2004, Kurt Garloff wrote:
> Hi,
> 
> On Tue, May 11, 2004 at 06:14:27PM +0200, Jens Axboe wrote:
> > On Tue, May 11 2004, Jeff Garzik wrote:
> > > Jens Axboe wrote:
> > > >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?
> 
> The disks gets faster as well.
> 
> But if we have to touch it every three years, I don't see this as a 
> huge problem either. If you want some more room, you can set it to 
> 24hrs now ...

Precisely. No need to over-engineer.
> 
> > 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.
> 
> If you do use the sg interface, you can specify the timeout.
> If you use SCSI_IOCTL_SEND_COMMAND, there's no way to do it and
> the value from scsi_ioctl.c applies.

Even the oldest sg interface? SCSI_IOCTL_SEND_COMMAND should have been
put to rest at least 5 years ago :)

-- 
Jens Axboe

Re: [PATCH] Format Unit can take many hours

[Jens Axboe]

On Tue, May 11 2004, Ricky Beam wrote:
> On Tue, 11 May 2004, Bob Tracy wrote:
> >Moreover, it simply "feels" wrong to define a constant for something
> >that isn't...  The quick fix of increasing the timeout doesn't address
> >the underlying issue of how long a format should take, and as Ricky
> >implies, that's probably more the concern of the application rather
> >than the driver.
> 
> The real problem is a lack of being able to specify a timeout for user
> supplied commands.  In-kernel drivers can set a command timeout.  The
> IOCTL interface does not export that capability.

Noone should use that interface, period. That ioctl is about as bad an
interface as you could imagine. Use any variant of sg and you should be
fine.

-- 
Jens Axboe