From: Jens Axboe <axboe@suse.de>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Kurt Garloff <garloff@suse.de>,
Linux SCSI list <linux-scsi@vger.kernel.org>,
Linux kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Format Unit can take many hours
Date: Tue, 11 May 2004 18:14:27 +0200 [thread overview]
Message-ID: <20040511161427.GW1906@suse.de> (raw)
In-Reply-To: <40A0FAE9.90900@pobox.com>
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
next prev parent reply other threads:[~2004-05-11 16:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-11 11:49 [PATCH] Format Unit can take many hours Kurt Garloff
2004-05-11 12:20 ` Jens Axboe
2004-05-11 12:40 ` Arjan van de Ven
2004-05-11 12:46 ` Jens Axboe
2004-05-11 12:44 ` Kurt Garloff
2004-05-11 16:10 ` Jeff Garzik
2004-05-11 16:14 ` Jens Axboe [this message]
2004-05-11 16:26 ` Kurt Garloff
2004-05-11 17:27 ` Jens Axboe
2004-05-11 14:01 ` Ricky Beam
2004-05-11 16:28 ` Bob Tracy
2004-05-11 16:44 ` Ricky Beam
2004-05-11 18:30 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040511161427.GW1906@suse.de \
--to=axboe@suse.de \
--cc=garloff@suse.de \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox