That took care of half the problem, but it's still failing because of: block/data: Cannot find attribute: fabric_max_sectors, skipped I tried adding it but either I'm putting it in the wrong location or my syntax is wrong, please advise. Thanks On Fri, Apr 3, 2015 at 5:43 PM, Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> wrote: > Hi Dan, > > On Fri, 2015-04-03 at 11:41 -0400, Dan Lane wrote: >> I recently rebuilt my storage server (again) using Fedora 21 Server >> (64-bit). Once everything was up and running I built out my target >> configuration and confirmed it was working. This was using the >> original Kernel 3.17.4. >> >> At this point I decided to update my update my server. Once I was >> done with all the updates, I found that target now refuses to start. >> Running "journalctl -xe" shows the following errors: >> >> Apr 03 02:24:36 labsan1.home.lan kernel: Rounding down aligned >> max_sectors from 4294967295 to 4294967288 >> Apr 03 02:24:36 labsan1.home.lan kernel: dev[ffff8800c8ffa000]: Passed >> optimal_sectors 8192 cannot be greater than hw_max_sectors: 512 >> Apr 03 02:24:36 labsan1.home.lan kernel: qla2xxx >> [0000:08:01.1]-00af:6: Performing ISP error recovery - >> ha=ffff8800c7098000. >> Apr 03 02:24:37 labsan1.home.lan kernel: qla2xxx >> [0000:08:01.1]-500a:6: LOOP UP detected (4 Gbps). >> Apr 03 02:24:37 labsan1.home.lan kernel: qla2xxx >> [0000:08:01.0]-00af:5: Performing ISP error recovery - >> ha=ffff8800c79f4000. >> Apr 03 02:24:38 labsan1.home.lan kernel: qla2xxx >> [0000:08:01.0]-500a:5: LOOP UP detected (4 Gbps). >> Apr 03 02:24:38 labsan1.home.lan kernel: qla2xxx >> [0000:0d:01.1]-00af:4: Performing ISP error recovery - >> ha=ffff8800c748c000. >> Apr 03 02:24:39 labsan1.home.lan kernel: qla2xxx >> [0000:0d:01.1]-500a:4: LOOP UP detected (4 Gbps). >> Apr 03 02:24:39 labsan1.home.lan kernel: qla2xxx >> [0000:0d:01.0]-00af:3: Performing ISP error recovery - >> ha=ffff8800359ac000. >> Apr 03 02:24:40 labsan1.home.lan kernel: qla2xxx >> [0000:0d:01.0]-500a:3: LOOP UP detected (4 Gbps). >> Apr 03 02:24:40 labsan1.home.lan target[1149]: Restore failed, 2 errors: >> Apr 03 02:24:40 labsan1.home.lan target[1149]: Storage Object >> block/data: Cannot set attribute optimal_sectors: [Errno 22] Invalid >> argument, skipped >> Apr 03 02:24:40 labsan1.home.lan target[1149]: Storage Object >> block/data: Cannot find attribute: fabric_max_sectors, skipped >> Apr 03 02:24:40 labsan1.home.lan systemd[1]: target.service: main >> process exited, code=exited, status=255/n/a >> Apr 03 02:24:40 labsan1.home.lan systemd[1]: Failed to start Restore >> LIO kernel target configuration. >> -- Subject: Unit target.service has failed >> -- Defined-By: systemd >> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >> -- >> -- Unit target.service has failed. >> -- >> -- The result is failed. >> >> I found a few other results on google that seemed to mostly match >> this, but they talk about this being patched already. >> >> Package versions: >> python-rtslib-2.1.fb52-1.fc21.noarch >> targetcli-2.1.fb39-1.fc21.noarch >> >> uname -a: >> Linux labsan1.home.lan 3.19.3-200.fc21.x86_64 #1 SMP Thu Mar 26 >> 21:39:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> > > This looks like a -fb specific bug. Even if setting an attribute fails, > it should not abort bringing up the device. Adding Andy CC'. > > A simple work-around is to change the saved optimal_sectors value for > the backend device in question from 8192 to 512 to match hw_max_sectors. > > --nab > -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
