Thank you. It's been fun just trying to find the right place to report this to :)
I have successfully set up tgtd with --device-type pt --bstype sg now. BluRay playback is working fine! But tgtd doesn't seem to like encrypted DVDs. On Tue, 30 Oct 2018 at 04:50, The Lee-Man <leeman.dun...@gmail.com> wrote: > > On Saturday, October 27, 2018 at 8:30:52 AM UTC-7, Ben Klein wrote: >> >> Hi, >> >> I've been trying to get a DVD-ROM drive working over iSCSI. I'm using >> targetcli on the target and iscsiadm/iscsi_discovery on the initiator. >> >> Target is running 4.18.16 unpatched from kernel.org, with AMD64 >> Devuan/Debian stable userland. 10 year old Core 2 Duo CPU. >> >> Initiator is running 4.18.15 unpatched from kernel.org with AMD64 >> Devuan/Debian unstable userland. Ryzen 7 CPU. >> >> Using pSCSI backend on /dev/sr0 triggers a memory leak that consumes all 5GB >> of system RAM on the target in a matter of seconds after attempting a read >> (I've been testing with "file -s") on the initiator side. It doesn't go into >> swap memory. >> >> I tested pSCSI and IBLOCK backends on a WD Green SSD, and found IBLOCK works >> fine (I was able to run mkfs.ext4 from the initiator without any memory leak >> on the target), but pSCSI still seems to trigger a memory leak, albeit a lot >> slower than with the DVD-ROM. I suspect udev might have something to do with >> this, as tries to read the volume label off optical discs on insertion. >> >> I have attached my targetcli output, and have configured my target-side >> kernel for coredumping and debugging. If someone can talk me through what to >> look for, I can poke around in the 5GB vmcore that gets produced by kdump. >> >> Please let me know if there's any other information I can provide. >> >> Thanks, >> Ben Klein > > > You would probably get more useful advise on the target-de...@vger.kernel.org > mailing list, since we mainly have initiator expertise here. They might have > even seen and fixed this issue. > > Never the less, you can try debugging the target driver. I believe the target > code uses dynamic debugging, which means you can enable the debugging at run > time, using the path /sys/kernel/debug/dynamic_debug/control. You can enable > debug printing for one or more lines, for a function, for a module, etc. > Pretty flexible. But it really helps to look at the code to see what is being > reported on (IMHO). > > I have recently used a similar setup to test tape over iscsi using the pscsi > backend, and I did not notice a memory leak like the one you're reporting, if > that helps. > > -- > 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. -- 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.
