> Introduce struct scsi_vpd for the VPD page length, data and the
> RCU head that will be used to free the VPD data. Use kfree_rcu()
> instead of kfree() to free VPD data. Move the VPD buffer pointer
> check inside the RCU read lock in the sysfs code. Only annotate
> pointers that are shared
> Introduce the scsi_get_vpd_buf() and scsi_update_vpd_page()
> functions. The only functional change in this patch is that if
> updating page 0x80 fails that it is attempted to update page 0x83.
>
> Signed-off-by: Bart Van Assche
> Acked-by: Hannes Reinecke
J .
> Bottomley <j...@linux.vnet.ibm.com>
> Cc: linux-scsi@vger.kernel.org; Bart Van Assche <bart.vanass...@wdc.com>;
> Christoph Hellwig <h...@lst.de>; Hannes Reinecke <h...@suse.de>;
> Johannes Thumshirn <jthumsh...@suse.de>; Seymour, Shane M
> <shane.seym...@hpe.com
inux.vnet.ibm.com>
> Cc: linux-scsi@vger.kernel.org; Bart Van Assche <bart.vanass...@wdc.com>;
> Christoph Hellwig <h...@lst.de>; Hannes Reinecke <h...@suse.de>;
> Johannes Thumshirn <jthumsh...@suse.de>; Seymour, Shane M
> <shane.seym...@hpe.com&g
> Hello Shane,
>
> You have either misinterpret my statement or the SCSI VPD handling code. If
> you have a look at the SCSI VPD handling code you will see that an
> rcu_read_lock() /
> rcu_read_unlock() pair is sufficient to prevent that the VPD buffer
> rcu_dereference() points at is being
> -Original Message-
> From: Bart Van Assche [mailto:bart.vanass...@wdc.com]
> Sent: Friday, August 25, 2017 2:54 AM
> To: h...@lst.de
> Cc: j...@linux.vnet.ibm.com; linux-scsi@vger.kernel.org; h...@suse.de;
> jthumsh...@suse.de; martin.peter...@oracle.com; Seymour, Sha
Reviewed-by: Shane Seymour
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Shane Seymour
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Shane Seymour
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Shane Seymour
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> But this has nothing to do with the patchset, right?
Correct.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Hannes,
How do you know that a request for an async scan is complete (I'm assuming that
you get add or change udev events)? Assuming that someone has manually started
a scan on something (e.g. some newly presented devices after boot) and all
scans are going to be async how do you when it is
Hi Kai,
I've done more tested. Some stuff didn't work and I've got some suggested
changes (there are two changes to the patch and one for the mt command).
Testing results first:
# echo 1 > /sys/bus/scsi/drivers/st/debug_flag
# mt -f /dev/st2 stsetoption can-partitions
# mt -f /dev/st1
Hi Kai,
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of "Kai Mäkisara (Kolumbus)"
> Sent: Tuesday, February 02, 2016 5:43 AM
> To: Seymour, Shane M
> Cc: Laurence Oberman; Emmanuel Florac;
Shane
> -Original Message-
> From: makisara@kai.makisara.private [mailto:makisara@kai.makisara.private]
> On Behalf Of Kai Makisara
> Sent: Saturday, January 30, 2016 4:22 AM
> To: Seymour, Shane M
> Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux-
&
Hi Kai,
$ pwd
/sys/class/scsi_tape/st1/device
$ cat scsi_level
4
Thanks
Shane
> -Original Message-
> From: "Kai Mäkisara (Kolumbus)" [mailto:kai.makis...@kolumbus.fi]
> Sent: Friday, January 29, 2016 4:04 AM
> To: Seymour, Shane M
> Cc: Laurence Oberman;
Hi Laurence,
> -Original Message-
> From: Laurence Oberman [mailto:lober...@redhat.com]
> Sent: Friday, January 29, 2016 10:25 AM
> To: Seymour, Shane M
> Cc: Kai Mäkisara (Kolumbus); Emmanuel Florac; Laurence Oberman; linux-
> s...@vger.kernel.org
> Subject: Re:
day, January 25, 2016 8:05 AM
> To: Seymour, Shane M
> Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux-
> s...@vger.kernel.org
> Subject: RE: What partition should the MTMKPART argument specify? Was:
> Re: st driver doesn't seem to grok LTO partitioning
>
> On
Hi Emmanuel,
> Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2 PB
> which leaves some time to think about it, until LTO-15 circa 2036 :)
There will be other issues to solve before then (by LTO-9 2 with compression
or LTO-10 without compression and we're at LTO-7 now). Take tar
Hi Kai,
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of "Kai Mäkisara (Kolumbus)"
> Sent: Friday, January 22, 2016 7:59 AM
> To: Seymour, Shane M
> Cc: Laurence Oberman; Emmanuel Florac;
My applogies:
> It may be worth noting (if you're going to update any documentation) that
> isn't 100% accurate. You actually get one wrap in partition 1 and the rest
> minus one wrap into partition 0. There is one wrap used as a guard between
> the two partitions. The size given to a partition
> len = snprintf(fname, 99, "%s", buf);
> - fname[len-1] = '\0';
Since it appears that's the only time len is actually used in that function can
you please remove the variable len completely as part of the patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi"
If you need help with anything please let me know I'd be more than happy to
contribute (with testing and a review if you want). I have a system with an
older LTO-3 tape drive that I can use any time (it doesn’t support partitioning
so if nothing else I can make sure partitioning attempts fail
> The VPD page information might change, so we need to be able to
> update it. This patch implements a VPD page rescan whenever
> the 'rescan' sysfs attribute is triggered.
>
> Signed-off-by: Hannes Reinecke
> ---
Reviewed-by: Shane Seymour
--
To
Hi Hannes,
I have one probably small nitpick about the patch. I'm not sure how likely what
I've put below is likely to happen in real life though.
Is there any chance at all that sdev->vpd_pg83_len could change when updated?
If there's any chance of that I'd have expected that both the length
Change st driver to allow enabling or disabling debug output
via sysfs file /sys/bus/scsi/drivers/st/debug_flag.
Previously the only way to enable debug output was:
1. loading the driver with the module parameter debug_flag=1
2. an ioctl call (this method was also the only way to dynamically
Hi James,
There's been no ack on this one. However, there's no actual reason to
prefer scnprintf over snprintf: the former will zero terminate, the
latter won't if the write length is over the buffer length, but this is
a file buffer: the routine will return as many bytes to userspace as are
While tape stats were being implemented in the kernel I started working
on a program that would read them out and display the data to allow me
to test the interface. After the changes were available in linux-next
I worked with the upstream sysstat maintainer to get that code into shape
so it was
A regression was introduced into the hpsa driver a while back so
non-zero LUNs of multi-LUN devices may no longer be presented via
a SAS based Smart Array. I have not done a bisection to discover
the change that caused it.
The CISS firmware specification (available on sourceforge)
defines an 8
-Original Message-
From: linux-scsi-ow...@vger.kernel.org
[mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Matthew R. Ochs
Sent: Monday, April 27, 2015 2:50 PM
To: linux-scsi@vger.kernel.org; james.bottom...@hansenpartnership.com;
n...@linux-iscsi.org; brk...@linux.vnet.ibm.com
Cc:
Two SLES11 SP3 servers encountered similar crashes simultaneously
following some kind of SAN/tape target issue:
...
qla2xxx [:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002.
qla2xxx [:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002.
qla2xxx
Changed DEVICE_ATTR macro usage to DEVICE_ATTR_RO|WO|RW.
This also forced some show/store function names to change.
Changed all show method snprintf() usage to scnprintf() per
Documentation/filesystems/sysfs.txt.
Signed-off-by: Shane Seymour shane.seym...@hp.com
---
Changes from v1:
Dropped one
Convert DEVICE_ATTR macro usage to DEVICE_ATTR_RO|WR|WO
Changes forced some function names to change.
Signed-off-by: Shane Seymour shane.seym...@hp.com
---
--- a/drivers/scsi/hpsa.c 2015-06-30 16:34:01.403904650 -0500
+++ b/drivers/scsi/hpsa.c 2015-06-30 16:21:54.214954176 -0500
@@
Remove unneccessary variable from raid_level_show
Signed-off-by: Shane Seymour shane.seym...@hp.com
---
Was not in previous patch.
--- a/drivers/scsi/hpsa.c 2015-06-30 16:15:42.631979483 -0500
+++ b/drivers/scsi/hpsa.c 2015-06-30 16:16:45.737975186 -0500
@@ -612,7 +612,6 @@ static
Changed all show method snprintf usage to scnprintf per
Documentation/filesystems/sysfs.txt.
Signed-off-by: Shane Seymour shane.seym...@hp.com
---
Please let me know if this is not the correct way to submit
patches by separating them but keeping them logically
together.
--- a/drivers/scsi/hpsa.c
Changed DEVICE_ATTR macro usage to DEVICE_ATTR_RO|WO|RW.
This also forced some show/store function names to change.
Changed all show method sprint/snprintf usage to scnprintf per
Documentation/filesystems/sysfs.txt.
Signed-off-by: Shane Seymour shane.seym...@hp.com
---
--- a/drivers/scsi/hpsa.c
Converted dh_state to use DEVICE_ATTR_RW macro
instead of __ATTR. That forced a change to the associated
show/store function names and the name of the attribute.
Changed usage of snprintf in show function to scnprintf per
Documentation/filesystems/sysfs.txt.
Signed-off-by: Shane Seymour
Converted dh_state to use DEVICE_ATTR_RW macro
instead of __ATTR. That forced a change to the associated
show/store function names and the name of the attribute.
Changed usage of snprintf in show function to scnprintf per
Documentation/filesystems/sysfs.txt.
Signed-off-by: Shane Seymour
Convert DRIVER_ATTR macros to DRIVER_ATTR_RO requested by
Greg KH. Also switched to using scnprintf instead of snprintf
per Documentation/filesystems/sysfs.txt.
Suggested-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Shane Seymour shane.seym...@hp.com
---
This patch was
Convert DRIVER_ATTR macros to DRIVER_ATTR_RO as requested by
Greg KH. Also switched to using sprintf as nothing printed should
exceed PAGE_SIZE - based on feedback from Greg when implementing
show functions for tape stats.
Suggested-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Convert DRIVER_ATTR macros to DRIVER_ATTR_RO as requested by
Greg KH. Also switched to using sprintf as nothing printed should
exceed PAGE_SIZE - based on feedback from Greg when implementing
show functions for tape stats.
Suggested-by: Greg Kroah-Hartman gre...@linuxfoundation.org
This patch changes the st driver to use attribute groups so
driver sysfs files are created automatically. See the
following for reference:
http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
Signed-off-by: Shane Seymour shane.seym...@hp.com
---
--- a/drivers/scsi/st.c
With a size of 48 while it won't overflow since you're using snprintf the
string with a maximum value in %d:
echo -n cmd 2147483647 RESET FAILED, new lockup detected |wc -c
48
is 48 characters long without a null terminator on the string (and in the
unlikely event that it's somehow a the
st: implement tape statistics
This patch implements tape statistics in the st module via
sysfs. Current no statistics are available for tape I/O and there
is no easy way to reuse the block layer statistics for tape
as tape is a character device and does not have perform I/O in
sector sized
My apologies for this I'm fixing it now.
-Original Message-
From: kbuild test robot [mailto:fengguang...@intel.com]
Sent: Monday, June 01, 2015 12:36 PM
To: Seymour, Shane M
Cc: kbuild-...@01.org; James Bottomley; Christoph Hellwig;
linux-scsi@vger.kernel.org
Subject: [scsi:misc 114/120
Signed-off-by: Shane Seymour shane.seym...@hp.com
Tested-by: Shane Seymour shane.seym...@hp.com
---
Changes from v6
- Removed tested by Laurence Oberman since the code has changed
significantly.
- Changed code to use ktime so time resolution is now in ns (Robert
Elliot) for virtual tape drives
The following patch exposes statistics for the st driver via sysfs.
There is a need for companies with large numbers of tape drives
numbering in the tens of thousands to track the performance of
those tape drives (e.g. when a backup exceeds its window). The
statistics provided should allow the
Retested with patch applied to 4.0.0-rc2-next-20150304 - all successful with no
issues found.
-Original Message-
From: Laurence Oberman [mailto:oberma...@gmail.com]
Sent: Thursday, February 26, 2015 5:47 AM
To: Seymour, Shane M
Cc: Greg KH; linux-scsi@vger.kernel.org; Laurence Oberman
The following patch exposes statistics for the st driver via sysfs.
There is a need for companies with large numbers of tape drives
numbering in the tens of thousands to track the performance of
those tape drives (e.g. when a backup exceeds its window). The
statistics provided should allow the
The following patch exposes statistics for the st driver via sysfs.
There is a need for companies with large numbers of tape drives
numbering in the tens of thousands to track the performance of those
tape drives (e.g. when a backup exceeds its window). The statistics
provided should allow the
Hi Greg,
Thank you for pushing me to go that little further. The statistics directory is
back. Any feedback from anyone would be appreciated.
Thanks
Shane
--
Signed-off-by: shane.seym...@hp.com
Tested-by: shane.seym...@hp.com
---
--- a/drivers/scsi/st.c 2015-01-11 14:46:00.243814755 -0600
+++
The following patch exposes statistics for the st driver via sysfs. There is a
need for companies with large numbers of tape drives numbering in the tens of
thousands to track the performance of those tape drives (e.g. when a backup
exceeds its window). The statistics provided should allow the
And you need to put below the --- line what has changed from the last
version, I don't see any of my comments address here :(
Doh! My appologies Greg, I'd missed your inline comments - I haven't had enough
coffee this morning.
--
To unsubscribe from this list: send the line unsubscribe
Hi All,
Please find attached v3 of the patch. It implements the changes requested by
Greg. The statistics files aren't in a separate directory any more they're
implemented directly as device attributes unless someone has objections to them
being in a place like /sys/class/scsi_tape/*/.
from correcting it. If there's no way to export a partition number
for the devices that support it I can add a new sysfs file (call it partition)
to export it that way and see if I can get the correct value into mt_resid.
-Original Message-
From: Seymour, Shane M
Sent: Monday, February
, Shane M
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] st: implement sysfs based tape statistics v2
One feature of tape statistics is that they're as much about the *tape* as they
are about the *drive*, which is uncommon for block devices. It might be useful
to have a set of counters which
Hello linux-api'ers
There has been some ongoing discussion about the best way to implement tape
statistics. The original method suggested a long time ago used a single file in
sysfs similar to block statistics in sysfs. That lead to an impass about the
code on the linux-scsi mailing list.
The
I was wondering if anyone had any feedback or had any chance to review the
changes?
-Original Message-
From: linux-scsi-ow...@vger.kernel.org
[mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Seymour, Shane M
Sent: Tuesday, January 13, 2015 2:43 PM
To: linux-scsi@vger.kernel.org
Cc
Some small changes since the last version - this version removes two files from
sysfs compared to the last version (read and write block counts since they're
derived from the byte counts they can be calculated in user space) but that's
the only change. This version has been rebased to
I'd like to ask if SCSI_IOCTL_GET_IDLUN should be deprecated? This is in
response to [Bug 88591] SCSI_IOCTL_GET_IDLUN only returns 8 bits for the SCSI
Target value of which has been seen on the mailing list.
It only returns one byte of id, lun, channel, and host number but we have
I was wondering if anyone had a chance to review the patch? Comments are
appreciated and I'm more than happy to make changes that will allow it to be
accepted.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More
I can, but at this point it will be tomorrow (11pm where I am).
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
It's been a year since my last attempt at doing this as I got distracted by
some other things. Comments are appreciated and any questions will be answered.
The following implements sysfs based per device tape statistics files with one
file per statistic and a method of trying to allow a
After moving from from branch next-20141106 to next-2014 to pick up recent
changes to the st driver I found that the following message was being logged by
the kernel (for many other modules as well):
Driver 'st' needs an owner
There was a change in driver_register to check the struct
New version of statistics patch:
- Removed sysfs file containing hint for number of tape drives
- Removed disk like stat file - there is now one file per statistic as per
feedback from James
- Like all other kernel stats these start at zero and keep incrementing (cannot
zero them any more)
-
Patch to clear driver specific data from struct device associated with
a tape drive when released by st unload or because there was a problem
attaching to the device. Currently set in st_probe but never cleared.
Signed-off-by: Shane Seymour shane.seym...@hp.com
Tested-by: Shane Seymour
With the things I've been doing in st it was easier to reboot than unload/load
the st driver since it would likely cause an oops. I applied the patch and have
tested it and the st module unloads/reloads with no problems now.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi
-Original Message-
From: Kai Mäkisara [mailto:kai.makis...@kolumbus.fi]
Sent: Wednesday, February 27, 2013 4:38 AM
To: James Bottomley
Cc: Seymour, Shane M; linux-scsi@vger.kernel.org
Subject: Re: [Patch][RFC] st: provide tape statistics via sysfs
The sysfs files in the patch export
First forgive me for using outlook for this, if there are any issues with what
I sent let me know and I'll send it again from gmail. This is also my first
attempt at a kernel patch so please be gentle.
This patch was written to enable tape statistics via sysfs for the dt driver
based on kernel
69 matches
Mail list logo