All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 12207] block reads/writes > 122880 bytes to USB tape drive gives EBUSY
Date: Fri, 10 Apr 2009 15:19:24 GMT	[thread overview]
Message-ID: <200904101519.n3AFJOij032488@demeter.kernel.org> (raw)
In-Reply-To: <bug-12207-11613@http.bugzilla.kernel.org/>

http://bugzilla.kernel.org/show_bug.cgi?id=12207





--- Comment #28 from Alan Stern <stern@rowland.harvard.edu>  2009-04-10 15:19:23 ---
On Fri, 10 Apr 2009 bugzilla-daemon@bugzilla.kernel.org wrote:

> --- Comment #27 from oshida@bb-next.net  2009-04-10 09:48:44 ---
> Thanks for reading.
> 
> Please share that this is just for tape device.

Your patch affects the max_sectors attribute file for all devices, not 
just for tape devices.

> > Where did your limit come from?
> 
> Just above experiments.
> But 4MB (or twiced 8MB) is not my recommend. For reguralizing I hope you to
> decide which is reasonable value.
> 
> Generally, there is no device which can operate the block size larger than
> 0xffffff bytes. This is from the SCSI tape device specification. (T10/SSC)

So there is no _tape_ device which can operate with larger block size.  
But maybe a non-tape device can.

Besides, the block size isn't the same as max_sectors.  max_sectors is 
allowed to be larger than the block size (but it mustn't be smaller).

> > Why do you want to do this?  The attribute is named "max_sectors", so 
> > shouldn't it return the value of max_sectors?
> 
> I can agree your suggestion but then I need declaring the read only attribute
> named "max_hw_sectors".

Why?

> I don't know the restrictions arround scsi driver stacks, ex, what max_sectors
> is used for and max_hw_sectors is used for. But by simple image, if a really
> effective value can be set onto a variable, it should be verifiable by reading
> same variable.

max_hw_sectors is supposed to be the largest transfer size supported by 
the hardware.  max_sectors is supposed to be the largest transfer size 
the kernel will use.  Therefore we should always have max_sectors <= 
max_hw_sectors.

With USB mass-storage devices this is difficult, because the driver 
doesn't know what transfer sizes are supported by the hardware.  The 
USB protocol doesn't provide this information.

> > Did you know that max_sectors can also be changed through the block 
> > interface?
> 
> I'm sorry I did not. Thanks for teaching.
> But I could not find the device (of course tape drive) under that tree. I think
> that is just for kinds of block device which can be manipulated with T10/SBC
> command set.

No, it is for all block devices.  If you can't find your device under 
/sys/block/ then look for it somewhere else, such as under 
/sys/bus/scsi/devices/.

Alan Stern

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

  parent reply	other threads:[~2009-04-10 15:19 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-12 21:41 [Bug 12207] New: block reads/writes > 122880 bytes to USB tape drive gives EBUSY bugme-daemon
2008-12-22 17:44 ` [Bug 12207] " bugme-daemon
2008-12-22 18:08 ` bugme-daemon
2008-12-22 18:09 ` bugme-daemon
2008-12-22 18:09 ` bugme-daemon
2008-12-23  7:30 ` bugme-daemon
2008-12-23 12:31   ` Oliver Neukum
2008-12-23 12:32 ` bugme-daemon
2008-12-23 13:56 ` bugme-daemon
2008-12-23 13:59 ` bugme-daemon
2008-12-23 14:47   ` Boaz Harrosh
2008-12-23 14:55   ` James Bottomley
2008-12-23 15:33     ` James Bottomley
2008-12-23 14:42 ` bugme-daemon
2008-12-23 14:46 ` bugme-daemon
2008-12-23 14:48 ` bugme-daemon
2008-12-23 14:54 ` bugme-daemon
2008-12-23 14:56 ` bugme-daemon
2008-12-23 15:33 ` bugme-daemon
2008-12-23 16:18 ` bugme-daemon
2008-12-23 16:30   ` Kai Makisara
2008-12-23 16:42     ` James Bottomley
2008-12-23 16:30 ` bugme-daemon
2008-12-23 16:42 ` bugme-daemon
2008-12-24  2:56 ` bugme-daemon
2008-12-24  4:19   ` FUJITA Tomonori
2008-12-24  4:19 ` bugme-daemon
2008-12-30 19:39 ` bugme-daemon
2009-02-05 21:12 ` bugme-daemon
2009-02-05 21:48 ` bugme-daemon
2009-03-09 20:48 ` bugme-daemon
2009-03-09 20:55 ` bugme-daemon
2009-03-22 20:52 ` bugme-daemon
2009-03-26 19:35 ` bugzilla-daemon
2009-04-07 10:43 ` bugzilla-daemon
2009-04-09 21:08 ` bugzilla-daemon
2009-04-10  9:48 ` bugzilla-daemon
2009-04-10 15:19 ` bugzilla-daemon [this message]
2009-04-10 19:29 ` bugzilla-daemon
2009-04-11  2:38 ` bugzilla-daemon
2009-04-11  6:12 ` bugzilla-daemon
2009-04-11 14:26 ` bugzilla-daemon
2009-04-15  9:55 ` bugzilla-daemon
2009-04-15 15:42 ` bugzilla-daemon

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=200904101519.n3AFJOij032488@demeter.kernel.org \
    --to=bugzilla-daemon@bugzilla.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.