headers
Adrian Bunk | 1 Mar 2005 01:31
Picon

[2.6 patch] SCSI: cleanups

Updated patch:

<--  snip  -->

This patch contains the following cleanups:
- make needlessly global code static
- remove the following unused functions:
  - scsi.h: print_driverbyte
  - scsi.h: print_hostbyte
- #if 0 the following unused functions:
  - constants.c: scsi_print_hostbyte
  - constants.c: scsi_print_driverbyte
- remove the following unneeded EXPORT_SYMBOL's:
  - hosts.c: scsi_host_lookup
  - scsi.c: scsi_device_cancel
  - scsi_lib.c: scsi_device_resume

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

---

 drivers/scsi/constants.c   |    4 ++++
 drivers/scsi/hosts.c       |    3 +--
 drivers/scsi/scsi.c        |    9 +++++----
 drivers/scsi/scsi.h        |    8 --------
 drivers/scsi/scsi_debug.c  |    2 +-
 drivers/scsi/scsi_lib.c    |    5 ++---
 drivers/scsi/scsi_priv.h   |    4 ----
 drivers/scsi/scsi_sysfs.c  |    4 ++--
 include/scsi/scsi_dbg.h    |    2 --
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Wilcox | 1 Mar 2005 03:47

Re: [2.6 patch] drivers/scsi/sym53c8xx_2/sym_hipd.c: make a function static

On Mon, Feb 28, 2005 at 11:01:55PM +0100, Adrian Bunk wrote:
> This patch makes a needlessly global function static.

Thanks, committed

--

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Doug Ledford | 1 Mar 2005 07:52
Picon
Favicon

Re: [Patch] QLogic qla2x00 driver fixes

On Fri, 2005-02-25 at 09:02 -0800, Patrick Mansfield wrote:
> On Fri, Feb 25, 2005 at 06:57:39AM -0500, Doug Ledford wrote:
> > On Fri, 2005-02-25 at 03:38 -0500, Jeff Garzik wrote:
> > > Arjan van de Ven wrote:
> > > > On Thu, 2005-02-24 at 23:21 -0500, Doug Ledford wrote:
> > > > 
> > > >>Don't use cmd->request->nr_hw_segments as it may not be initialized
> > > >>(SG_IO in particular bypasses anything that initializes this and just
> > > >>uses scsi_do_req to insert a scsi_request directly on the head of the
> > > >>queue) 
> > > > 
> > > > 
> > > > should we fix that in the SG_IO layer ?
> > > 
> > > Possibly/probably.
> 
> Doug,
> 
> What kernel did you hit this with? 

Our RHEL4 kernel (2.6.9 plus bunches-o'-patches)

> And same question as Doug G: is it via sg (not the block SG_IO)? sg uses
> scsi_do_req(), block SG_IO doesn't.

At the moment, I'm sorting that out.  It's a bit of a black box.  We
have two different loops of commands running on my test machine.  There
are 10 instances of:

while true; do scsiinfo -i /dev/sdf; done
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Mar 2005 08:11

Fw: [Bugme-new] [Bug 4268] New: SCSI performance regression in 2.6.10


Did anything change in the mpt fusion driver?

I'm seeing the same thing, again with mpt-fusion.  38MB/sec when it should
be getting >60.

Begin forwarded message:

Date: Mon, 28 Feb 2005 22:03:57 -0800
From: bugme-daemon <at> osdl.org
To: bugme-new <at> lists.osdl.org
Subject: [Bugme-new] [Bug 4268] New: SCSI performance regression in 2.6.10

http://bugme.osdl.org/show_bug.cgi?id=4268

           Summary: SCSI performance regression in 2.6.10
    Kernel Version: 2.6.10
            Status: NEW
          Severity: normal
             Owner: andmike <at> us.ibm.com
         Submitter: duraid <at> octopus.com.au

Distribution: Debian 'unstable', pristine 2.6.10 kernel
Hardware Environment: HP rx2600 (ia64), LSI 53C1030 U320 SCSI host (Fusion MPT)
Problem Description: There is a quite severe performance regression in 2.6.10
when using SCSI disk drives. (I've tested against 2.4.20, 2.6.8 and 2.6.9, none
of which exhibit this problem)

Steps to reproduce: dd if=/dev/sdXX of=/dev/null bs=1048576 count=10000
(streaming read the first 10GB of scsi disk XX)
(Continue reading)

Permalink | Reply | 0 comments |
headers
FUJITA Tomonori | 1 Mar 2005 08:19
Picon
Gravatar

[ANNOUNCE] iSCSI enterprise target software

Hi,

I would like to announce the iSCSI enterprise target (IET) software,
which is open-source software to build iSCSI storage systems. It can
provide disk volumes to iSCSI initiators by using any kinds of files
(regular files, block devices, virtual block devices like RAID and
LVM, etc). The project was started by forking the Ardis target
implementation (http://www.ardistech.com/iscsi/) about one year
ago. The source code and further information are available from:

http://iscsitarget.sourceforge.net/

The user-space daemon handles authentication and the kernel threads
take care of network and disk I/O requests from initiators by using
the VFS interface. The kernel-space code is not intrusive. It doesn't
touch other parts of the kernel. The code is already stable and
usable. More than 130 people currently subscribe to the project's
mailing list. The developers aim for inclusion into the mainline
kernel.

The latest code against 2.6.11-rc5 for review can be found at:

http://zaal.org/iscsi/iet/0.4.6/r996.tar.gz

Could you please review the code? Any comments are greatly
appreciated.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 30 comments |
headers
Douglas Gilbert | 1 Mar 2005 09:14

Re: [2.6 patch] SCSI: possible cleanups

Adrian Bunk wrote:
> Before I'm getting flamed to death:

Adrian,
I have a few comments below.

> This patch contains possible cleanups. If parts of this patch conflict 
> with pending changes these parts of my patch have to be dropped.
> 
> This patch contains the following possible cleanups:
> - make needlessly global code static
> - remove or #if 0 the following unused functions:
>   - scsi.h: print_driverbyte
>   - scsi.h: print_hostbyte

The names of the above are too general so they should go
as soon as practical.

>   - constants.c: scsi_print_hostbyte
>   - constants.c: scsi_print_driverbyte

I'm a bit surprised nothing else is using the above two.

>   - scsi_scan.c: scsi_scan_single_target
> - remove the following unneeded EXPORT_SYMBOL's:
>   - constants.c: __scsi_print_sense
>   - hosts.c: scsi_host_lookup
>   - scsi.c: scsi_device_cancel
>   - scsi_error.c: scsi_normalize_sense
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arjan van de Ven | 1 Mar 2005 09:40
Favicon

Re: [ANNOUNCE] iSCSI enterprise target software

On Tue, 2005-03-01 at 16:19 +0900, FUJITA Tomonori wrote:

> The user-space daemon handles authentication and the kernel threads
> take care of network and disk I/O requests from initiators by using
> the VFS interface. The kernel-space code is not intrusive. It doesn't
> touch other parts of the kernel. The code is already stable and
> usable. More than 130 people currently subscribe to the project's
> mailing list. The developers aim for inclusion into the mainline
> kernel.

> Could you please review the code? Any comments are greatly
> appreciated.
> -

can you explain why the target has to be inside the kernel and can't be
a pure userspace daemon ?

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 29 comments |
headers
Jens Axboe | 1 Mar 2005 09:47
Picon

Re: [PATCH] scsi/sata write barrier support

On Tue, Feb 22 2005, Greg Stark wrote:
> 
> Jens Axboe <axboe <at> suse.de> writes:
> 
> > fsync has been working all along, since the initial barrier support for
> > ide. only ext3 and reiserfs support it.
> 
> Really? That's huge news. Since what kernel version(s) is that?

Since 2.6.9.

> What about a non-journaled fs, or at least a meta-data-only-journaled fs?
> Journaled FS's don't mix well with transaction based databases since they're
> basically doing their own journaling anyways.

Only works on ext3 and reiserfs currently.

--

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Zhao, Forrest | 1 Mar 2005 10:06
Picon
Favicon

One question about SCSI device hotplug

Hi, list

If I surprisingly hot-remove a SCSI disk from HBA manually 
without executing "echo "scsi remove-single-device
 <h> <b> <t <l>" > /proc/scsi/scsi", can the "hotplug"
event be notified to SCSI mid-layer or user space?

I briefly browse some code of LLDD, it seems that LLDD never
report "hotplug" event to upper-level layer. Am I right?

Thanks,
Forrest
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
FUJITA Tomonori | 1 Mar 2005 10:35
Picon
Gravatar

Re: [ANNOUNCE] iSCSI enterprise target software

From: Arjan van de Ven <arjan <at> infradead.org>
Subject: Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 09:40:38 +0100

> > Could you please review the code? Any comments are greatly
> > appreciated.
> > -
> 
> can you explain why the target has to be inside the kernel and can't be
> a pure userspace daemon ?

o synchronization

Suppose that an target runs in the user space and an initiator sends
two WRITE commands (A and B) with the simple attribute.

The target can write A and B simultaneously. Before the target sends
the response of A, A must be committed to disk (that is, some dirty
page cache must be committed). So the target calls fsync(). It commits
A to disk. Moreover, it also commits B to disk unnecessarily. This
really hurts performance.

The current code uses the sync_page_range function.

o disk drive cache

When the target calls fsync(), dirty page cache is supposed to be
committed to disk. However, the disk drive uses write-back policy, it
is not. The data is still in disk drive cache. There is no system call
to control disk drive cache. So the target (in the user space) cannot
(Continue reading)

Permalink | Reply | 28 comments |

Gmane