Scenario: - On the server there is a target pointing to a zvol which is partitioned with a BSD label: (on the server) # cd /dev/zvol/path # ls v905* v905 v905a v905b v905d - Now the ctld is started: # service ctld start - Then v905 seems to be opened in a way which makes the partitions disappear: # ls v905* v905 - But v905 remains visible even if I establish a session to it: (on the client) # iscsictl -A -n v905 (on the server) # ls v905* v905 Desired behavior: - v905 and all its partitions should remain visible until a client actually establishes a session to the target - Maybe v905 itself should become invisible while a client has a session established to it (this is debatable)
By the way, a positive remark + a thank you for the iscsi work: (on the client) % iscsictl -A -n v905 % mount /dev/da0d /mnt % bonnie -d /mnt/tmp/x -s 1024 File '/mnt/tmp/x/Bonnie.37415', size: 1073741824 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 1024 114260 50.4 113703 13.1 173854 14.7 253630 100.0 3363968 100.7 409290.9 242.6 % umount /mnt % iscsictl -R -n v905 (on the server, addressing the target directly as a mounted UFS) % service ctld stop (see bug #195585) % mount /dev/zvol/path/v905d /mnt % bonnie -d /mnt/tmp/x -s 1024 File '/mnt/tmp/x/Bonnie.41437', size: 1073741824 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 1024 165433 68.7 247671 51.7 448879 37.7 265097 100.0 3201309 101.0 336049.7 239.1 bonnie -d /mnt/tmp/x -s 1024 5.87s user 6.12s system 4335445% cpu 23.066 total % umount /mnt Nice performance on cheap hardware. The target is 20GB of a 6 x 2TB raidz2 zpool, with 2 partitions a and d. So again, thanks. -- Martin
Another example of the current limitations: - The server exports v9{01..20} via iSCSI - v914 contains a Windows installation - v916 contains an openSUSE installation - The v9xx are zfs zvols - openSUSE is running under VirtualBox, with iSCSI providing the disk so there is an open session to v916 - Windows is not running; there is not open session to v914 Now I want to do a rollback of the Windows disk: [0]# zfs rollback <path>/v914@<snapshot name> This results in cannot rollback '<path>/914': dataset is busy And I have to stop openSUSE, stop ctld, do the rollback, and restart ctld and openSUSE again. It would be much more convenient to just be able to perform the rollback, which would work if the v914 dataset were not marked busy by ctld.
I agree it would be a nice feature to have, but it looks very hard to implement - right now files and partitions are opened when they are configured (ie on ctld startup); implementing this feature would require passing the information about which LUNs are actually being "attached" from frontends, through LUN mapping layer, to the backends. Also, it wouldn't work when targets are exported via Fibre Channel, as those never actually log out, unless disabled or shutting down. The easiest way to work around it is simply to disable target in ctl.conf - comment it out, basically - then send SIGHUP to ctld ("pkill -HUP ctld"). After you're done, just uncomment the target and send SIGHUP again. Thanks for the benchmarks!