Re: Should iscsid.service be enabled or disabled in a systemd environment
I'm running Ubuntu 18.04 LTS. Yes there is a iscsid.socket there that is active. So from what you said, I think I don't need to enable iscsid.service so that it's started at boot time, given that my iscsi usage is intermittent. THanks you lots for the clarification David On Sunday, 4 November 2018 17:36:58 UTC, The Lee-Man wrote: > > What distro are you running? The iscsid daemon has been set up for what > systemd calls "socket activation" in the upstream sources. > > For example, for SUSE, we have another service called iscsid.socket. For > socket activation, you need a "SERVICE.socket" unit, and a > "SERVICE.service" unit. > > For this to work, you must have the "socket" unit running and do not need > the regular service running. This means that systemd will watch the network > socket you specify, and start up your service if somebody tries to reach > it, which in turn means iscsid does not have to be running all the time. > This is particularly useful if you rarely use the service, but it's not > smart enough to stop the daemon when you're no longer using it. So once it > starts up, it stay running, and "systemctl status SERVICE" will show that > it is running. If you run "systemctl stop SERVICE", it will stop it (i.e. > the iscsid daemon in this case) but warn "can be started again by > SERVICE.socket" (or something like that). > > In answer to your question, there is nothing wrong with enabling the > service by default if you use it regularly. But if you have an > "iscsi.socket" file on your system, then you do not *have* to have iscsid > running to be able to use it. > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Should iscsid.service be enabled or disabled in a systemd environment
I'm not really up to speed with systemd and wanted to enable iscsi on my system. So I issued a "systemctl enable iscsid" after a reboot I saw it was running and was happy! But after some further reading I realised that systemd has an inetd-alike capability, and that iscsid should probably be started by traffic on the socket. So was I wrong to enable the service? IOW should I disable iscsid.service or leave it enabled? Many thanks David -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: LTO-4 iSCSI performance less than expected ...
Of course it turns out the data for that test was highly compressible. So the actual speed over the network was around 33-40MB/s Rumour has it that the Jumbo Frame capable ethernet cards arrive today. I'll let U know if that changes anything. Dave -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: LTO-4 iSCSI performance less than expected ...
Well that was interesting - I booted up the application I used for BU of my Windows systems and used that to backup this Linux box over the network to the iSCSI connected drive. Result using SW compression I was getting about 90-130MB/s So confused why dd etc. was so darn slow ... Dave On Saturday, 15 April 2017 11:05:25 UTC+1, david.p...@perdrix.co.uk wrote: > > Before doing the dd I issued: > > mt-st -f /dev/st0l setblk 65536 stsetoptions 0x8000 > > which was happily accepted, but it made no difference to the throughput. > > Looking at the server hosting the tape, the network was only running at > about 37% capacity (32MB/s). > > Zipping the output of dd and writing to the non-compression device killed > throughput (not enough CPU grunt to keep the pipeline fed :( > > I may need to get some new network cards that support jumbo frames! > > Dave > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: LTO-4 iSCSI performance less than expected ...
Before doing the dd I issued: mt-st -f /dev/st0l setblk 65536 stsetoptions 0x8000 which was happily accepted, but it made no difference to the throughput. Looking at the server hosting the tape, the network was only running at about 37% capacity (32MB/s). Zipping the output of dd and writing to the non-compression device killed throughput (not enough CPU grunt to keep the pipeline fed :( I may need to get some new network cards that support jumbo frames! Dave -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: LTO-4 iSCSI performance less than expected ...
Thanks Lee, It would appear that stoptions and setstoptiosn are synonyms. 35 is the command code for MTWEOFI not the mask for enabling it as you say. I misread the header file. So yes 0x8000 seems to be correct. I'll give it a try. Dave -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: LTO-4 iSCSI performance less than expected ...
Let's try another tack. Will "mt-st -f /dev/st0l /stoptions 35" turn on MTWEOFI? Dave -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: LTO-4 iSCSI performance less than expected ...
I don't know? How do I find out? Should I have it set? > > Have you set the Write Immediate Filemark option for the st driver? > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: LTO-4 iSCSI performance less than expected ...
Hi there, Uli, Yes I did listen to the drive - no it wasn't shoe-shining. DD direct gave a slightly slower throughput. Dave -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
LTO-4 iSCSI performance less than expected ...
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 about 60MB/s which I know is about half what the drive is capable of. However what I'm seeing is a consistent throughput of about 30MB/s which is quite a lot slower that I'd expect. The processor is an Intel Atom D525 1.80Ghz four core processor with 4GB RAM. The drive I'm backing up is a SATA SSD. The backup is run thus: sudo mt-st -f /dev/st0l setblk 65536 sudo dd bs=64k if=/dev/sdb | mbuffer -s 65536 -m -m 50% -P 80 -o /dev/st0l Is what I'm seeing pretty much the norm, or is there something I can do to get better throughput? Thanks in advance for any assistance you can provide. Dave -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Problem with iSCSI connected LTO-2 tape drive
Lee, It would appear that the guilty party was: node.conn[0].timeo.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 I changed both of these to 0 for the tape device and the problem went away. Please note that the README.gz for open-scsi doesn't actually say that this is what you need to do to disable the NOP-out polling, so could I suggest that this be stated explicitly. I must admit that I find it hard to imagine that an iSCSI target would reply to a NOP-out while it was processing a command such as a tape fsf or even tape erase (whose timeout is 6 * the long-timeout of 4 hours). Should perhaps the NOP-out polling be suspended while a command is being processed? Or alternatively maybe the NOP-out polling be completely disabled by default with something in the README.gz file that explains WHEN you might want it and how to enable it. It's certainly clear that (at least) the MS iSCSI initiator doesn't send NOP-out polls. Regards Dave Regards Dave On Wednesday, 14 December 2016 19:18:16 UTC, The Lee-Man wrote: > > >Also, you may want to disable the Ping/NOOPs that open-iscsi is setting. > This is also discussed in the README file. I’d try setting them both >to 0 > to get them out of the way. It looks like the tape drive does not respond > to the NOOP ping when it is busy for 80+ seconds skipping forward >one > file. > > — > Lee Duncan > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Problem with iSCSI connected LTO-2 tape drive
Ulrich is correct, the scsi timeouts for tape drives are a *lot* longer. The short timeout is 900 seconds and the long timeout is 14400 seconds (4 hours). The IOCTL error message is occurring after 15 seconds, which I think points at the iSCSI layer. Cheers Dave Partridge -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
