Re: aacraid: latest driver results in Host adapter abort request. / Outstanding commands on (0,0,0,0):
Le Mon, 24 Sep 2018 08:11:20 +0200 Stefan Priebe - Profihost AG écrivait: > all series 6 controllers are those with problems when high load > happens. > As I mentioned in my messages to the ML since late june, the driver doesn't work either with 7xx5 and 8xx5 controllers. Who's maintaining this driver? -- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgp3m6dCcF7E3.pgp Description: Signature digitale OpenPGP
Re: aacraid: latest driver results in Host adapter abort request. / Outstanding commands on (0,0,0,0):
Le Sun, 23 Sep 2018 20:22:56 +0200
Stefan Priebe - Profihost AG écrivait:
> Am 22.09.2018 um 23:40 schrieb Bart Van Assche:
> > On 9/18/18 11:10 PM, Stefan Priebe - Profihost AG wrote:
> >> after upgrading the aacraid driver / kernel from aacraid 50792 to
> >> aacraid 50877.
> >
> > The aacraid driver version was updated to 50792 in commit
> > 0662cc968ace ("scsi: aacraid: Update driver version") and to 50877
> > in commit 1cdb74b80f93 ("scsi: aacraid: Update driver version to
> > 50877"). That means that the regression you encountered got
> > introduced after commit 0662cc968ace. 114 changes got checked in
> > after that commit. That's too much to find the root cause by
> > rereading all these changes. Is there any way to trigger the
> > problem faster such that it becomes feasible to run a bisect?
>
> Sadly i'm not able. May be also something else in the kernel has
> changed.
>
> I'm now trying the original out of tree driver from microsemi /
> adaptec: Adaptec aacraid driver 1.2.1.56008src
>
> No idea how those driver versions corespond to the kernel ones.
I can tell you that the last working version for me is 50834. You can
find the version number in aacraid.h, that's the value of
the AAC_DRIVER_BUILD constant.
the 50877 driver has been broken since it was out several months ago!
--
Emmanuel Florac | Direction technique
| Intellique
|
| +33 1 78 94 84 02
pgpnWeRtVzBvT.pgp
Description: Signature digitale OpenPGP
Re: aacraid: latest driver results in Host adapter abort request. / Outstanding commands on (0,0,0,0):
Le Wed, 19 Sep 2018 08:10:41 +0200 Stefan Priebe - Profihost AG écrivait: > Hello, > > after upgrading the aacraid driver / kernel from aacraid 50792 to > aacraid 50877. > > I get aborted comands every night. > I have exactly the same problem since 4.15 was out, and nobody answered... aacraid doesn't work properly neither with ASR7xx5 or ASR8xx5 cards. -- ---- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgpONEVFsp4Xf.pgp Description: Signature digitale OpenPGP
Re: st driver doesn't seem to grok LTO partitioning [coming back 2 and a half years later]
Le Fri, 15 Jan 2016 12:48:09 +0100 Emmanuel Florac écrivait: > Le Thu, 14 Jan 2016 15:12:53 -0500 (EST) > Laurence Oberman écrivait: > > > All attempts to get my drive and changer firmware updated have > > failed. So I wont be able to add another "tested by" to this thread > > unless I can find another drive. > > Too bad, would have been good to test on a different brand. I have an > IBM drive somewhere, but it's an LTO-4 alas. I know that IBM and HP > drives may have some significant differences in behaviour. I finally tested with an IBM LTO-6 drive, and as feared, it doesn't behave like the HP LTO-6 drive. I had previously found that partitioning an LTO-6 tape using an HP drive like this worked just fine: mt -f /dev/nst0 mkpartition 245 It actually silently rounds the value to the closest number. However, the very same command fails with an IBM drive with an "input output error", and the following output in dmesg ( st driver in debug mode): [8329294.626574] st 7:0:2:0: [st0] Loading tape. [8329294.631672] st 7:0:2:0: [st0] Block limits 1 - 8388608 bytes. [8329294.632350] st 7:0:2:0: [st0] Mode sense. Length 11, medium 68, WBS 10, BLL 8 [8329294.632352] st 7:0:2:0: [st0] Density 5a, tape length: 0, drv buffer: 1 [8329294.632354] st 7:0:2:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). [8329294.633210] st 7:0:2:0: [st0] Partition page length is 16 bytes. [8329294.633213] st 7:0:2:0: [st0] psd_cnt 2, max.parts 3, nbr_parts 0 [8329294.633214] st 7:0:2:0: [st0] Formatting tape with two partitions (1 = 245 MB). [8329294.635533] st 7:0:2:0: [st0] Error: 802, cmd: 15 10 0 0 18 0 [8329294.635536] st 7:0:2:0: [st0] Sense Key : Illegal Request [current] [8329294.635539] st 7:0:2:0: [st0] Add. Sense: Invalid field in parameter list [8329294.635541] st 7:0:2:0: [st0] Partitioning of tape failed. However with a slightly lower size it works: root@srv-num-4:~# mt -f /dev/nst0 mkpartition 2426400 With the log output: Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Block limits 1 - 8388608 bytes. Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Mode sense. Length 11, medium 68, WBS 10, BLL 8 Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Density 5a, tape length: 0, drv buffer: 1 Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Loading tape. Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Block limits 1 - 8388608 bytes. Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Mode sense. Length 11, medium 68, WBS 10, BLL 8 Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Density 5a, tape length: 0, drv buffer: 1 Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Partition page length is 16 bytes. Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] psd_cnt 2, max.parts 3, nbr_parts 0 Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Formatting tape with two partitions (1 = 2426000 MB). Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Error: 802, cmd: 15 10 0 0 18 0 Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Sense Key : Recovered Error [current] Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Add. Sense: Rounded parameter Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Recovered ioctl error (1). Jul 18 17:30:00 srv-num-4 kernel: st 7:0:2:0: [st0] Sending FORMAT MEDIUM Contrary to the HP drive, the IBM drive let us know that the parameter we passed was slightly off and rounded to the nearest value, which is the polite thing to do. Unfortunately, another difference with the HP drive is that it only rounds to the *highest* nearest value, and doesn't bother rounding down, so a slightly too high value will go unnoticed with the HP drive, and will fail completely with the IBM one. Isn't life wonderful? Cheers, -- -------- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgpSV1FSBsRE6.pgp Description: Signature digitale OpenPGP
Re: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work
Le Tue, 3 Jul 2018 17:37:56 + Dave Carroll écrivait: > > [ 61.076949] SME is active and system is using DMA bounce buffers > > [ 61.076954] aacraid: Comm Interface type2 enabled > > > > Both controllers are capable of 64-bit DMA, however the communication > area should be 32-bit. Is this issue specific to Secure Memory > Encryption? Does it occur without that enabled? The machine with the big array is a very old Opteron, so it definitely not SME capable. I'll try without SME to be sure, is there a way to disable it that you know of or should I compile another kernel? -- -------- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgpBICeXAyukJ.pgp Description: Signature digitale OpenPGP
Re: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work
Le Tue, 3 Jul 2018 16:59:41 + Dave Carroll écrivait: > Hi Emmanuel, > > It is curious that the FW is having outstanding commands ... I've > created a ticket to iderntify the differences. I suspect that the > large drive size may be related, but all options are open. > I have already set up many drives of this size previously, using ASR8xx5 controllers, without any problem. On another machine with a simple 8x1TB array, it doesn't work any better, while an older kernel works perfectly fine too: 4.14.48 : [ 61.069190] Adaptec aacraid driver 1.2.1[50834]-custom [ 61.069527] aacraid :21:00.0: SME is active, device will require DMA bounce buffers [ 61.076949] SME is active and system is using DMA bounce buffers [ 61.076954] aacraid: Comm Interface type2 enabled Nothing else happens for minutes. Attached devices are unavailable. "arcconf" find no controller. "rmmod aacraid" doesn't work (device in use). Running kernel 4.16.14 with the 8 TB array is exactly the same: [ 40.380488] Adaptec aacraid driver 1.2.1[50877]-custom [ 40.380871] aacraid :21:00.0: SME is active, device will require DMA bounce buffers [ 40.388991] SME is active and system is using DMA bounce buffers [ 40.388995] aacraid: Comm Interface type2 enabled In contrast, kernel 4.13, though the driver version is the same as 4.14, just works: [ 25.286437] Adaptec aacraid driver 1.2.1[50834]-custom [ 25.293694] aacraid: Comm Interface type2 enabled [ 25.300799] AAC0: kernel 7.13-0[33263] Mar 16 2018 [ 25.300801] AAC0: monitor 7.13-0[33263] [ 25.300802] AAC0: bios 7.13-0[33263] [ 25.300804] AAC0: serial 6A46639462D [ 25.300804] AAC0: Non-DASD support enabled. [ 25.300805] AAC0: 64bit support enabled. [ 25.300807] aacraid :21:00.0: 64 Bit DAC enabled ... [ 27.307013] scsi host16: aacraid [ 27.307228] scsi 16:0:0:0: Direct-Access ASR8805 LogicalDrv 0 V1.0 PQ: 0 ANSI: 2 [ 27.307364] sd 16:0:0:0: [sdm] Very big device. Trying to use READ CAPACITY(16). [ 27.307376] sd 16:0:0:0: [sdm] 11714670592 512-byte logical blocks: (6.00 TB/5.45 TiB) [ 27.307385] sd 16:0:0:0: [sdm] Write Protect is off [ 27.307386] sd 16:0:0:0: [sdm] Mode Sense: 12 00 10 08 [ 27.307403] sd 16:0:0:0: [sdm] Write cache: disabled, read cache: enabled, supports DPO and FUA [ 27.307411] sd 16:0:0:0: Attached scsi generic sg12 type 0 [ 27.307507] sd 16:0:0:0: [sdm] Very big device. Trying to use READ CAPACITY(16). [ 27.307830] sd 16:0:0:0: [sdm] Very big device. Trying to use READ CAPACITY(16). [ 27.307855] sd 16:0:0:0: [sdm] Attached SCSI removable disk [ 27.332731] scsi 16:1:0:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 27.355431] scsi 16:1:0:0: Attached scsi generic sg13 type 0 [ 27.355830] scsi 16:1:1:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 27.385377] scsi 16:1:1:0: Attached scsi generic sg14 type 0 [ 27.385788] scsi 16:1:2:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 27.413412] scsi 16:1:2:0: Attached scsi generic sg15 type 0 [ 27.413813] scsi 16:1:3:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 27.437420] scsi 16:1:3:0: Attached scsi generic sg16 type 0 [ 27.437836] scsi 16:1:4:0: Direct-Access ATA WDC WD10TPVT-00H 1A01 PQ: 1 ANSI: 6 [ 27.636675] scsi 16:1:4:0: Attached scsi generic sg17 type 0 [ 27.637077] scsi 16:1:5:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 27.664591] scsi 16:1:5:0: Attached scsi generic sg18 type 0 [ 27.664996] scsi 16:1:6:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 27.697619] scsi 16:1:6:0: Attached scsi generic sg19 type 0 [ 27.698027] scsi 16:1:7:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 27.732645] scsi 16:1:7:0: Attached scsi generic sg20 type 0 -- -------- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgpljfhS_hxGN.pgp Description: Signature digitale OpenPGP
Re: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work
Le Wed, 27 Jun 2018 18:48:56 + Dave Carroll écrivait: > > Is this size consistent with the 4.13 kernel? That size is greater > > than the 64-bit LBA addressing (0x93 539F B000). > > Sorry, that comment was incorrect, but I would like to see if the > size is consistent between the kernels. After a very long time, it finally boots up and sees the disks, but here's the output from dmesg | grep aacraid: [1.357760] Adaptec aacraid driver 1.2.1[50877]-custom [1.388119] aacraid: Comm Interface type2 enabled [3.405113] scsi host0: aacraid [ 50.156024] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,0,0): [ 50.156126] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,0,0): [ 50.172032] aacraid: Host adapter reset request. SCSI hang ? [ 65.536106] aacraid: Host adapter reset request. SCSI hang ? [ 65.536204] aacraid :01:00.0: outstanding cmd: midlevel-0 [ 65.536206] aacraid :01:00.0: outstanding cmd: lowlevel-0 [ 65.536207] aacraid :01:00.0: outstanding cmd: error handler-0 [ 65.536208] aacraid :01:00.0: outstanding cmd: firmware-2 [ 65.536210] aacraid :01:00.0: outstanding cmd: kernel-0 [ 65.536228] aacraid :01:00.0: Controller reset type is 3 [ 65.536314] aacraid :01:00.0: Issuing IOP reset [ 98.675617] aacraid :01:00.0: IOP reset succeded [ 98.684161] aacraid: Comm Interface type2 enabled [ 110.015352] aacraid :01:00.0: Scheduling bus rescan [ 166.896116] aacraid: Host adapter reset request. SCSI hang ? [ 166.896214] aacraid :01:00.0: outstanding cmd: midlevel-0 [ 166.896216] aacraid :01:00.0: outstanding cmd: lowlevel-0 [ 166.896217] aacraid :01:00.0: outstanding cmd: error handler-0 [ 166.896218] aacraid :01:00.0: outstanding cmd: firmware-2 [ 166.896220] aacraid :01:00.0: outstanding cmd: kernel-0 [ 166.896236] aacraid :01:00.0: Controller reset type is 3 [ 166.896322] aacraid :01:00.0: Issuing IOP reset [ 198.858466] aacraid :01:00.0: IOP reset succeded [ 198.870660] aacraid: Comm Interface type2 enabled [ 211.129896] aacraid :01:00.0: Scheduling bus rescan [ 228.844034] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,0,0): [ 266.835610] aacraid: Host adapter reset request. SCSI hang ? [ 266.837891] aacraid :01:00.0: outstanding cmd: midlevel-0 [ 266.837894] aacraid :01:00.0: outstanding cmd: lowlevel-0 [ 266.837897] aacraid :01:00.0: outstanding cmd: error handler-0 [ 266.837899] aacraid :01:00.0: outstanding cmd: firmware-2 [ 266.837902] aacraid :01:00.0: outstanding cmd: kernel-0 [ 266.837939] aacraid :01:00.0: Controller reset type is 3 [ 266.840415] aacraid :01:00.0: Issuing IOP reset [ 299.846642] aacraid :01:00.0: IOP reset succeded [ 299.858811] aacraid: Comm Interface type2 enabled [ 312.098221] aacraid :01:00.0: Scheduling bus rescan [ 367.869277] aacraid: Host adapter reset request. SCSI hang ? [ 367.871382] aacraid :01:00.0: outstanding cmd: midlevel-0 [ 367.871385] aacraid :01:00.0: outstanding cmd: lowlevel-0 [ 367.871387] aacraid :01:00.0: outstanding cmd: error handler-0 [ 367.871389] aacraid :01:00.0: outstanding cmd: firmware-2 [ 367.871391] aacraid :01:00.0: outstanding cmd: kernel-0 [ 367.871480] aacraid :01:00.0: Controller reset type is 3 [ 367.873982] aacraid :01:00.0: Issuing IOP reset [ 400.765513] aacraid :01:00.0: IOP reset succeded [ 400.776673] aacraid: Comm Interface type2 enabled [ 413.036505] aacraid :01:00.0: Scheduling bus rescan [ 468.995678] aacraid: Host adapter reset request. SCSI hang ? [ 468.995700] aacraid :01:00.0: outstanding cmd: midlevel-0 [ 468.995704] aacraid :01:00.0: outstanding cmd: lowlevel-0 [ 468.995706] aacraid :01:00.0: outstanding cmd: error handler-0 [ 468.995709] aacraid :01:00.0: outstanding cmd: firmware-2 [ 468.995711] aacraid :01:00.0: outstanding cmd: kernel-0 [ 468.995740] aacraid :01:00.0: Controller reset type is 3 [ 468.995745] aacraid :01:00.0: Issuing IOP reset [ 501.875537] aacraid :01:00.0: IOP reset succeded [ 501.887288] aacraid: Comm Interface type2 enabled [ 514.148609] aacraid :01:00.0: Scheduling bus rescan The RAID controller is unusable, obviously. Rebooting with 4.13, now... -- ---- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgpiO9bja167Q.pgp Description: Signature digitale OpenPGP
Re: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work
Le Wed, 27 Jun 2018 18:48:56 + Dave Carroll écrivait: > Sorry, that comment was incorrect, but I would like to see if the > size is consistent between the kernels. > I just booted the 4.16 from Debian testing, same problem, so this is not an artefact of my custom compilation: aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,0,0): aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,0,0): aacraid: Host adapter abort request. aacraid: Host adapter reset request. SCSI hang ? The very same adapter connected to the very same disks works perfectly fine with a 4.13 kernel, and not at all with 4.14, 4.15, 4.16. I didn't test 4.17 yet but... -- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgptqiB2zA2MO.pgp Description: Signature digitale OpenPGP
Re: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work
Le Wed, 27 Jun 2018 18:48:56 + Dave Carroll écrivait: > Sorry, that comment was incorrect, but I would like to see if the > size is consistent between the kernels. > Yes it is. The only difference is the driver version going from 50834 to 50877. The problem occurs on different setups, using different RAID controllers, etc. As I mentioned it works with an ASR7xx5 up to 4.14, but with 4.16 both 8xx5 and 7xx5 controllers don't work. [5.762727] Adaptec aacraid driver 1.2.1[50834]-custom [5.768147] aacraid: Comm Interface type2 enabled [5.775262] AAC0: kernel 7.13-0[33263] Mar 16 2018 [5.775264] AAC0: monitor 7.13-0[33263] [5.775265] AAC0: bios 7.13-0[33263] [5.775267] AAC0: serial 6A476396945 [5.775268] AAC0: Non-DASD support enabled. [7.782209] scsi host6: aacraid [7.782629] scsi 6:0:2:0: Direct-Access ASR8885 raid3V1.0 PQ: 0 ANSI: 2 [7.782735] sd 6:0:2:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [7.782743] sd 6:0:2:0: [sdb] 632763166720 512-byte logical blocks: (324 TB/295 TiB) [7.782751] sd 6:0:2:0: [sdb] Write Protect is off [7.782752] sd 6:0:2:0: [sdb] Mode Sense: 12 00 10 08 [7.782764] sd 6:0:2:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA [7.782832] sd 6:0:2:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [7.808366] scsi 6:1:105:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.809387] scsi 6:1:106:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.810895] scsi 6:1:107:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.811889] scsi 6:1:108:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.812131] sd 6:0:2:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [7.812156] sd 6:0:2:0: [sdb] Attached SCSI removable disk [7.812884] scsi 6:1:109:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.813886] scsi 6:1:110:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.814861] scsi 6:1:111:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.815994] scsi 6:1:112:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.817001] scsi 6:1:113:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.818019] scsi 6:1:114:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.819004] scsi 6:1:115:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.820103] scsi 6:1:116:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.821087] scsi 6:1:117:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.822065] scsi 6:1:118:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.824714] scsi 6:1:119:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.825785] scsi 6:1:120:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.826830] scsi 6:1:121:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.829031] scsi 6:1:122:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.830013] scsi 6:1:123:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.831022] scsi 6:1:124:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.832033] scsi 6:1:125:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.833098] scsi 6:1:126:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.834078] scsi 6:1:127:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.835077] scsi 6:1:128:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.836046] scsi 6:1:129:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.837025] scsi 6:1:130:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.838002] scsi 6:1:131:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.838984] scsi 6:1:132:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.839965] scsi 6:1:133:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.840939] scsi 6:1:134:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 -- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgpEXUp9KUvpv.pgp Description: Signature digitale OpenPGP
Re: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work
Le Wed, 27 Jun 2018 18:20:27 +0200 Emmanuel Florac écrivait: > As per my previous post, I've determined that the aacraid driver > doesn't work with current Adaptec RAID controllers (ASR8xxx family, > latest firmware) with kernels over 4.14. Kernel up to 4.15 works with > ASR7xxx family but kernel 4.16 doesn't work either with ASR7xxx nor > ASR8xxx controllers. > > I've just retried running the latest 4.16.18 (plain vanilla) on Debian > stable: > > Running "modprobe aacraid", the driver hangs and resets the controller > constantly. rebooting the system on earlier kernels up to 4.13.xx > everything *just works* without any problem. dmesg output: > > [ 344.845719] Adaptec aacraid driver 1.2.1[50877]-custom > [ 344.852250] aacraid: Comm Interface type2 enabled > [ 344.859381] AAC0: kernel 7.13-0[33263] Mar 16 2018 > [ 344.859384] AAC0: monitor 7.13-0[33263] > [ 344.859385] AAC0: bios 7.13-0[33263] > [ 344.859388] AAC0: serial 6A476396945 > [ 344.859389] AAC0: Non-DASD support enabled. > [ 346.869001] scsi host6: aacraid > [ 346.869500] scsi 6:0:2:0: Direct-Access ASR8885 For comparison, here's the output booting 4.13.16 (the highest working release) on the same system ; driver version is slightly different: [5.762727] Adaptec aacraid driver 1.2.1[50834]-custom [5.768147] aacraid: Comm Interface type2 enabled [5.775262] AAC0: kernel 7.13-0[33263] Mar 16 2018 [5.775264] AAC0: monitor 7.13-0[33263] [5.775265] AAC0: bios 7.13-0[33263] [5.775267] AAC0: serial 6A476396945 [5.775268] AAC0: Non-DASD support enabled. [7.782209] scsi host6: aacraid [7.782629] scsi 6:0:2:0: Direct-Access ASR8885 raid3V1.0 PQ: 0 ANSI: 2 [7.782735] sd 6:0:2:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [7.782743] sd 6:0:2:0: [sdb] 632763166720 512-byte logical blocks: (324 TB/295 TiB) [7.782751] sd 6:0:2:0: [sdb] Write Protect is off [7.782752] sd 6:0:2:0: [sdb] Mode Sense: 12 00 10 08 [7.782764] sd 6:0:2:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA [7.782832] sd 6:0:2:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [7.808366] scsi 6:1:105:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.809387] scsi 6:1:106:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.810895] scsi 6:1:107:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.811889] scsi 6:1:108:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.812131] sd 6:0:2:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [7.812156] sd 6:0:2:0: [sdb] Attached SCSI removable disk [7.812884] scsi 6:1:109:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.813886] scsi 6:1:110:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.814861] scsi 6:1:111:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.815994] scsi 6:1:112:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.817001] scsi 6:1:113:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.818019] scsi 6:1:114:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.819004] scsi 6:1:115:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.820103] scsi 6:1:116:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.821087] scsi 6:1:117:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.822065] scsi 6:1:118:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.824714] scsi 6:1:119:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.825785] scsi 6:1:120:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.826830] scsi 6:1:121:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.829031] scsi 6:1:122:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.830013] scsi 6:1:123:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.831022] scsi 6:1:124:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.832033] scsi 6:1:125:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.833098] scsi 6:1:126:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.834078] scsi 6:1:127:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.835077] scsi 6:1:128:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.836046] scsi 6:1:129:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.837025] scsi 6:1:130:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.838002] scsi 6:1:131:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.838984] scsi 6:1:132:0: Direct-
aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work
8.740878] aacraid: Comm Interface type2 enabled [ 662.210562] aacraid :01:00.0: Scheduling bus rescan [ 717.858005] aacraid: Host adapter reset request. SCSI hang ? [ 717.858018] aacraid :01:00.0: outstanding cmd: midlevel-0 [ 717.858020] aacraid :01:00.0: outstanding cmd: lowlevel-0 [ 717.858021] aacraid :01:00.0: outstanding cmd: error handler-0 [ 717.858022] aacraid :01:00.0: outstanding cmd: firmware-1 [ 717.858024] aacraid :01:00.0: outstanding cmd: kernel-0 [ 717.858041] aacraid :01:00.0: Controller reset type is 3 [ 717.858042] aacraid :01:00.0: Issuing IOP reset [ 751.089104] aacraid :01:00.0: IOP reset succeded [ 751.100998] aacraid: Comm Interface type2 enabled [ 764.620214] aacraid :01:00.0: Scheduling bus rescan [ 820.268834] aacraid: Host adapter reset request. SCSI hang ? [ 820.268845] aacraid :01:00.0: outstanding cmd: midlevel-0 [ 820.268847] aacraid :01:00.0: outstanding cmd: lowlevel-0 [ 820.268848] aacraid :01:00.0: outstanding cmd: error handler-0 [ 820.268850] aacraid :01:00.0: outstanding cmd: firmware-1 [ 820.268851] aacraid :01:00.0: outstanding cmd: kernel-0 [ 820.268869] aacraid :01:00.0: Controller reset type is 3 [ 820.268870] aacraid :01:00.0: Issuing IOP reset [ 890.510493] aacraid :01:00.0: IOP reset failed [ 890.510497] aacraid :01:00.0: ARC Reset attempt failed -- -------- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgpY19tjFahOM.pgp Description: Signature digitale OpenPGP
aacraid woes with kernel 4.14.48 to 4.16.14
ached SCSI removable disk [ 13.221263] random: fast init done [ 13.280269] scsi 16:1:0:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 13.306349] scsi 16:1:1:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 13.337330] scsi 16:1:2:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 13.380291] scsi 16:1:3:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 13.518301] scsi 16:1:4:0: Direct-Access ATA WDC WD10TPVT-00H 1A01 PQ: 1 ANSI: 6 [ 13.728354] scsi 16:1:5:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 13.756322] scsi 16:1:6:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 [ 13.791346] scsi 16:1:7:0: Direct-Access ATA WDC WD10TPVT-00U 1A01 PQ: 1 ANSI: 6 Apparently the problem may lie in the "SME" and "bounce buffers", however I don't know for sure if the SME and bounce buffers (whatever they are) were disabled in 4.13 and prior kernels, or if it's simply the warning that was enabled at some point. Now to the older machine, little RAM, older RAID controller the situation is slightly different: 4.14.48 and 4.15.18 run both fine: [6.066699] Adaptec aacraid driver 1.2.1[50834]-custom [6.067097] aacraid: Comm Interface type2 enabled [6.085979] AAC0: kernel 7.5-0[32118] Mar 31 2018 [6.085981] AAC0: monitor 7.5-0[32118] [6.085982] AAC0: bios 7.5-0[32118] [6.085984] AAC0: serial 5C1113B8ADE [6.085985] AAC0: Non-DASD support enabled. [6.089604] random: fast init done [6.099792] scsi host6: aacraid [6.100034] scsi 6:0:0:0: Direct-Access ASR7805 yrdy V1.0 PQ: 0 ANSI: 2 [6.100261] sd 6:0:0:0: [sda] 3900682240 512-byte logical blocks: (2.00 TB/1.82 TiB) [6.100276] sd 6:0:0:0: [sda] Write Protect is off [6.100278] sd 6:0:0:0: [sda] Mode Sense: 12 00 10 08 [6.100296] sd 6:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA [6.123005] scsi 6:1:4:0: Direct-Access ATA Hitachi HDS72302 MN6O PQ: 1 ANSI: 6 [6.125896] sd 6:0:0:0: [sda] Attached SCSI removable disk However with 4.16.14 the controller hangs and resets constantly: [ 78.830864] aacraid: Host adapter abort request. aacraid: Outstanding commands on (6,0,0,0): [ 78.835871] aacraid: Host adapter reset request. SCSI hang ? [ 94.181485] aacraid: Host adapter reset request. SCSI hang ? [ 94.181493] aacraid :01:00.0: outstanding cmd: midlevel-0 [ 94.181494] aacraid :01:00.0: outstanding cmd: lowlevel-0 [ 94.181495] aacraid :01:00.0: outstanding cmd: error handler-0 [ 94.181497] aacraid :01:00.0: outstanding cmd: firmware-1 [ 94.181498] aacraid :01:00.0: outstanding cmd: kernel-0 [ 94.181514] aacraid :01:00.0: Controller reset type is 3 [ 94.181515] aacraid :01:00.0: Issuing IOP reset [ 120.593352] aacraid :01:00.0: IOP reset succeded [ 120.605025] aacraid: Comm Interface type2 enabled [ 121.660829] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 121.660976] NFSD: starting 90-second grace period (net f099) [ 128.984735] mgag200 :08:04.0: Video card doesn't support cursors with partial transparency. [ 128.984738] mgag200 :08:04.0: Not enabling hardware cursor. [ 133.824432] aacraid :01:00.0: Scheduling bus rescan [ 193.523141] aacraid: Host adapter reset request. SCSI hang ? [ 193.523150] aacraid :01:00.0: outstanding cmd: midlevel-0 [ 193.523152] aacraid :01:00.0: outstanding cmd: lowlevel-0 [ 193.523153] aacraid :01:00.0: outstanding cmd: error handler-0 [ 193.523154] aacraid :01:00.0: outstanding cmd: firmware-1 [ 193.523155] aacraid :01:00.0: outstanding cmd: kernel-0 [ 193.523178] aacraid :01:00.0: Controller reset type is 3 [ 193.523179] aacraid :01:00.0: Issuing IOP reset [ 219.910222] aacraid :01:00.0: IOP reset succeded [ 219.915742] aacraid: Comm Interface type2 enabled [ 233.140378] aacraid :01:00.0: Scheduling bus rescan [ 246.771302] INFO: task kworker/u24:3:79 blocked for more than 120 seconds. -- ---- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgp9mM3qR17Qj.pgp Description: Signature digitale OpenPGP
Re: SAS disk from RAID card (no RAID mode) problems
Le Tue, 27 Dec 2016 09:01:34 +0100 IW News <n...@imagedworld.com> écrivait: > Hi, > > So there is no support for the mvsas driver? > > The controller is integrated in the motherboard. I could by a PCIe one > but, what's the deal them? You didn't even say what's the SSD drive model. Maybe the drive is faulty? The cabling? -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 pgp7MUQlTXPi7.pgp Description: Signature digitale OpenPGP
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Le Thu, 4 Feb 2016 19:54:55 +0200 "Kai Mäkisara (Kolumbus)" <kai.makis...@kolumbus.fi> écrivait: > > Tested with patched kernel 4.5.0-rc2-next-20160202+. It's looking > > good everything partition related passed with DDS5 and LTO6. You > > can definitely add me as a tested-by. I did find one issue below > > but it's not related to the partitioning changes. > Thanks for testing. It would be interesting to get confirmation from > a LTO-5 user that partitioning works. Even without that I will make > the final patch within a few days (remove some debugging and update > the documentation). I currently have one IBM LTO-4, one HP LTO-5 and one HP LTO-6 drives. I'll try to run some tests tomorrow. -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Le Thu, 28 Jan 2016 19:31:10 +0200 "Kai Mäkisara (Kolumbus)" <kai.makis...@kolumbus.fi> écrivait: > > On 27.1.2016, at 1.35, Seymour, Shane M <shane.seym...@hpe.com> > > wrote: > > > > 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 format archives with a standard block size of 10k can take > > this much data to get to 2^32 blocks and cause the current 32bit > > block number to wrap: > > > > 43,980,465,111,040 (2^32 * 10240) > > > This is a somewhat theoretic example. In the 1990s no reasonable > person used block size below 32 kB. Now the limit is probably higher. > But, eventually we have to enlarge the block position and count > variables. You'd be surprised. In fact current LTO drive performance maxes out between 32k and 256k. Most people would use 64k. Default for LTFS is 512k. Many, many people just use tar with the default block size, not knowing any better (yay, shoeshine). > > That's probably the correct time to also look at adding support for > > more partitions. Not sure when the extended block id form of READ > > POSITION got added but it may mean only supporting the wider values > > only with tape drives that support REPORT SUPPORTED OPCODES (if > > that can indicate that it supports READ POSITION with extended > > block ids and anything else required to support block numbers > > larger than 2^32). > The current driver supports using up to ST_NBR_PARTITIONS (in the > source set to 4). Support for using partitions must be in the driver. > I am still not sure if partitioning the tape should be in the driver. As a "normal" user, I pretty much don't want to ever have to look at these atrocious SCSI reference docs :) So I'm all for as many things as possible to be exposed through the driver instead. I'm pretty confident that I'm expressing the ordinary developer/admin point of view here :) > > The 0x91 version of SPACE needs to be used as well (the 32bit > > version 0x11 Is currently used) to allow tape movement with counts > > >2^32. That requires a new ioctl call. I haven't looked at what > > >else may need to change but there's > > likely to be more. The alternate version of SPACE is from page 220 > > of the above HP LTO5 tape reference. > > > The first step is to make the internal counters 64 bits. Then the > code should be changed so that it can handle the large addresses. > Note that this is necessary for handling partition changes even if no > positioning commands are exposed to the user. The last step is to > introduce the new positioning methods. > > The new positioning methods should perhaps be defined so that both > the partition number and the block number are specified together. A > proper tape address needs both. > Sounds good. > But I think we should first fix the existing partitioning command so > that it works for current drives. Definitely :) -- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Le Sun, 24 Jan 2016 23:05:17 +0200 (EET) Kai Makisara <kai.makis...@kolumbus.fi> écrivait: > Below is a test patch that implements the current behaviour with > non-negative argument (but works with LTOs etc.) and makes partition > zero size absolute value of argument (MB) if argument is negative. If > you want to test the patch, note that the current mt-st does not > accept negative numbers. A minimal patch is needed. OK I'm going to try this one. -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Ooops, fat finger posting before I've finished answering... Le Fri, 22 Jan 2016 02:10:03 + "Seymour, Shane M" <shane.seym...@hpe.com> écrivait: > > > > There seem to be lot of arguments supporting both possible choices. > > Should we use the existing definition (1) or change it for the > > drives supporting SCSI level >= 3 (or supporting FORMAT MEDIUM)? > > The definition can’t be changed later. This is why we should make a > > good decision. > > > > Opinions? > > How about using the fact the size is signed to indicate one slightly > different thing? I'm not sure if you'd call this using or abusing the > fact that it's signed. > I find the idea of using negative number as "interesting". I'm afraid of what will happen as tape size grows? Don't we risk overflowing at some point, and ending with very unexpected results? 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 :) I have a different proposition: what about adding a new ioctl named MTMKADVPART that takes a struct to define many different partitions at once? So that we'd be able to create 2 partitions with the existing MTMKPART, and also create several partitions for newer drives? Added bonus a corresponding ioctl to read the media configuration as specified in mode sense page 11h (see LTO SCSI reference) and present it back so that we could know how the tape is actually partitioned :) -- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Le Fri, 22 Jan 2016 02:10:03 + "Seymour, Shane M" <shane.seym...@hpe.com> écrivait: > > However, before making the final patch, we should decide which > > partition the specified size should apply to. For the SCSI level > > <=2 it applies to partition 1. For other drives we may have some > > freedom to “tune” the definition. The size should apply to the > > partition the users expect it to apply. > > I'd argue for consistency here in the current interface and that it > should apply in the same way more on that below. I agree, it would be extremely surprising (in a bad way) to see your application behave differently when upgrading your drive, for instance. > > Partitioning with two partitions is used for storing index in a > > small partition and use the rest of the tape for data. In this > > case, it is probably natural to specify the size of the index. The > > LTFS definition supports index in any partition. The open source > > code I have seen seem to default to index in partition 0. > > > > The HP and IBM LTO default partitioning (FDP=1) specifies two wraps > > (minimum) to partition 1 and the rest to 0. LTFS 2.2 specifications doesn't explicitly number partitions, however it makes it clear that the "index" partition (the smaller one) must come first. Furthermore, all LTFS tapes I've had a look at have partition 0 as index. Add to this the fact that current LTO-7 tapes are 6 TB. That comes to pretty big numbers when you want to size a partition in MB. > 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 > is rounded up to the size of a wrap as well. > > See > https://docs.oracle.com/cd/E21419_04/en/LTO5_Vol3_E5b/LTO5_Vol3_E5b.pdf > > Page 100 where it gives examples of how partition sizes are > calculated on HP LTO5 drives. > Ican confirm this from the tests I've made on LTO-5 and LTO-6. The size of the partition you'll obtain may end quite different from the size you've asked for. This is made particularly difficult when you must convert a few TB to MB, and you don't know exactly where it'll > > > > There seem to be lot of arguments supporting both possible choices. > > Should we use the existing definition (1) or change it for the > > drives supporting SCSI level >= 3 (or supporting FORMAT MEDIUM)? > > The definition can’t be changed later. This is why we should make a > > good decision. > > > > Opinions? > > How about using the fact the size is signed to indicate one slightly > different thing? I'm not sure if you'd call this using or abusing the > fact that it's signed. > > Make the default behavior for a positive size the same as the current > behavior for SCSI-2 (size applies to partition 1). If the size is > negative then the absolute value of the size applies to partition 0. > That provides some flexibility in choosing which partition the size > applies to if it worked that way for all devices. > > With that you also get consistent behavior between tape drives without > having to know if the size will apply to partition 0 or partition 1 > based on the tape technology and you get the benefit of being able to > set an explicit size for partition 0 or partition 1. > > You could overload the value of 0 as well to use FDP to choose the > sizes for the partitions (assuming 0 doesn't already have a side > effect in the code). Then you get whatever the tape drive wants to do. -- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Wed, 6 Jan 2016 10:23:34 -0500 (EST) Laurence Oberman <lober...@redhat.com> écrivait: > MaxPartitions: 0 > > Drive is working fine, > > # mt -f /dev/st0 status > SCSI 2 tape drive: > File number=0, block number=0, partition=0. > Tape block size 512 bytes. Density code 0x58 (no translation). > Soft error count since last status=0 > General status bits on (4101): > BOT ONLINE IM_REP_EN > > This is what I get when I try and partition and I believe this may be > a firmware issue for me. Yes probably, it reports "MaxPartitions 0", should be 1 for an LTO-5 drive. Weird. -- -------- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Wed, 6 Jan 2016 17:10:15 +0100 Emmanuel Florac <eflo...@intellique.com> écrivait: > Works OK with LTO-5 (HP). Sizing the partitions is quite difficult, as > you can see. To get one "wrap" in the first partition, "140" and > "1424000" work, but "145" doesn't. Same for LTO-6 (I'm still > looking for the proper size). > Looks like the proper size for a "one wrap" 38 GB partition 0 on LTO-6 is "245". Go figure. -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Mon, 4 Jan 2016 12:46:26 +0100 Emmanuel Florac <eflo...@intellique.com> écrivait: > That works fine for me. I'm going to do some testing with other drives > I have (LTO-3 -- should fail -- and LTO-5). > Works OK with LTO-5 (HP). Sizing the partitions is quite difficult, as you can see. To get one "wrap" in the first partition, "140" and "1424000" work, but "145" doesn't. Same for LTO-6 (I'm still looking for the proper size). # mt -f /dev/st0 mkpartition 1 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Updating partition number in status. Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Got tape pos. blk 0 part 0. Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Loading tape. Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Partition page length is 12 bytes. Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 0, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 1529 0 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 00 3c 03 09 00 05 f9 00 00 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: psd_cnt 2, max.parts 1, nbr_parts 0 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Formatting tape with two partitions (FDP). Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 4, psum 03, pofmetc 4, rec 03, units 00, sizes: 65535 0 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 9c 03 00 00 ff ff 00 00 Jan 6 16:38:42 taiko kernel: st 6:0:0:0: st0: Sending FORMAT MEDIUM Jan 6 16:38:56 taiko kernel: st 6:0:0:0: st0: Rewinding tape. # tapeinfo -f /dev/sg1 Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'Ultrium 5-SCSI ' Revision: 'Z61U' Attached Changer API: No SerialNumber: 'HU1249TP88' MinBlock: 1 MaxBlock: 16777215 SCSI ID: 0 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: Not Loaded Density Code: 0x58 BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0x1 DeCompType: 0x1 BOP: yes Block Position: 0 Partition 0 Remaining Kbytes: 1459056 Partition 0 Size in Kbytes: 1459056 ActivePartition: 0 EarlyWarningSize: 0 NumPartitions: 1 MaxPartitions: 1 Partition0: 1453 Partition1: 38 # mt -f /dev/st0 setpartition 1 Jan 6 16:40:20 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 6 16:40:20 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 6 16:40:20 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1 Jan 6 16:40:20 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 6 16:40:20 taiko kernel: st 6:0:0:0: st0: Setting block to 0 and partition to 1. Jan 6 16:40:20 taiko kernel: st 6:0:0:0: st0: Got tape pos. blk 0 part 0. Jan 6 16:40:20 taiko kernel: st 6:0:0:0: st0: Visited block 0 for partition 0 saved. Jan 6 16:40:20 taiko kernel: st 6:0:0:0: st0: Trying to change partition from 0 to 1 Jan 6 16:40:25 taiko kernel: st 6:0:0:0: st0: Rewinding tape. # mt -f /dev/st0 mkpartition 1453 Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1 Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Loading tape. Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1 Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: Partition page length is 12 bytes. Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: PP: max 1, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 1453 38 Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: MP: 11 0a 01 01 3c 03 09 00 05 ad 00 26 Jan 6 16:42:22 taiko kernel: st 6:0:0:0: st0: psd_cnt 2, max.parts 1, nbr_parts 1 Jan 6
Re: st driver doesn't seem to grok LTO partitioning
Le Tue, 5 Jan 2016 16:55:04 -0500 (EST) Laurence Oberman <lober...@redhat.com> écrivait: > mt -f /dev/nst0 mkpartition 1 > What is the type of drive exactly? I still couldn't test with the LTO-5 drive as the machine it's connected to is being reinstalled. -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Mon, 4 Jan 2016 12:22:34 +0200 (EET) Kai Makisara <kai.makis...@kolumbus.fi> écrivait: > The patch has been tested with my DDS-4 drive. Oh BTW, may be you could correct this one while you're at it :) I don't think my kernel is so old... :) ~# mt -f /dev/st0 stshowopt Your kernel (3.18.25) may be too old for this command. The options set: buffer-writes async-writes read-ahead debug can-bsr can-partitions -- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Mon, 4 Jan 2016 12:22:34 +0200 (EET) Kai Makisara <kai.makis...@kolumbus.fi> écrivait: > >In the HP LTFS sources I found an interesting detail: the code does > >LOAD before unformatting. A comment says that it is in some cases > >better method to put the position to beginning of partition 0 than > >other methods. You could try ‘mt load’ before trying to partition. > > > Here is again a new version of the patch. This does load before > partitioning. The code performing default partitioning (FDP=1) has > also been slightly modified (two more bits of the original mode page > retained). OK, I'll test 'mt load' first, then the new patch. Stay tuned... -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Mon, 4 Jan 2016 12:22:34 +0200 (EET) Kai Makisara <kai.makis...@kolumbus.fi> écrivait: > >In the HP LTFS sources I found an interesting detail: the code does > >LOAD before unformatting. A comment says that it is in some cases > >better method to put the position to beginning of partition 0 than > >other methods. You could try ‘mt load’ before trying to partition. > > > Here is again a new version of the patch. This does load before > partitioning. The code performing default partitioning (FDP=1) has > also been slightly modified (two more bits of the original mode page > retained). You were right, it works by sending a "LOAD" first: First, not working: # mt -f /dev/nst0 mkpartition 0 Jan 4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Jan 4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape. Jan 4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes. Jan 4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38 Jan 4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM Jan 4 12:02:17 shakuhachi kernel: st 7:0:0:0: st0: Error: 802, cmd: 4 0 0 0 0 0 Jan 4 12:02:17 shakuhachi kernel: st0: Sense Key : Illegal Request [current] Jan 4 12:02:17 shakuhachi kernel: st0: Add. Sense: Position past beginning of medium Then: # mt -f /dev/nst0 load Jan 4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Jan 4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Loading tape. Jan 4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Jan 4 12:02:33 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). # mt -f /dev/nst0 mkpartition 0 Jan 4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Jan 4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape. Jan 4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes. Jan 4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38 Jan 4 12:02:42 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM # tapeinfo -f /dev/sg6 Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'Ultrium 6-SCSI ' Revision: '329U' Attached Changer API: No SerialNumber: 'HU1302U4RC' MinBlock: 1 MaxBlock: 16777215 SCSI ID: 0 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: Not Loaded Density Code: 0x5a BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0x1 DeCompType: 0x1 BOP: yes Block Position: 0 ActivePartition: 0 EarlyWarningSize: 0 NumPartitions: 0 MaxPartitions: 3 -- -------- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
hachi kernel: st 7:0:0:0: st0: Formatting tape with two partitions (FDP). Jan 4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1 Jan 4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 4, psum 03, pofmetc 4, rec 03, units 00, sizes: 65535 0 Jan 4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: MP: 11 0a 03 01 9c 03 00 00 ff ff 00 00 Jan 4 12:40:01 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM # mt -f /dev/nst0 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 0 bytes. Density code 0x5a (no translation). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN Jan 4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Jan 4 12:40:28 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). # mt -f /dev/nst0 setpartition 1 # mt -f /dev/nst0 status SCSI 2 tape drive: File number=0, block number=0, partition=1. Tape block size 0 bytes. Density code 0x5a (no translation). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN # mt -f /dev/nst0 mkpartition 0 Jan 4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Jan 4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 4 12:42:15 shakuhachi kernel: st 7:0:0:0: st0: Loading tape. Jan 4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Jan 4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Jan 4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Jan 4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes. Jan 4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38 Jan 4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: MP: 11 0e 03 01 3c 03 09 00 09 ef 00 26 Jan 4 12:42:18 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM # tapeinfo -f /dev/sg6 Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'Ultrium 6-SCSI ' Revision: '329U' Attached Changer API: No SerialNumber: 'HU1302U4RC' MinBlock: 1 MaxBlock: 16777215 SCSI ID: 0 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: Not Loaded Density Code: 0x5a BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0x1 DeCompType: 0x1 BOP: yes Block Position: 0 ActivePartition: 0 EarlyWarningSize: 0 NumPartitions: 0 MaxPartitions: 3 -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Mon, 4 Jan 2016 10:08:44 -0500 Laurence Oberman <oberma...@gmail.com> écrivait: > I am back at work with access to my tape changer today. Will pull the > patches and help test as well. > I assume I need to apply both patches, the earlier one and this > latest one. > No only the latest one. -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Wed, 30 Dec 2015 19:54:01 +0200 (EET) Kai Makisara <kai.makis...@kolumbus.fi> écrivait: > I think I found out why it did not work with the default format. At > the end of this message you find a new patch that should correct > that. There are also other changes: > - some changes when specifying the size in the mode page; needed for > the IBM 3592 drives but should not change results with LTO > - formatting with one partition is done directly with FORMAT MEDIUM if > the drive requires that command > - some other bugs fixed Hum, I can't seem to be able to go back to 1 partition, or to reformat the tape (didn't change it since yesterday), am I missing something? Dec 30 19:21:29 shakuhachi kernel: st: Version 20151230, fixed bufsize 32768, s/g segs 256 Dec 30 19:21:29 shakuhachi kernel: st 7:0:0:0: Attached scsi tape st0 Dec 30 19:21:29 shakuhachi kernel: st 7:0:0:0: st0: try direct i/o: yes (alignment 512 B) ~# mt -f /dev/nst0 mkpartition 0 Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape. Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes. Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38 Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM Dec 30 19:24:41 shakuhachi kernel: st 7:0:0:0: st0: Error: 802, cmd: 4 0 0 0 0 0 Dec 30 19:24:41 shakuhachi kernel: st0: Sense Key : Illegal Request [current] Dec 30 19:24:41 shakuhachi kernel: st0: Add. Sense: Position past beginning of medium ~# mt -f /dev/nst0 mkpartition 1 Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape. Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes. Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38 Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: psd_cnt 2, max.parts 3, nbr_parts 1 Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Formatting tape with two partitions (FDP). Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 1 Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 4, psum 00, pofmetc 4, rec 03, units 00, sizes: 65535 0 Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Error: 802, cmd: 15 10 0 0 18 0 Dec 30 19:26:12 shakuhachi kernel: st0: Sense Key : Illegal Request [current] Dec 30 19:26:12 shakuhachi kernel: st0: Add. Sense: Invalid field in parameter list Dec 30 19:26:12 shakuhachi kernel: st 7:0:0:0: st0: Partitioning of tape failed. -- -------- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Wed, 30 Dec 2015 21:21:47 +0200 "Kai Mäkisara (Kolumbus)" <kai.makis...@kolumbus.fi> écrivait: > This happens if the position is not at the beginning of partition 0. > Could you try to switch to partition 0: > mt -f /dev/nst0 setpartition 0 > mt -f /dev/nst0 status > > and the retry partitioning. Alas, no dice: # mt -f /dev/nst0 setpartition 0 Dec 30 22:19:33 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Dec 30 22:19:33 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Dec 30 22:19:33 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Dec 30 22:19:33 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). # mt -f /dev/nst0 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 0 bytes. Density code 0x5a (no translation). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN Dec 30 22:19:49 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Dec 30 22:19:49 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Dec 30 22:19:49 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Dec 30 22:19:49 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). # mt -f /dev/nst0 mkpartition 0 Dec 30 22:22:21 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Dec 30 22:22:21 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Dec 30 22:22:21 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Dec 30 22:22:21 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Dec 30 22:22:21 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape. Dec 30 22:22:21 shakuhachi kernel: st 7:0:0:0: st0: Partition page length is 16 bytes. Dec 30 22:22:21 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 1, psum 03, pofmetc 4, rec 03, units 09, sizes: 2543 38 Dec 30 22:22:21 shakuhachi kernel: st 7:0:0:0: st0: Sending FORMAT MEDIUM Dec 30 22:22:21 shakuhachi kernel: st 7:0:0:0: st0: Error: 802, cmd: 4 0 0 0 0 0 Dec 30 22:22:21 shakuhachi kernel: st0: Sense Key : Illegal Request [current] Dec 30 22:22:21 shakuhachi kernel: st0: Add. Sense: Position past beginning of medium -- -------- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
: st0: Partition page length is 16 bytes. Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 0, xdp 1, psum 03, pofmetc 0,rec 03 units 09, sizes: 2620 0 Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: psd_cnt 2, max.parts 3, nbr_parts 0 Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Formatting tape with two partitions (FDP). Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Sent partition page length is 12 bytes. needs_format: 0 Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: PP: max 3, add 1, xdp 4, psum 00, pofmetc 0,rec 03 units 00, sizes: 65535 0 Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Error: 802, cmd: 15 10 0 0 18 0 Dec 29 18:55:54 shakuhachi kernel: st0: Sense Key : Illegal Request [current] Dec 29 18:55:54 shakuhachi kernel: st0: Add. Sense: Invalid field in parameter list Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Partitioning of tape failed. Dec 29 18:55:54 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape. -- -------- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Fri, 25 Dec 2015 17:53:46 +0200 (EET) Kai Makisara <kai.makis...@kolumbus.fi> écrivait: > the patch implements the following: if the > size is 1, the driver tells the drive to use default partitioning for > two partitions. For the HP Ultrium this should result in partition 0 > of 1425 GB and 1 of 37.5 GB. I don't know if this is a useful > addition. Oh BTW I didn't check what's happening in code, but actual values should be 37.5 GB for partition 0 and 1425 GB for partition 1, not the other way around. -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Fri, 25 Dec 2015 17:53:46 +0200 (EET) Kai Makisara <kai.makis...@kolumbus.fi> écrivait: > The patch uses the scsi level of the device to separate processing. > The FORMAT MEDIUM command is defined in SCSI-3 and I suppose that no > current drive is still SCSI-2. In addition to the "sane" changes > using the method to specify partitions, the patch implements the > following: if the size is 1, the driver tells the drive to use > default partitioning for two partitions. For the HP Ultrium this > should result in partition 0 of 1425 GB and 1 of 37.5 GB. I don't > know if this is a useful addition. Still testing, with another, LTO-5 tape: ~# mt -f /dev/nst0 mkpartition 0 /dev/nst0: Invalid argument Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Density 58, tape length: 0, drv buffer: 1 Dec 29 17:57:38 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Fri, 25 Dec 2015 17:53:46 +0200 (EET) Kai Makisara <kai.makis...@kolumbus.fi> écrivait: > The patch uses the scsi level of the device to separate processing. > The FORMAT MEDIUM command is defined in SCSI-3 and I suppose that no > current drive is still SCSI-2. In addition to the "sane" changes > using the method to specify partitions, the patch implements the > following: if the size is 1, the driver tells the drive to use > default partitioning for two partitions. For the HP Ultrium this > should result in partition 0 of 1425 GB and 1 of 37.5 GB. I don't > know if this is a useful addition. > I didn't look much at the code, but here's what's happening when running "mt -f /dev/st0 mkpartition 1": Dec 29 17:01:53 shakuhachi kernel: st: Version 20151225, fixed bufsize 32768, s/g segs 256 Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: Attached scsi tape st0 Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: try direct i/o: yes (alignment 512 B) Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Dec 29 17:01:53 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Dec 29 17:02:04 shakuhachi kernel: st 7:0:0:0: st0: Rewinding tape. Dec 29 17:03:06 shakuhachi kernel: st 7:0:0:0: st0: Block limits 1 - 16777215 bytes. Dec 29 17:03:06 shakuhachi kernel: st 7:0:0:0: st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 Dec 29 17:03:06 shakuhachi kernel: st 7:0:0:0: st0: Density 5a, tape length: 0, drv buffer: 1 Dec 29 17:03:06 shakuhachi kernel: st 7:0:0:0: st0: Block size: 0, buffer size: 4096 (1 blocks). Dec 29 17:07:20 shakuhachi kernel: st 7:0:0:0: st0: Error: 802,cmd: 0 0 0 0 0 0 Note that I've simply patched my plain vanilla 3.18.25 st modules. There doesn't seem to be any difference with newer (or older) kernels, anyway. Do you want me to try anything in particular? Is my mt version OK (v 1.1)? -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Fri, 25 Dec 2015 17:53:46 +0200 (EET) Kai Makisara <kai.makis...@kolumbus.fi> écrivait: > The patch at the end of this message is an attempt to make the > partitioning work for both old and new drives. The patch is against > st.c from the current git kernel, although I have tested it in 4.3.3. > It seems to work with my HP DDS-4 drive. It includes some debugging > printks and I have tried to see that the commands that would have > been sent to newer drives are basically correct. > > The patch uses the scsi level of the device to separate processing. > The FORMAT MEDIUM command is defined in SCSI-3 and I suppose that no > current drive is still SCSI-2. In addition to the "sane" changes > using the method to specify partitions, the patch implements the > following: if the size is 1, the driver tells the drive to use > default partitioning for two partitions. For the HP Ultrium this > should result in partition 0 of 1425 GB and 1 of 37.5 GB. I don't > know if this is a useful addition. Great I'll give it a try soon next week! -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Tue, 22 Dec 2015 05:51:30 +
"Seymour, Shane M" <shane.seym...@hpe.com> écrivait:
> 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 gracefully). I may be able to beg, borrow,
> or steal access to an LTO 5 or 6 drive though to help out in testing.
ATM I have an HP LTO-5 and IBM LTO-6 drives (there are real differences
in behaviour between these at times). I need to check what media I have
available for tests though.
> Kai, for the source of the HPE EverStore software should be available
> here:
>
> http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=5111617
The IBM driver should be here:
http://www-933.ibm.com/support/fixcentral/swg/quickorder?parent=ibm~ST~Tapedevicedriversandsoftware=ibm/Storage_Tape/Tape+device+drivers=1.0=Linux=all=fc
When you have selected RH as a platform, the source rpm is also
available to download.
>
> This seems to be the relevant code from the driver though (the same
> download has the ibm tape driver as well). You'll need to look at the
> following:
>
> ltotape.c - ltotape_readposition to determine the current partition
> ltotape.c - ltotape_locate - to move to a position on tape (includes
> setting the partition and has a special flag for changing partitions
> between the two it supports if required) ltotape.c - ltotape_format -
> for creating and destroying partitions ltotape.c -
> ltotape_remaining_capacity - will get you the remaining and maximum
> capacity for the partitions
>
> When you look at those functions you'll see TC_FORMAT_TYPE referenced
> this is the enum referred it is in src/libltfs/tape_ops.h:
>
> typedef enum {
> TC_FORMAT_DEFAULT = 0x00, /* Make 1 partition medium */
> TC_FORMAT_PARTITION = 0x01, /* Make 2 partition medium */
> TC_FORMAT_DEST_PART = 0x02, /* Destroy all data and make 2
> partition medium */ TC_FORMAT_MAX = 0x03
> } TC_FORMAT_TYPE;/* Space command operations */
> The driver at that download looks like it only supports two
> partitions though and if you go looking around the code (grep for
> partition) some LTO drives (probably older ones) look like they may
> be partition aware but may not actually support partitions, see this
> comment:
>
> ltotape_platform.c: * For an LTO drive, need to determine
> whether it is partition-capable or only partition-aware:
The IBM code however looks like it supports any number of partitions
(though LTO-6/7 support only 4,so MAX_SUPPORTED_PARTITIONS is set to 4):
if(copy_from_user((void*)usr_part, (void*)arg,
sizeof(struct tape_partition))) {
printk("lin_tape_create_partition: cannot copy from user\n");
rc = -EFAULT;
goto EXIT_LABEL;
} /* if */
if(usr_part->number_of_partitions > MAX_SUPPORTED_PARTITIONS) {
DbgPrint(("lin_tape: too many partitions %d\n",
usr_part->number_of_partitions));
rc = -EINVAL;
goto EXIT_LABEL;
} /* if */
Interestingly it seems to support both wrap partitioning and
longitudinal partitioning (on 3592 drives).
--
Emmanuel Florac | Direction technique
| Intellique
| <eflo...@intellique.com>
| +33 1 78 94 84 02
--
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
Re: st driver doesn't seem to grok LTO partitioning
Le Tue, 22 Dec 2015 02:20:31 -0500 Laurence Oberman <oberma...@gmail.com> écrivait: > I also have access to newer hardware if needed. I have started > reviewing all of this and will post back to this thread. > Emmanuel can you summarize what you would like to achieve and we will > all work on this together. I'd like to be able to partition LTO media through standard commands, like "mt mkpartition", mostly to be able to create LTFS tapes without relying on hard to compile code from IBM/HP/Quantum/Oracle. -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Fri, 18 Dec 2015 17:06:44 +0100 Emmanuel Florac <eflo...@intellique.com> écrivait: > > I'm trying to use mt to work with LTO-5 and bigger tapes. Switching > partitions works: > > # tapeinfo -f /dev/sg1 > Product Type: Tape Drive > Vendor ID: 'HP ' > Product ID: 'Ultrium 5-SCSI ' > Revision: 'Z61U' > Attached Changer API: No > SerialNumber: 'HU1249TP88' > MinBlock: 1 > MaxBlock: 16777215 > SCSI ID: 1 > SCSI LUN: 0 > Ready: yes > BufferedMode: yes > Medium Type: Not Loaded > Density Code: 0x58 > BlockSize: 0 > DataCompEnabled: yes > DataCompCapable: yes > DataDeCompEnabled: yes > CompType: 0x1 > DeCompType: 0x1 > BOP: yes > Block Position: 0 > Partition 0 Remaining Kbytes: 1459056 > Partition 0 Size in Kbytes: 1459056 > ActivePartition: 0 > EarlyWarningSize: 0 > NumPartitions: 1 > MaxPartitions: 1 > Partition0: 38 > Partition1: 1453 > > # mt -f /dev/nst0 setpartition 1 > > > However "mt mkpartition" fails miserably: > > # mt -f /dev/nst0 mkpartition 1453 > /dev/nst0: Input/output error > > # dmesg | tail > st 6:0:1:0: st0: Failed to read 65536 byte block with 256 byte > transfer. st0: Sense Key : Illegal Request [current] > st0: Add. Sense: Invalid field in parameter list > > Is this a limitation of mt or the st driver? > I'm replying to myself: this is very obviously a limitation of the st driver. Checking st.c partition_tape() function, it looks like it only knows of hardware from past century... OTOH it seems that Cygwin does that properly... by using CreateTapePartition, a windows kernel32.dll function. Argh. We'll have to do the heavy lifting of SCSI commands by hand, then. Where should we post an eventual patch, given that the linux-tape ML looks like a ghost town? It would also be great to be able to support more than 2 partitions (LTO-6 and 7 support 4), but that would require patching the mt utility too, but I don't where it currently lives :) Any hints welcome. -- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: st driver doesn't seem to grok LTO partitioning
Le Mon, 21 Dec 2015 11:20:55 -0500 Laurence Oberman <oberma...@gmail.com> écrivait: > The st driver gets a lot of attention actually. Let me look into this > and get back you. I've found that the IBM tape driver (lin_tape) implements neat ioctls for LTO and 3592 tape partitionning. Just in case. -- ---- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: Limit max concurrent sessions
Le Sun, 27 Sep 2015 12:28:41 +0200 Gionatan Danti <g.da...@assyoma.it> écrivait: > Il 23-09-2015 17:18 Emmanuel Florac ha scritto: > > > > Use XFS. XFS won't let you mount it several time on different > > machines without various "force" options. > > Alternatively, use a cluster-aware FS like ocfs2. Ocfs2 is quite > > easy to set up. > > Thank you for the suggestion. > Unfortunately, due to specific requirements I must use EXT4. > > So, there is no methods to limit concurrent connections? > Thanks. Not that I know of using LIO. However, using ietd you can use the MaxSession parameter to limit the number of concurrent sessions. -- -------- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: Limit max concurrent sessions
Le Wed, 23 Sep 2015 16:20:01 +0200 Gionatan Danti <g.da...@assyoma.it> écrivait: > Hi all, > anyone with some ideas / infos ? > > Thanks. > > On 06/05/15 17:36, Gionatan Danti wrote: > > Hi all, > > I would like to understand if, and how to, limit the maximum number > > of simultaneous connections to a specific LUN, both with the old > > iSCSI stack (tgtadmin and friends) and the new one (targetcli and > > the likes). > > > > I am exporting a LUN with a general purpose filesystem (non cluster > > aware) and I would be 100% sure that only a single machine at a > > time can mount it. > > > > At the moment, I protected the iSCSI LUN with both an IP-based > > access list and a username/password combo, but hard limiting the > > maximum number of connections opened against it to 1 (one) would be > > a nice thing... > > > > As I have mixed RHEL 6 and 7 environment, I am interested in how to > > do that on both the old and new iSCSI stack. > > Use XFS. XFS won't let you mount it several time on different machines without various "force" options. Alternatively, use a cluster-aware FS like ocfs2. Ocfs2 is quite easy to set up. -- Emmanuel Florac | Direction technique | Intellique | <eflo...@intellique.com> | +33 1 78 94 84 02 -- 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
Re: Adaptec 71605H HBA randomly failing to detect any drives at init
Le Mon, 1 Sep 2014 09:06:46 -0700 Andrew Robertson andyrobertson...@gmail.com écrivait: I'm happy to test patches/etc on this system if necessary -- and/or if someone can help point me in the right direction, I'd appreciate it. In my experience the 7xxx5 are very sensitive to cable length and backplane type: basically work fine with 50 cm cables, and fails with 80 cm cables with some backplanes (works with Supermicro, not with AIC, etc). So what is the backplane and cables you're using? -- Emmanuel Florac | Direction technique | Intellique | eflo...@intellique.com | +33 1 78 94 84 02 -- 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
Re: Dell Shared PERC8 RAID Controller
Le Mon, 3 Mar 2014 14:53:36 + Istvan Hubay Cebrian istvan.cebr...@gmail.com écrivait: lspci -nn (on Dell PowerEdge M520 Blade) ... 01:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2008 [Falcon] [1000:0073] (rev 03) This one is supported by the megaraid_sas driver, provided it's recent enough. 08:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2208 IOV [Thunderbolt] [1000:002f] (rev 05) ... This one seems unsupported. I don't know what it's actually for, though. Is it the one posing you a problem? I suppose ESXi lets you check (with modinfo) if megaraid_sas manages it. -- Emmanuel Florac | Direction technique | Intellique | eflo...@intellique.com | +33 1 78 94 84 02 -- 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
Re: Dell Shared PERC8 RAID Controller
Le Mon, 3 Mar 2014 15:22:13 + Istvan Hubay Cebrian istvan.cebr...@gmail.com écrivait: I can't however see the Shared storage provided by the VRTX Enclosure. I would assume one controller is for the internal storage of the M520 Blade and the other controller for the Shared storage. Yes, that's probably the case. As I said, I'd first try installing ESXi on a blade to check what driver it uses for this particular card (ESXi is a special Linux distro after all). -- Emmanuel Florac | Direction technique | Intellique | eflo...@intellique.com | +33 1 78 94 84 02 -- 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
Re: Dell Shared PERC8 RAID Controller
Le Mon, 3 Mar 2014 17:56:04 + Istvan Hubay Cebrian istvan.cebr...@gmail.com écrivait: ~ # esxcli system module get -m megaraid_sas Module: megaraid_sas Module File: /usr/lib/vmware/vmkmod/megaraid_sas License: GPL Version: Version 06.801.52.00, Build: 472560, Interface: 9.2 Built on: Feb 7 2013 Signed Status: Unsigned Signature Issuer: Signature Digest: 50bd fb02 0df9 4ad0 3d99 00de 9234 f055 f7d2 f81e aadf 7120 a941 44b3 61a6 d3b1 Signature FingerPrint: Provided Namespaces: Required Namespaces: com.vmware.driverAPI@9.2.0.0, com.vmware.vmkapi@v2_0_0_0 OK so this looks like the normal megaraid_sas under the usual license, though it obviously works with the weird device: 00:08:00.0 RAID bus controller Mass storage controller: LSI Logic / Symbios Logic Shared PERC 8 Mini [vmhba2] Class 0104: 1000:002f Could you grab the file /usr/lib/vmware/vmkmod/megaraid_sas.ko and run modinfo on it (even from a different distro, should work fine I suppose). -- Emmanuel Florac | Direction technique | Intellique | eflo...@intellique.com | +33 1 78 94 84 02 -- 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
Re: Dell Shared PERC8 RAID Controller
Le Mon, 3 Mar 2014 18:44:50 + vous écriviez: Specifically stated MegaRAID whilst the Shared PERC 8 does not. In the module listing I can't clearly identify any module that would be responsible for providing support to the shared PERC 8 controller Well I went through the module list and couldn't find anything else that could reasonably fit with an LSI driver, so I'm pretty sure it must be the megaraid driver... If only it could be a normal Linux system, alas. -- Emmanuel Florac | Direction technique | Intellique | eflo...@intellique.com | +33 1 78 94 84 02 -- 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
Re: Odd behavior of a SAS-2 backplane with SGPIO commands
Le Mon, 10 Sep 2012 16:47:11 +0300 Pasi Kärkkäinen pa...@iki.fi écrivait: Any replies from Supermicro/LSI ? Only loosely related, but Supermicro replaced recently my 846E26 (dual expander backplane) with 846E16 (single expander). Apparently they gave up getting the E26 to work properly or something: LSI expander firmware problem. In another (very large scale, high end) setup, many different 60 slots 5 LSI expanders chassis had a general failure of the 5th drawer. Another LSI SAS-2 expander firmware problem. I could start a rant about the evil of proprietary firmware, etc. You get my meaning :) -- Emmanuel Florac | Direction technique | Intellique | eflo...@intellique.com | +33 1 78 94 84 02 -- 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
