Antw: [EXT] Re: [PATCH 0/2] scsi:donot skip lun if inquiry returns PQ=1 for all hosts

>>> Christoph Hellwig schrieb am 15.12.2022 um 08:06 in Nachricht : > On Wed, Dec 14, 2022 at 03:08:44PM +0800, Wenchao Hao wrote: >> When iSCSI initiator logged in target, the target attached none valid >> lun but lun0. lun0 is not an valid disk, while it would response >> inquiry command with PQ

Antw: [EXT] [PATCH 1/2] scsi:core:Add sysfs interface to control if skip lun with PQ=1

>>> "'Wenchao Hao' via open-iscsi" schrieb am 14.12.2022 um 08:08 in Nachricht <20221214070846.1808300-2-haowenc...@huawei.com>: ... > + * Targets set PQ=1 would be skipped if shost->no_skip_pq1 is not set I would write "Targets that set ..." instead. ... -- You received this message b

Antw: Re: [EXT] Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

>>> Ulrich Windl schrieb am 25.11.2022 um 08:11 in Nachricht <63806AA5.95B : >>> 161 : 60728>: >>>> "'Wenchao Hao' via open-iscsi" schrieb am > 24.11.2022 um 16:30 in Nachricht > <2d0439ba-7fb7-47ef-b52c-a866dc0c86...@googlegroups

Antw: Re: [EXT] Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

>>> "'Wenchao Hao' via open-iscsi" schrieb am 24.11.2022 um 16:30 in Nachricht <2d0439ba-7fb7-47ef-b52c-a866dc0c86...@googlegroups.com>: > On Thursday, November 24, 2022 at 6:06:09 PM UTC+8 Uli wrote: > >> >>> "'Lee Duncan' via open-iscsi" schrieb am >> 23.11.2022 um 17:47 in Nachricht >> <0f7

Antw: [EXT] Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

>>> "'Lee Duncan' via open-iscsi" schrieb am 23.11.2022 um 17:47 in Nachricht <0f7258d5-ff8e-fa4e-ab8e-5125c42a6...@suse.com>: > On 11/22/22 20:41, Wenchao Hao wrote: ... > Again, I don't believe that's correct. I will test it. ... Maybe a session capture (via serial line or so) to show real fact

Antw: [EXT] Re: [PATCH v6] scsi:iscsi: Fix multiple iscsi session unbind event sent to userspace

>>> "'Wenchao Hao' via open-iscsi" schrieb am 21.11.2022 um 15:17 in Nachricht <89692b2b-90f7-e8e8-fa77-f14dbe996...@huawei.com>: > On 2022/11/9 11:47, Mike Christie wrote: >> On 11/7/22 7:44 PM, Wenchao Hao wrote: >>> I found an issue that kernel would send ISCSI_KEVENT_UNBIND_SESSION >>> for mul

Antw: [EXT] Re: [PATCH] scsi: iscsi: prefer xmit of DataOut before new cmd

>>> Adam Hutchinson schrieb am 15.06.2022 um 20:57 in Nachricht : > Is there any reason not to use time as an indicator that pending R2Ts > need to be processed? Could R2Ts be tagged with a timestamp when > received and only given priority over new commands if the age of the > R2T at the head exc

Antw: [EXT] Re: [PATCH] scsi: iscsi: prefer xmit of DataOut before new cmd

Hi! In my primitive point of view iSCSI is just "another type of cable", making me wonder: Is iSCSI allowed to reorder the requests at all? Shouldn't the block layer or initiator do so, or the target doing out-of order processing (tagged queueing)? I mean: If there is a problem that occurs even

Antw: [EXT] Re: [PATCH] scsi: iscsi: prefer xmit of DataOut before new cmd

>>> Mike Christie schrieb am 08.06.2022 um 17:36 >>> in Nachricht <48af6f5f-c3b6-ac65-836d-518153ab2...@oracle.com>: > On 6/8/22 9:16 AM, Dmitriy Bogdanov wrote: >> Hi Mike, >> >>> On 6/7/22 10:55 AM, Mike Christie wrote: On 6/7/22 8:19 AM, Dmitry Bogdanov wrote: > In function iscsi_dat

Antw: [EXT] [PATCH] scsi: iscsi: fix harmless double shift bug

>>> Dan Carpenter schrieb am 21.04.2022 um 17:03 in Nachricht : > These flags are supposed to be bit numbers. Right now they cause a > double shift bug where we use BIT(BIT(2)) instead of BIT(2). > Fortunately, the bit numbers are small and it's done consistently so it > does not cause an issue a

Antw: [EXT] Re: [PATCH v2] scsi: iscsi: Fix multiple iscsi session unbind event sent to userspace

>>> Mike Christie schrieb am 20.04.2022 um 18:28 >>> in Nachricht <938bca13-2dcc-24c0-51b5-26f7e7238...@oracle.com>: ... > >> diff --git a/include/scsi/scsi_transport_iscsi.h > b/include/scsi/scsi_transport_iscsi.h >> index 9acb8422f680..877632c25e56 100644 >> --- a/include/scsi/scsi_transport

Antw: [EXT] Re: Question about iscsi session block

>>> Donald Williams schrieb am 15.02.2022 um 17:25 in Nachricht : > Hello, >Something else to check is your MPIO configuration. I have seen this > same symptom when the linux MPIO feature "queue_if_no_path" was enabled > > From the /etc/multipath.conf file showing it enabled. > > failb

Antw: [EXT] hostbyte=DID_TRANSPORT_DISRUPTED: network issues or?

>>> Mauricio schrieb am 26.11.2021 um 15:52 in Nachricht <0c84ea13-e5f5-4755-8f34-3b81dd0040...@googlegroups.com>: > Now I was able to address my issue with the testbox, I can mount the > LUN in that host without issues. So it is time to switch back to the > problem box, which started hav

Antw: Re: [EXT] Concurrent usage of iscsiadm

>>> The Lee-Man schrieb am 21.10.2021 um 17:55 in Nachricht <8d711f1e-d3f4-4109-87ed-a950e93298...@googlegroups.com>: > Hi Ulrich: > > I don't see how systemd is going to run parallel iscsiadm commands, at > least with the units that come with open-iscsi. Systemd actually guards > against that.

Antw: [EXT] Concurrent usage of iscsiadm

Hi! Another thing is: Whether you like systemd or not: It runs many processes automatically and concurrently. So it seems wise that iscasadm may be run concurrently. If there are issues, iscsiadm should use a MUTEX internally to avoid those IMHO Regards, Ulrich >>> Vojtech Juranek schrieb am 2

Re: Antw: [EXT] Re: [PATCH] scsi scsi_transport_iscsi.c: fix misuse of %llu in scsi_transport_iscsi.c

>>> Guo Zhi schrieb am 15.10.2021 um 09:36 in >>> Nachricht <6772c5ef-4666-e2b5-2885-797baa939...@sjtu.edu.cn>: > However if this is a special pointer to lookup a driver, It's really > tricky for me to fix it, > > as I don't have a scsi device to test my code. Years ago when a big server had

Re: Antw: [EXT] Re: [PATCH] scsi scsi_transport_iscsi.c: fix misuse of %llu in scsi_transport_iscsi.c

>>> Mike Christie schrieb am 11.10.2021 um 17:29 >>> in Nachricht : > On 10/11/21 1:35 AM, Ulrich Windl wrote: >>>>> Joe Perches schrieb am 09.10.2021 um 05:14 in Nachricht >> <5daf69b365e23ceecee911c4d0f2f66a0b9ec95c.ca...@perches.com>: >

Antw: [EXT] Re: [PATCH] scsi scsi_transport_iscsi.c: fix misuse of %llu in scsi_transport_iscsi.c

>>> Joe Perches schrieb am 09.10.2021 um 05:14 in Nachricht <5daf69b365e23ceecee911c4d0f2f66a0b9ec95c.ca...@perches.com>: > On Sat, 2021-10-09 at 11:02 +0800, Guo Zhi wrote: >> Pointers should be printed with %p or %px rather than >> cast to (unsigned long long) and printed with %llu. >> Change %l

Antw: [EXT] linux iscsi target setup for IP camera

I think at the very least you'll have to provide some details (like logs from Linux, and maybe some details from Windows where it is said to work). Or a technical specification of the camera at least. Regards, Ulrich >>> Fernando Perfumo schrieb am 26.08.2021 um 16:44 in >>> Nachricht : > I'm

Re: Antw: [EXT] ISCSI Target and Initiator on same host

make sense that you can do this, but > practically there is weird issues. Would you guys say it might be a > misconfiguration ? Maybe be concrete with your setup and messages first. > > On Wednesday, 30 June 2021 at 15:10:54 UTC+2 Paul Koning wrote: > >> >> >> > On J

Antw: [EXT] ISCSI Target and Initiator on same host

I think I did that about 10 years ago... >>> Riaan Pretorius schrieb am 30.06.2021 um >>> 12:41 in Nachricht <07b30064-72b3-42c1-ae71-f40c885c06...@googlegroups.com>: > I have an interesting question to ask: > > Is it possible to share the target on the same server as a initiator ? > e.g. serve

Aw: [EXT] Re: [PATCH 1/1] scsi: Fix spelling mistakes in header files

(Amazingly I also did think "busses" is correct -- seems to be a common mistake; maybe only for Germans that would pronounce "busses" differently from "buses"...) >>> Martin K. Petersen 26.05.2021, 06:08 >>> On Mon, 17 May 2021 17:59:45 +0800, Zhen Lei wrote: > Fix some spelling mistakes in c

Antw: [EXT] [PATCH AUTOSEL 5.11 07/22] scsi: iscsi: Fix race condition between login and sync thread

>>> Sasha Levin schrieb am 05.04.2021 um 18:03 in Nachricht <20210405160406.268132-7-sas...@kernel.org>: > @@ -2963,6 +2971,7 @@ static int iscsi_if_ep_disconnect(struct > iscsi_transport *transport, > mutex_lock(&conn->ep_mutex); > conn->ep = NULL; > mut

Antw: [EXT] Hi help me please

>>> go xayyasang schrieb am 06.12.2020 um 15:38 in Nachricht : > [root@target ~]# iscsiadm -m node -o show > iscsiadm: No records found Hi! Obviously something is not as you expect. Without knowing details, nobody can help you. Please take the time to explain what you did and what you do expect

Antw: [EXT] [PATCH 05/12] open-iscsi: Fix NULL pointer dereference in mgmt_ipc_read_req()

>>> Wenchao Hao schrieb am 07.12.2020 um 02:54 in >>> Nachricht <20201207015410.48488-6-haowenc...@huawei.com>: > If malloc() returns NULL on fail, we should return -ENOMEM to > avoid NULL pointer dereference. > > Signed-off-by: Wenchao Hao > Signed-off-by: Zhiqiang Liu > Signed-off-by: Wu Bo

Antw: [EXT] [PATCH] iscsiadm: Verify mode parameters when recognize mode

>>> Wenchao Hao schrieb am 20.11.2020 um 07:20 in >>> Nachricht <20201120062052.51838-1-haowenc...@huawei.com>: > Parameters verify should be performed as soon as possible > to avoid unuseless work. "avoid unuseless work" ;-) Is that useful work? -- You received this message because you are

Antw: [EXT] [PATCH v2] SCSI: libiscsi: fix NOP race condition

>>> Lee Duncan schrieb am 06.11.2020 um 20:33 in Nachricht <20201106193317.16993-1-leeman.dun...@gmail.com>: ... > +/* invalid scsi_task pointer */ > +#define INVALID_SCSI_TASK (struct iscsi_task *)-1l ... Comment: I prefer 'L' over 'l', because in many fonts 'I', '1' and 'l' look ve

Antw: [EXT] Re: Slow iSCSI tape performance

>>> The Lee-Man schrieb am 25.10.2020 um 17:51 in Nachricht <4ad354c3-5d6a-4b1f-b978-afee5d1219...@googlegroups.com>: > I haven't heard about disabling TUR for iSCSI tape improvement. Even if > true, I'm not sure how you'd do that. You'd need to modify your target IMHO > to always reply "ready"

Antw: [EXT] Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

>>> Mike Christie schrieb am 08.10.2020 um 22:54 >>> in Nachricht <47eca384-b54e-63cc-0f84-7ed6501f4...@oracle.com>: > On 10/8/20 12:11 PM, Mike Christie wrote: >> On 9/25/20 1:41 PM, ldun...@suse.com wrote: >>> From: Lee Duncan >>> >>> iSCSI NOPs are sometimes "lost", mistakenly sent to the >>>

Antw: [EXT] [PATCH v9 2/7] net: add WARN_ONCE in kernel_sendpage() for improper zero-copy send

>>> Coly Li schrieb am 01.10.2020 um 09:54 in Nachricht <20201001075408.25508-3-col...@suse.de>: > If a page sent into kernel_sendpage() is a slab page or it doesn't have > ref_count, this page is improper to send by the zero copy sendpage() > method. Otherwise such page might be unexpected releas

Antw: [EXT] [PATCH v6 1/6] net: introduce helper sendpage_ok() in include/linux/net.h

>>> Coly Li schrieb am 18.08.2020 um 14:47 in Nachricht <20200818124736.5790-2-col...@suse.de>: > The original problem was from nvme-over-tcp code, who mistakenly uses > kernel_sendpage() to send pages allocated by __get_free_pages() without > __GFP_COMP flag. Such pages don't have refcount (page_

Antw: [EXT] Re: Large Immediate and/or Unsolicted Data causes long delays on R2T responses

>>> The Lee-Man schrieb am 29.06.2020 um 20:59 in Nachricht <4792_1593457181_5EFA3A1C_4792_1489_1_4c70b62c-467c-4860-a951-663fb88158c7o@goog egroups.com>: > On Saturday, May 2, 2020 at 11:30:27 AM UTC-7, ajhutc...@gmail.com wrote: >> >> I am able to create a condition where the open-iscsi initiato

Antw: [EXT] [PATCH] iscsi: Add break to while loop

>>> Wu Bo schrieb am 04.06.2020 um 14:23 in Nachricht <7784_1591272646_5ED8E4C6_7784_490_1_1591273415-689835-1-git-send-email-wubo40@h awei.com>: > From: liubo > > Fix the potential risk of rc value being washed out by jumping out of the > loop > > Signed-off-by: liubo > Reported-by: Zhiqiang

Antw: [EXT] Re: udev events for iscsi

>>> Donald Williams schrieb am 21.04.2020 um 20:49 in Nachricht <30147_1587494977_5E9F4041_30147_801_1_CAK3e-EawwxYGb3Gw74+P-yBmrnE0ktOL=Fj1OT_L q+czyz...@mail.gmail.com>: > Hello, > > If the loss exceeds the timeout value yes. If the 'drive' doesn't come > back in 30 to 60 seconds it's not lik

Antw: [EXT] Re: udev events for iscsi

>>> The Lee-Man schrieb am 21.04.2020 um 20:44 in Nachricht <618_1587494664_5E9F3F08_618_445_1_7f583720-8a84-4872-8d1a-5cd284295c22@googlegr ups.com>: > On Tuesday, April 21, 2020 at 12:31:24 AM UTC-7, Gionatan Danti wrote: >> >> [reposting, as the previous one seems to be lost] >> >> Hi all, >> I

Antw: [EXT] Re: udev events for iscsi

>>> Donald Williams schrieb am 21.04.2020 um 18:06 in Nachricht <29812_1587485183_5E9F19FE_29812_432_1_CAK3e-EbA-d6NeDETJ0EMHeAw3HGko_uCB_f6gsiq jmeeyz...@mail.gmail.com>: [...] > > The default setting for Linux is 30 seconds. This can be verified using the > command: > > # for i in $(find /sy

Aw: [EXT] Re: udev events for iscsi

>>> 21.04.2020, 17:20 >>>Wondering myself.> On Apr 21, 2020, at 2:31 AM, Gionatan Danti wrote:> > > [reposting, as the previous one seems to be lost]> > Hi all,> I have a question regarding udev events when using iscsi disks.> > By using "udevadm monitor" I can see that events are generated when

Antw: [EXT] [PATCH] open-iscsi:Modify iSCSI shared memory permissions for logs

Hi! Maybe this could be made a symbolic constant, or even be made configurable. The other interesting thing is that there are three seemingly very similar code fragements to create the shared memory, but each with a different size parameter (sizeof(struct logarea) vs. size vs. MAX_MSG_SIZE + siz

Antw: [EXT] replacement_timeout Override

>>> Marc Smith schrieb am 14.03.2020 um 15:28 in Nachricht <29983_1584196109_5E6CEA0D_29983_1691_1_CAH6h+hdZ7QvF_WuLU5PJVpe4RpjM4EeEW7aBQVZ forzv1p...@mail.gmail.com>: > Hi, > > I'm using open-iscsi version 2.1.1. I noticed that my > "replacement_timeout" value set in the node record is not being

Antw: [EXT] [PATCH] scsi: Replace zero-length array with flexible-array member

Hi! Personally I think variable-sized structures are a bad thing, independent of the syntax being used. 30 years ago saving one indirection would have been an argument for such structures, but nowadays? Regards, Ulrich >>> "Gustavo A. R. Silva" schrieb am 24.02.2020 um >>> 17:14 in Nachricht

Antw: reboot hangs with "Reached target shutdown", who can help me?

Hi! I think the problem is more related to systemd, rather than iscsi. Personally I hate systemd, but you don't wnat to know that... Regards, Ulrich >>> can zhu schrieb am 10.12.2019 um 15:25 in Nachricht <372db1a3-424d-4063-bcdb-ccb0b821d...@googlegroups.com>: > os version: > > CentOS Linux r

Antw: [PATCH V4] scsi: avoid potential deadlock in iscsi_if_rx func

>>> "wubo (T)" schrieb am 20.11.2019 um 14:26 in Nachricht : > In iscsi_if_rx func, after receiving one request through iscsi_if_recv_msg > func, > iscsi_if_send_reply will be called to try to reply the request in do-loop. > If the return of iscsi_if_send_reply func return -EAGAIN all the time,

Antw: [PATCH AUTOSEL 4.19 054/237] scsi: iscsi_tcp: Explicitly cast param in iscsi_sw_tcp_host_get_param

>>> Sasha Levin schrieb am 16.11.2019 um 16:38 in Nachricht <20191116154113.7417-54-sas...@kernel.org>: > From: Nathan Chancellor > > [ Upstream commit 20054597f169090109fc3f0dfa1a48583f4178a4 ] > > Clang warns when one enumerated type is implicitly converted to another. IMHO even an explicit

Antw: Re: iSCSI packet generator

Hi! Just a note of curiosity: Several years ago I wanted to test some RAID configurations, but had no server with enough disks. However the server had a lot of RAM (by that time). So I ended with creating a few small ramdisks which I exported as iSCSI devices. The host was happy with those "dis

Antw: [PATCH v2] scsi: avoid potential deadloop in iscsi_if_rx func

>>> "wubo (T)" schrieb am 30.10.2019 um 08:56 in Nachricht : > From: Bo Wu ... > + if (--retries < 0) { > + printk(KERN_ERR "Send reply failed too many > times. " > +"Max supported retries %u\n", > ISCSI_SEND_M

Antw: Re: CEPH ISCSI Gateway - very slow performance - Fine tuning help

>>> "Ulrich Windl" schrieb am 14.02.2019 um 09:05 in Nachricht <5c65213302a10002f...@gwsmtp1.uni-regensburg.de>: > filesystems like ext3 occasionally make bug requests (like 1000 sectors), and Sorry: s/bug/big/ -- You received this message because you are sub

Antw: Re: CEPH ISCSI Gateway - very slow performance - Fine tuning help

>>> ASVINCHANDAR SELVARAJ schrieb am 14.02.2019 um >>> 06:03 in Nachricht : > I tried this > > Centos 7.4 > > echo '4096000' > /sys/block/sdb/queue/max_sectors_kb > > But I am getting Input/output error Actually for FC SAN storage we made the opposite experience: Some filesystems like ext3 o

Antw: Re: Initial Login Advice

Hi! I wonder: On Fibre-Channel (FC) SAN stroage systems, some systems indicate when there are new LUNs available, while others do not. Linux clients sometimes understand what the storage system is telling them, sometimes not. So usually one has to rescan the scsi bus to find new (or obsolete) L

Antw: Re: max_sectors_kb so small, throughout so small

Hi! I'm somewhat surprised: Maybe it's all about latency, because with FC-SAN we typically see a performance _decrease_ if large sequential requests are being transmitted. So actually we did limit the default amount of max_sectors_kb. Most "intelligent" SAN systems break down large requests to sma

Antw: [PATCH 3/4] libopeniscsiusr: clear errno before calling strtoll

>>> Chris Leech schrieb am 13.06.2018 um 17:25 in Nachricht <20180613152545.1049967-4-cle...@redhat.com>: > errno must be set to 0 before calling strtoll or error checking will > have false positives > --- > libopeniscsiusr/sysfs.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libopen

Antw: [PATCH 4/4] libopeniscsiusr: setup ipv6 records based on iface name

>>> Chris Leech schrieb am 13.06.2018 um 17:25 in Nachricht <20180613152545.1049967-5-cle...@redhat.com>: > The is_ipv6 flag (runtime iface rec representation only, not on disk) > was being set when creating ifaces from sysfs, but not when reading them > in from an iface record file. This caused i

Antw: Re: [PATCH] Reduce delays to improve iscsi boot performance

>>> The Lee-Man schrieb am 16.04.2018 um 23:57 in Nachricht <59dd48da-66d2-44c0-a2ef-669e1897f...@googlegroups.com>: > On Monday, April 16, 2018 at 2:38:01 PM UTC-7, The Lee-Man wrote: >> >> On Friday, April 13, 2018 at 3:19:11 PM UTC-7, cathy.z...@oracle.com >> wrote: >>> >>> From: Cathy Zhou

Antw: Re: 4.14.16 kworker deathspin if logged out without deleting scsi devices

>>> Maxim Ivanov schrieb am 15.02.2018 um 23:41 in Nachricht : > Investigating it further, it looks like it is working fine if multipathd > didn't start at all (unit is masked). If it was started, then stopped, > logout hangs. Did you wait for multipathd to finish before logging out? Multip

Antw: [PATCH 14/15] staging: greybus: make device_type const

>>> Bhumika Goyal schrieb am 19.08.2017 um 10:22 in >>> Nachricht <1503130946-2854-15-git-send-email-bhumi...@gmail.com>: > Make this const as it is only stored in the type field of a device > structure, which is const. Hi! I just have a comment on the patch description: What "this" and "it" re

Antw: Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

>>> Christoph Hellwig schrieb am 10.08.2017 um 11:32 in Nachricht <20170810093217.gl24...@lst.de>: > We can't use an on-stack buffer for the sense data, as drivers will > dma to it. So we should reuse the SCSI init_rq_fn() for the BSG Doesn't it just depend on WHEN the DMA is done? If the functi

Antw: Re: [RFC PATCH 4/6] bsg: refactor ioctl to use regular BSG-command infrastructure for SG_IO

>>> Johannes Thumshirn schrieb am 10.08.2017 um 10:24 in Nachricht <20170810082456.gi4...@linux-x5ow.site>: > On Wed, Aug 09, 2017 at 04:11:18PM +0200, Benjamin Block wrote: >> +return 0 == (bc->hdr.flags & BSG_FLAG_Q_AT_TAIL); > > return !(bc->hdr.flags & BSG_FLAG_Q_AT_TAIL); and make the fu

Re: Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

>>> Paul Koning schrieb am 05.07.2017 um 15:16 in Nachricht <8cc15605-cff3-4d6e-adbe-5efc9f8e7...@comcast.net>: >> On Jul 5, 2017, at 3:08 AM, Ulrich Windl > wrote: >> >>>>> Jeffrey Walton schrieb am 17.06.2017 um 16:23 in > Nachricht >

Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

>>> Jeffrey Walton schrieb am 17.06.2017 um 16:23 in >>> Nachricht : [...] > But its not clear to me how to ensure uniqueness when its based on > randomness from the generators. Even with a perfect random generator non-unique values are possible (that's why it's random). It's unlikely, but it

Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

>>> Stephan Müller schrieb am 26.06.2017 um 19:38 in Nachricht <1678474.gnybdsl...@tauon.chronox.de>: > Am Montag, 26. Juni 2017, 03:23:09 CEST schrieb Nicholas A. Bellinger: > > Hi Nicholas, > >> Hi Stephan, Lee & Jason, >> >> (Adding target-devel CC') >> >> Apologies for coming late to the d

Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

>>> "Jason A. Donenfeld" schrieb am 17.06.2017 um 02:41 in Nachricht : > Hi Lee, > > On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: >> It seems like what you are doing is basically "good", i.e. if there is >> not enough random data, don't use it. But what happens in that case? The >> authen

Antw: Diskless iSCSI boot Configuration

>>> schrieb am 15.05.2017 um 20:40 in Nachricht : > Hello guys, > I am trying to configure a diskless PC to boot through an iSCSI server. > I have already configure the iSCSI Target side and the PC through a Live > USB is accessed to the iSCSI target. With fdisk -l command, I can see the > dis

Antw: Re: [RFC] C/Python initiator userspace API approach.

>>> Christian Seiler schrieb am 26.04.2017 um 09:14 >>> in Nachricht : > On 04/26/2017 01:11 AM, Gris Ge wrote: >> B) Expand iscsid to listen on a socket for IPC with JSON output. >> Pro: >> * Easy to create language bindings via JSON + IPC. >> Con: >>

Antw: LTO-4 iSCSI performance less than expected ...

>>> schrieb am 27.03.2017 um 18:03 in Nachricht : > I'm connecting my Linux server to an LTO-4 tape drive over a 1 gigabit LAN > with very little other activity. > > Doing some hand waving, I guess that I should allow ten bits per byte and a > protocol overhead of around 40%. That gets me to a

Antw: Re: Problem with iSCSI connected LTO-2 tape drive

>>> Lee Duncan schrieb am 14.12.2016 um 20:18 in Nachricht <8286a277-f7fe-4c7d-a944-40034a0b5...@gmail.com>: > On Dec 12, 2016, at 5:46 AM, Dave partridge wrote: >> >> I just ran a Wireshark capture on the target system of the iSCSI session for > a Windows initiator connecting the tape and then

Antw: [PATCHv2 0/2] Handle iscsid shutdown more cleanly

>>> schrieb am 22.11.2016 um 23:42 in Nachricht : [...] > The second patch modifies iscsid to treat a > SIGTERM just like it had received the "immediate > stop" command from iscsiadm (via the "-k" > option), simplifying the shutdown of iscsid so > that it no longer requires IPC communications. Go

Antw: Re: RFC: iscsid shutdown hangs with system when service manually killed

>>> "Ulrich Windl" schrieb am 22.11.2016 um 08:43 in Nachricht <5834052f02a100023...@gwsmtp1.uni-regensburg.de>: [...] > I also think that a look with three "continue" and one "break" is a bit s/look/loop/ # user not fully awake ;-)

Antw: Re: RFC: iscsid shutdown hangs with system when service manually killed

>>> Lee Duncan schrieb am 21.11.2016 um 18:41 in Nachricht <6eda30f6-f37a-4e44-9d47-de265352b...@gmail.com>: >> On Nov 21, 2016, at 6:14 AM, Hannes Reinecke wrote: >> >> On 11/19/2016 08:46 PM, The Lee-Man wrote: >>> In this wonderful new world of systemd, I have an issue with stopping >>> the

Antw: RFC: iscsid shutdown hangs with system when service manually killed

If a human talks to a person that isn't there you call him/her crazy. If software talks to a process that isn't there, you call it a bug (I guess) ;-) To me the proper fix is to ensure iscsid is running before trying to talk to it (stop it) Ulrich >>> The Lee-Man schrieb am 19.11.2016 um 20:46

Antw: how to get iscsi target details(iqn) from device OS name programmatically at initiator side

>>> schrieb am 10.11.2016 um 11:16 in Nachricht <4e2f30b5-7c75-47d6-ad1e-2470b92bd...@googlegroups.com>: > > i need C/C++ library/API at initiator side which can give me the iscsi > target details(iqn) when i pass the OS device name or scsi-channel-lun > details. > > for example input will be

Antw: Open-Iscsi working

>>> Raghu Murugesan schrieb am 09.11.2016 um 00:18 in Nachricht <486524a5-8b14-4c0a-bf3f-b755b4561...@googlegroups.com>: > I want to understand how open-iscsi implements the RFC3720. I read RFC3720 > to understand how iscsi works. > > But I could understand how this RFC3720 is implemented in op

Antw: Re: [RFC 1/3] iscsid: Changes to support the new qedi transport

>>> Chris Leech schrieb am 19.10.2016 um 19:14 in Nachricht <20161019171452.iflp5nibq7yzi...@straylight.hirudinean.org>: > On Wed, Oct 19, 2016 at 01:02:18AM -0400, nilesh.jav...@cavium.com wrote: >> From: Nilesh Javali >> >> qedi is not attached to netdev hence avoid suppressing warnings. >> >

Antw: Re: Does iSCSI protocol have an integrated cache scheme?

hed using memory to cache the hot > data. > but iscsi driver has differences with normal block device, after all it's a > remote disk. > so i want to use a normal block device to act as a cache disk for iscsi > device besides using the normal memory cache. > do you have any

Antw: Does iSCSI protocol have an integrated cache scheme?

The iSCSI transport layer is definitely the wrong place to do caching! iSCSI devices are cached just as normal block devices are (unless you use direct I/O). >>> ??? schrieb am 10.10.2016 um 11:46 in Nachricht : > > does iSCSI protocol itself or open-source iSCSI implementations like > open-i

Antw: Re: [PATCH] iscsi_ibft,iscsi_boot: remove CAP_SYS_ADMIN restriction for reading entries

>>> Konrad Rzeszutek Wilk schrieb am 05.10.2016 um 01:23 in Nachricht : > On Oct 4, 2016 12:11 PM, "Dan Williams" wrote: >> >> On Tue, 2016-10-04 at 12:08 -0400, Peter Jones wrote: >> > On Tue, Oct 04, 2016 at 11:03:05AM -0500, Dan Williams wrote: >> > > >> > > All the iSCSI boot entries are read

Antw: Re: [PATCH] iscsi_ibft,iscsi_boot: remove CAP_SYS_ADMIN restriction for reading entries

>>> Dan Williams schrieb am 04.10.2016 um 18:11 in Nachricht <1475597465.21760.3.ca...@redhat.com>: > On Tue, 2016-10-04 at 12:08 -0400, Peter Jones wrote: >> On Tue, Oct 04, 2016 at 11:03:05AM -0500, Dan Williams wrote: >> > >> > All the iSCSI boot entries are read-only anyway; it's unclear why

Antw: Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

>>> The Lee-Man schrieb am 27.09.2016 um 03:50 in Nachricht : > Christoph Hellwig suggested we do away with the open-iscsi google group > (this group) and use linux-scsi. Obviously linux-scsi is more generic. > > Any thoughts on this? (removed others on the cc list). > > On Monday, September

Antw: Re: How to encrypt password store in nodes dir

>>> The Lee-Man schrieb am 21.09.2016 um 18:43 in Nachricht : > There is no option to encrypt the password and storing in that format. Also I think if somebodxy is root on the machine, he/she can do more dangerous things than reading the iSCSI passwords... > > On Friday, September 16, 2016 at

Antw: iscsi daemon in docker container

>>> "Serguei Bezverkhi (sbezverk)" schrieb am 08.03.2016 um 03:54 in Nachricht : > Hello, > > As per Michael Christie suggestion, I am reaching out to a wider audience. > I am trying to run iscsid inside of a Docker container but without using > systemd. When I start iscsid -d 8 -f, it fails w

Antw: Re: [PATCH] iscsi_tcp set SO_LINGER to abort connection for error handling

Hi! I always thought SO_LINGER only has an effect on connections that are (partially) closed only: So if there is some network outage on a TCP connection and the connection is still considered established, would it help? Regards, Ulrich >>> Chris Leech schrieb am 04.03.2016 um 06:00 in Nachri

Antw: persistant record layout and long DNS names

>>> Chris Leech schrieb am 19.02.2016 um 23:42 in Nachricht <20160219224215.422q6isrsar6v...@straylight.hirudinean.org>: > I was asked an interesting question recently, and thought I'd share it > here. I don't think it's critical to address right away, but surprising > and something to think about

Antw: [PATCH] Build system: sort object file lists

>>> Christian Seiler schrieb am 13.02.2016 um 01:05 >>> in Nachricht <56be734d.1000...@gmail.com>: > Hi, > > Debian is currently working on making the entire archive build > reproducibly. is a good > resource describing the motivation behind this effort. > > T

Antw: Re: [PATCH] make use of all 24 bits of ISID qualifier space

>>> Chris Leech schrieb am 10.02.2016 um 22:51 in Nachricht <20160210215131.ge9...@straylight.hirudinean.org>: [...] > Do we really want to do anything other than limit to the 24-bits that we > can place into an ISID? I think not having any "artificial" limits is a good idea. If we run out of m

Antw: Re: login times when scaling out targets (Re: ISID uniqueness)

>>> Chris Leech schrieb am 10.02.2016 um 03:53 in Nachricht <20160210025324.gb9...@straylight.hirudinean.org>: > On Tue, Feb 09, 2016 at 03:24:04PM -0800, Chris Leech wrote: >> But there may be more straightforward gains to be had in cleaning up the >> sysfs code. Every attribute read ends up in

Antw: iscsiadm didn't discovery the LUNs when LUN0 is removed

Hi! I don't know the recent specs, but years ago we had a disk system (not iSCSI) where the documentation said LUN 0 must always exist. So we created a small dummy LUN that nobody actually used, but it was visible to every system. Maybe that helps. Regards, Ulrich >>> RenShu Xiao schrieb am

Antw: Re: Possible issue in commit 659743b02c41 ("libiscsi: Reduce locking contention in fast path")

>>> Chris Leech schrieb am 06.11.2015 um 01:56 in Nachricht <20151106005608.ga18...@straylight.hirudinean.org>: [...] > Am I missing something, or is splitting a linked list across two locks a > major failing of this change? [...] Could you explain your question again for those that are not deep

Antw: systemd files for open-iscsi

Hi! A somewhat unrelated question: With all these partial orderings (specified by "before" and "After" in the systemd unit files) is there a test suite that tries all allowable combinations that fulfill the partial ordering? Just in case the ordering is too weak? Regards, Ulrich >>> The Lee-M

Antw: [PATCH v2 1/2] iscsid: Changes to support ping through iscsiuio

>>> schrieb am 09.07.2015 um 13:38 in >>> Nachricht <1436441896-7161-2-git-send-email-adheer.chandravan...@qlogic.com>: > From: Adheer Chandravanshi > > These changes are done in order to support ping operation for drivers > like bnx2i that use iscsiuio. > > Signed-off-by: Adheer Chandravanshi

Antw: Re: [PATCH] Reformat man page synopsis sections

;> >> Thanks for your suggestions. >> >> On 29.05.2015 08:49, Ulrich Windl wrote: >>> A comment on likes like this: >>>> +\fBiscsiadm\fR \-m discoverydb [ \-hV ] [ \-d debug_level ] [ \-P > printlevel ] >>> >>> I think such lines sho

Re: Antw: [PATCH 2/4] buildsys: respect CFLAGS and LDFLAGS from the outside

>>> Christian Seiler schrieb am 31.05.2015 um 11:32 in Nachricht <556ad51a.9080...@iwakd.de>: [...] > I disagree here vehemently that it's only useful for development (in > fact, I would assert that it's rather useless for development and only > really useful in production), but this would go off

Re: Antw: [PATCH 2/4] buildsys: respect CFLAGS and LDFLAGS from the outside

>>> Christian Seiler schrieb am 29.05.2015 um 12:43 in Nachricht <556842d3.8070...@iwakd.de>: > On 05/29/2015 08:19 AM, Ulrich Windl wrote: >> Some remarks on the CFLAGS thing: >> In one of my projects I used this approach for messing with CFLAGS: >> -- &g

Antw: [PATCH 4/4] Spelling and escaping error fixes.

Hi! A comment on likes like this: > +\fBiscsiadm\fR \-m discoverydb [ \-hV ] [ \-d debug_level ] [ \-P printlevel > ] I think such lines should be restructured for redability and better diff-ing like this: .B iscsiadm .B \-m discoverydb .RB [ \-hV ] .RB [ \-d .IR debug_level ] .RB [ \-P .IR pr

Antw: [PATCH 2/4] buildsys: respect CFLAGS and LDFLAGS from the outside

Hi! Some remarks on the CFLAGS thing: In one of my projects I used this approach for messing with CFLAGS: -- CFLAGS=-pthread CWARNFLAGS=-Wall -Wextra -Wshadow COPTFLAGS=-pipe -O2 CDEBUGFLAGS=-g -fstack-protector-all CFLAGS+=$(CWARNFLAGS) CFLAGS+=$(COPTFLAGS) #CFLAGS+=$(CDEBUGFLAGS) LDFLAGS=-lpthre

Q: automatic remove of down devices?

Hello! Today we rebooted our FibreChannel storage that is accessed via iSCSI. Since then (the storage is up again) syslog is filled with messages like these: ... Jan 16 14:30:31 o1 multipathd: VM-E2: sdbs - tur checker reports path is down Jan 16 14:30:31 o1 multipathd: cLVM-E2: sdbw - tur checke

Antw: [PATCH 4/5] iscsiuio CFLAGS fixes

>>> "Ulrich Windl" schrieb am 14.01.2015 um 08:45 in Nachricht <54b62c9d02a100018...@gwsmtp1.uni-regensburg.de>: >>>> Chris Leech schrieb am 12.01.2015 um 20:24 in Nachricht > <1421090651-8333-5-git-send-email-cle...@redhat.com>: >> try and

Antw: [PATCH 4/5] iscsiuio CFLAGS fixes

>>> Chris Leech schrieb am 12.01.2015 um 20:24 in Nachricht <1421090651-8333-5-git-send-email-cle...@redhat.com>: > try and keep existing CFLAGS from environment for packagers > --- > iscsiuio/configure.ac | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/iscsiuio/configur

Antw: [PATCH 2/5] add discovery as a valid mode in iscsiadm.8

>>> Chris Leech schrieb am 12.01.2015 um 20:24 in Nachricht <1421090651-8333-3-git-send-email-cle...@redhat.com>: > --- > doc/iscsiadm.8 | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/doc/iscsiadm.8 b/doc/iscsiadm.8 > index 9a945d1..05793b2 100644 > --- a/d

Antw: Issue seeing targets when using discovery with the IP Address.

Stupid question: What is the result of "nslookup "? Does it work as intended? >>> Jonathan Payne schrieb am 23.12.2014 um 14:59 in Nachricht <40060add-e3af-449d-93a0-b73ad54ed...@googlegroups.com>: > Hello everyone, > > > I'm having an issue with two Ubuntu servers in our ExacqVision security

Antw: Linux kernel development reports for the 3.17 release

>>> Greg KH schrieb am 14.12.2014 um 21:16 in Nachricht <20141214201653.ga18...@kroah.com>: [...] > Your email address shows up in the changelog for the 3.16 kernel > release as a contributor, but I can't seem to place it with a company. > If you don't mind, could you let me know what company you

Antw: Re: Slow dir / Performance.

Does "man blktrace" sound useful to you? With this command and others you can produce "funny output" like this: 9-1 AW271 68123744 16 153.802866844 1 1057 xfsbufd/dm-12 9-1 QW272 68123744 16 153.802871575 1 1057 xfsbufd/dm-12 9-1 AW273 16187603

Antw: Slow dir / Performance.

>>> schrieb am 02.12.2014 um 15:06 in Nachricht <5a7097b3-0dd7-4c28-abbf-ff66800b8...@googlegroups.com>: > We have 2 Equallogic Systems, And a Dell Servers. > > We have every server give a block device home dir , so the user data are on > the home dir this is working great its format on xfs file

  1   2   3   4   5   >