Re: zfs, iSCSI and volmode=dev

[Edward Napierala]

2017-10-09 17:38 GMT+01:00 Eugene M. Zheganin <e...@norma.perm.ru>:

> Hi,
>
> On 27.09.2017 16:07, Edward Napierala wrote:
>
>> 2017-08-30 11:45 GMT+02:00 Eugene M. Zheganin <e...@norma.perm.ru > e...@norma.perm.ru>>:
>>
>> Hi,
>>
>>
>> I have an iSCSI production system that exports a large number of
>> zvols as the iSCSI targets. System is running FreeBSD
>> 11.0-RELEASE-p7 and initially all of the zvols were confugured
>> with default volmode. I've read that it's recommended to use them
>> in dev mode, so the system isn't bothered with all of these geom
>> structures, so I've switched all of the zvols to dev mode, then I
>> exported/imported the pools back. Surprisingly, the performance
>> has fallen down like 10 times (200-300 Mbits/sec against 3-4
>> Gbits/sec previously). After observing for 5 minutes the ESXes
>> trying to boot up, and doing this extremely slowly, I switched the
>> volmode back to default, then again exported/imported the pools.
>> The performance went back to normal.
>>
>>
>> So... why did this happen ? The result seems to be
>> counter-intuitive. At least not obvious to me.
>>
>>
>> I don't really have an answer - mav@ would be the best person to ask.
>> Based
>> on his description, "ZVOLs in GEOM mode don't support DPO/FUA cache
>> control
>> bits, had to chunk large I/Os into MAXPHYS-sized pieces and go through
>> GEOM."
>> There also used to be so that TRIM was only supported in the "dev" mode,
>> but
>> that changed a while ago.
>>
>> Yeah, but you mean dev is faster by design. So was my first thought too,
> but it seems like the opposite. Default volmode is geom, and it's much
> faster than dev.


I'd expect it to be faster, but it might be it interferes with something.
For example,
if Windows forces direct media access (bypassing the disk cache), and going
through
GEOM made the target ignore this bit, that could hurt performance.  (Note
that
it's just an idea; I have no idea what's actually happening there.)

My first suspect would be TRIM, but then it should work in both modes.
Might be worth
checking to be sure, by disabling the "unmap" option in ctl.conf (option
"unmap" "off")
to see if it makes a difference.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: automount usb msdosfs no partition table

[Edward Napierala]

2017-10-09 0:10 GMT+01:00 Tomasz CEDRO :

> Hello world :-)
>
> I need to configure automount for a testing machine. It seems to work
> fine, except for two issues:
>
> 1. Mount point does not disappear after device disappears, what makes
> things harder to script when device is gone. automount -c does not
> remove the mountpoint, only restarting the service does. It is a bug
> or feature?
>

Bug, or perhaps a missing feature.  No known workaround at this point,
I'm afraid.


> 2. Automounter does not mount USB Pendrive / MSDOSFS devices that does
> not have a parition table. Some USB Drives does not have valid
> partition table, they appear as /dev/da0 and can be mounted with
> mount_msdosfs /dev/da0 /mnt, but they are not recognised by
> automounter.. how can I make it work with such devices?
>

It should just work:

[trasz@v2:~]% ll /media
total 5
drwxr-xr-x   3 root  wheel   512 Oct  6 15:38 .
drwxr-xr-x  21 root  wheel  1024 Oct  5 23:58 ..
[trasz@v2:~]% doas mdconfig -s1g
md0
trasz@v2:~]% doas newfs_msdos /dev/md0
newfs_msdos: cannot get number of sectors per track: Operation not supported
newfs_msdos: cannot get number of heads: Operation not supported
/dev/md0: 2096576 sectors in 65518 FAT16 clusters (16384 bytes/cluster)
BytesPerSec=512 SecPerClust=32 ResSectors=1 FATs=2 RootDirEnts=512
Media=0xf0 FATsecs=256 SecPerTrack=63 Heads=255 HiddenSecs=0
HugeSectors=2097152
[trasz@v2:~]% ll /media
total 5
drwxr-xr-x   3 root  wheel   512 Oct  6 15:38 .
drwxr-xr-x  21 root  wheel  1024 Oct  5 23:58 ..
drwxr-xr-x   3 root  wheel   512 Oct 10 06:50 md0
[trasz@v2:~]%

With the pendrive plugged in, can you do "gpart show",
"/etc/autofs/special_media" (as root), and paste the output?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs, iSCSI and volmode=dev

[Edward Napierala]

2017-08-30 11:45 GMT+02:00 Eugene M. Zheganin :

> Hi,
>
>
> I have an iSCSI production system that exports a large number of zvols as
> the iSCSI targets. System is running FreeBSD 11.0-RELEASE-p7 and initially
> all of the zvols were confugured with default volmode. I've read that it's
> recommended to use them in dev mode, so the system isn't bothered with all
> of these geom structures, so I've switched all of the zvols to dev mode,
> then I exported/imported the pools back. Surprisingly, the performance has
> fallen down like 10 times (200-300 Mbits/sec against 3-4 Gbits/sec
> previously). After observing for 5 minutes the ESXes trying to boot up, and
> doing this extremely slowly, I switched the volmode back to default, then
> again exported/imported the pools. The performance went back to normal.
>
>
> So... why did this happen ? The result seems to be counter-intuitive. At
> least not obvious to me.


I don't really have an answer - mav@ would be the best person to ask.  Based
on his description, "ZVOLs in GEOM mode don't support DPO/FUA cache control
bits, had to chunk large I/Os into MAXPHYS-sized pieces and go through
GEOM."
There also used to be so that TRIM was only supported in the "dev" mode, but
that changed a while ago.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ctld: only 579 iSCSI targets can be created

[Edward Napierala]

Thanks for the packet trace.  What happens there is that the Windows
initiator logs in, requests Discovery ("SendTargets=All"), receives the list
of targets, as expected, and then... sends "SendTargets=All" again,
instead of logging off.  This results in ctld(8) dropping the session.
The initiator then starts the Discovery session again, but this time it only
logs in and then out, without actually requesting the target list.

Perhaps you could work around this by using "discovery-filter",
as documented in ctl.conf(5)?


2017-09-22 11:49 GMT+01:00 Eugene M. Zheganin :

> Hi,
>
> Edward Tomasz Napierała wrote 2017-09-22 12:15:
>
>>
>> There are two weird things here.  First is that the error is coming from
>> ctld(8) - the userspace daemon, not the kernel.  The second is that those
>> invalid opcodes are actually both valid - they are the Text Request,
>> and the Logout Request with Immediate flag set, exectly what you'd expect
>> for a discovery session.
>>
>> Do you have a way to do a packet dump?
>>
>
> Sure. Here it is:
>
> http://enaza.ru/stub-data/iscsi-protocol-error.pcap
>
> Target IP is 10.0.2.4, initiator IP is 10.0.3.127. During the session
> captured in this file I got in messages:
>
> Sep 22 15:38:11 san1 ctld[61373]: 10.0.3.127 
> (iqn.1991-05.com.microsoft:worker296):
> protocol error: received invalid opcode 0x4
> Sep 22 15:38:11 san1 ctld[61374]: 10.0.3.127 
> (iqn.1991-05.com.microsoft:worker296):
> protocol error: received invalid opcode 0x46
>
> This error happens when the initiator is trying to connect the disk from a
> target discovered.
>
> Target is running FreeBSD 11.0-STABLE #1 r310734M where M is for
> CTL_MAX_PORTS 1024 (old verion, yup, but I have a suspicion that I still
> failed to prove that more recent version have some iSCSI vs ZFS conflict,
> but that's another story). Initiator is running Windows 7 Professional x64,
> inside a ESX virtual machine. This happens only when some unclear threshold
> is crossed, previous ~2 hundreds of initiators run Windows 7 Professional
> too.
>
> If you need any additional data/diagnostics please let me know.
>
> Eugene.
>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Common Desktop Environment broken when compiling from ports tree on FreeBSD 12 RC3 (May also apply to the final build)

[Edward Napierala]

pon., 17 gru 2018 o 00:42 Alex McKeever 
napisał(a):
>
> I ran into problems compiling the CDE in FreeBSD 12.0 RC3 (PowerPC) on my 
> eMac. It says it is broken and cannot be compiled. Also, any ETA on when this 
> port of the OS will go into Tier 1? Compiling software, desktop environments, 
> X11, using 11.1 and the now unsupported 10.4 failed when I tried those a 
> while back (and personally I have been partial to Linux and how easily I can 
> just get software via APT or Zypper... I would be running Debian Sid if they 
> didn’t drop support for the eMac in terms of my internal display not working 
> after Jessie)

FWIW, the x11/cde port is not just broken on MIPS and PowerPC; it's marked
broken on FreeBSD 12 on all architectures.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"