Re: FFSv2 log option with SD card
On 22/02/2020 4:28 am, Sad Clouds wrote: Hi, is it advisable to NOT enable log option for FFSv2 that resides on SD card due to flash memory wearing out in those regions, or does it make no practical difference because of built-in wear levelling? How long's a piece of string? Wear levelling just evens out the wear... surprise. It doesn't account for the overall wear. I read a document many years ago, where a 4kb cluster size for a 1 GB SD and 4kb writes per N seconds (where N was below 10, can't recall), and the estimated life of the SD card was 80 years. So, go ahead and enable logging. At worst you probably shorten its life by a few years. Of course, this all depends on the read/writing you're doing to the SD card. YMMV.
Re: iSCSI: NetBSD-9 target, Linux initiator
On Fri, Feb 21, 2020 at 07:46:26PM +0100, BERTRAND Joel wrote: > > In my experience the iscsi target (and the userland iscsi initiator) > > are pretty limited and somewhat broken. I suggest you use the > > iscsi target from pkgsrc (net/istgt). Much better, faster and more > > compatible. > > Same configuration files or not ? Unfortunately not. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: iSCSI: NetBSD-9 target, Linux initiator
On Fri, 21 Feb 2020 at 19:29, Chavdar Ivanov wrote: > > On Fri, 21 Feb 2020 at 18:46, BERTRAND Joel wrote: > > > > Michael van Elst a écrit : > > > joel.bertr...@systella.fr (BERTRAND Joel) writes: > > > > > >> If I understand... Error is triggered by test > > >> /usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c line > > >> 1405 when initiator sends data greater than 1MB. > > > > > >> Why this limitation ? > > > > > > Apparently to avoid allocating an arbitrary sized buffer. > > > > Yes, but why not allocate for example a 4MB buffer ? > > > > > In my experience the iscsi target (and the userland iscsi initiator) > > > are pretty limited and somewhat broken. I suggest you use the > > > iscsi target from pkgsrc (net/istgt). Much better, faster and more > > > compatible. > > Years ago, perhaps around NetBSD v.5 or 6, I tried the built-in iSCSI > target and found the same - it was, shall we say, rather flaky. I then > started using net/istgt, it worked for me as well. > > Lately, since I enabled it on one of my systems running -current of > the day with 2-3 updates a week, I've found the built-in target to be > reasonably ok, at least with initiators running on various Windows > versions; I haven't had any reason to try it with other initiators so > far. As I mentioned before, my extents are either /dev/rdkxx from a > GPT disk, or a ZFS zvols. I do get > src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:1364: ***ERROR*** > UNKNOWN OPCODE 0xa1 (or 0xdf or 0x9e), but they don't seem to affect > the operation. Performancewise, things are not so good - i have a > FreeNAS 11.3 on the same gigabit switch, from the same Windows 10 > initiator I get 2-4 times better figures (measured by > CrystalDiskMark), even if the FreeNAS server is only a guest on a > XCP-NG host, whereas the NetBSD machine is physicall; both with > gigabit interfaces. > > I should try again net/istgt just to check the performance figures. > > > > > > Same configuration files or not ? > > Definitely not... And here we are with the numbers... Michael is of course right about the performance. NetBSD-current, amd64 from yesterday, built-in iscsi-target: .. --- CrystalDiskMark 6.0.2 x64 (C) 2007-2018 hiyohiyo Crystal Dew World : https://crystalmark.info/ --- * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes Sequential Read (Q= 32,T= 1) : 9.148 MB/s Sequential Write (Q= 32,T= 1) : 3.197 MB/s Random Read 4KiB (Q= 8,T= 8) : 0.708 MB/s [172.9 IOPS] Random Write 4KiB (Q= 8,T= 8) : 0.241 MB/s [ 58.8 IOPS] Random Read 4KiB (Q= 32,T= 1) : 0.683 MB/s [166.7 IOPS] Random Write 4KiB (Q= 32,T= 1) : 0.307 MB/s [ 75.0 IOPS] Random Read 4KiB (Q= 1,T= 1) : 0.700 MB/s [170.9 IOPS] Random Write 4KiB (Q= 1,T= 1) : 0.284 MB/s [ 69.3 IOPS] Test : 50 MiB [G: 67.3% (20.2/30.0 GiB)] (x1) [Interval=5 sec] Date : 2020/02/21 20:23:43 OS : Windows 10 [10.0 Build 18363] (x64) . Same system, same target, using net/istgt: ... --- CrystalDiskMark 6.0.2 x64 (C) 2007-2018 hiyohiyo Crystal Dew World : https://crystalmark.info/ --- * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes Sequential Read (Q= 32,T= 1) :16.854 MB/s Sequential Write (Q= 32,T= 1) :10.903 MB/s Random Read 4KiB (Q= 8,T= 8) :12.360 MB/s [ 3017.6 IOPS] Random Write 4KiB (Q= 8,T= 8) :12.594 MB/s [ 3074.7 IOPS] Random Read 4KiB (Q= 32,T= 1) :12.185 MB/s [ 2974.9 IOPS] Random Write 4KiB (Q= 32,T= 1) :12.421 MB/s [ 3032.5 IOPS] Random Read 4KiB (Q= 1,T= 1) : 0.703 MB/s [171.6 IOPS] Random Write 4KiB (Q= 1,T= 1) : 0.571 MB/s [139.4 IOPS] Test : 50 MiB [G: 67.3% (20.2/30.0 GiB)] (x1) [Interval=5 sec] Date : 2020/02/21 20:23:21 OS : Windows 10 [10.0 Build 18363] (x64) . FreeNAS 11.3 target: --- CrystalDiskMark 6.0.2 x64 (C) 2007-2018 hiyohiyo Crystal Dew World : https://crystalmark.info/ --- * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes Sequential Read (Q= 32,T= 1) :18.639 MB/s Sequential Write (Q= 32,T= 1) :20.656 MB/s Random Read 4KiB (Q= 8,T= 8) : 9.985 MB/s [ 2437.7 IOPS] Random Write 4KiB (Q= 8,T= 8) :13.202 MB/s [ 3223.1 IOPS] Random Read 4KiB (Q= 32,T= 1) :10.803 MB/s [ 2637.5 IOPS] Random Write 4KiB (Q= 32,T= 1) :13.384 MB/s [
Re: Fwd: NetBSD 9.0 randomly boots
On 21/02/2020 18:10, Maxime Villard wrote: Le 21/02/2020 à 10:57, BERTRAND Joël a écrit : Maxime Villard a écrit : Hi, 1) How much ram does your system have? 16 GB 2) If you add "#define NO_X86_ASLR" at the top of sys/arch/x86/x86/pmap.c, does the system boot fine? I cannot try. Maybe the next week. Actually, you don't need to try this; I had a sudden doubt yesterday, but in the end it is fine and there is no problem. I have tried to reboot this server and I cannot obtain panic anymore (?). But kernel randomly enters in loop : [ 1.004775] pciide0: primary channel configured to native-PCI mode [ 1.004775] pciide0: using ioapic0 pin 18 for native-PCI interrupt [ 1.004775] atabus2 at pciide0 channel 0 [ 1.004775] pciide0: secondary channel configured to native-PCI mode [ 1.004775] atabus3 at pciide0 channel 1 [ 1.004775] i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 0412 (rev. 0x06) [ 1.004775] hdaudio0 at pci0 dev 3 function 0: HD Audio Controller [ 1.004775] hdaudio0: interrupting at msi1 vec 0 [ 1.004775] hdaudio0: autoconfiguration error: unsol: codec id 0x01 not valid [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured I see that as well on my 9.0 system fairly regularly. For me it doesn't panic very often and usually makes it out of the loop and boots. I can reproduce quite easily and I'm in a position to add debug and reboot the machine in question to reproduce if someone guides me on where it needs to go. :) Mike
Re: iSCSI: NetBSD-9 target, Linux initiator
On Fri, 21 Feb 2020 at 18:46, BERTRAND Joel wrote: > > Michael van Elst a écrit : > > joel.bertr...@systella.fr (BERTRAND Joel) writes: > > > >> If I understand... Error is triggered by test > >> /usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c line > >> 1405 when initiator sends data greater than 1MB. > > > >> Why this limitation ? > > > > Apparently to avoid allocating an arbitrary sized buffer. > > Yes, but why not allocate for example a 4MB buffer ? > > > In my experience the iscsi target (and the userland iscsi initiator) > > are pretty limited and somewhat broken. I suggest you use the > > iscsi target from pkgsrc (net/istgt). Much better, faster and more > > compatible. Years ago, perhaps around NetBSD v.5 or 6, I tried the built-in iSCSI target and found the same - it was, shall we say, rather flaky. I then started using net/istgt, it worked for me as well. Lately, since I enabled it on one of my systems running -current of the day with 2-3 updates a week, I've found the built-in target to be reasonably ok, at least with initiators running on various Windows versions; I haven't had any reason to try it with other initiators so far. As I mentioned before, my extents are either /dev/rdkxx from a GPT disk, or a ZFS zvols. I do get src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:1364: ***ERROR*** UNKNOWN OPCODE 0xa1 (or 0xdf or 0x9e), but they don't seem to affect the operation. Performancewise, things are not so good - i have a FreeNAS 11.3 on the same gigabit switch, from the same Windows 10 initiator I get 2-4 times better figures (measured by CrystalDiskMark), even if the FreeNAS server is only a guest on a XCP-NG host, whereas the NetBSD machine is physicall; both with gigabit interfaces. I should try again net/istgt just to check the performance figures. > > Same configuration files or not ? Definitely not... > > Best regards, > > JKB --
Re: iSCSI: NetBSD-9 target, Linux initiator
Michael van Elst a écrit : joel.bertr...@systella.fr (BERTRAND Joel) writes: If I understand... Error is triggered by test /usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c line 1405 when initiator sends data greater than 1MB. Why this limitation ? Apparently to avoid allocating an arbitrary sized buffer. Yes, but why not allocate for example a 4MB buffer ? In my experience the iscsi target (and the userland iscsi initiator) are pretty limited and somewhat broken. I suggest you use the iscsi target from pkgsrc (net/istgt). Much better, faster and more compatible. Same configuration files or not ? Best regards, JKB
Re: iSCSI: NetBSD-9 target, Linux initiator
joel.bertr...@systella.fr (BERTRAND Joel) writes: >If I understand... Error is triggered by test >/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c line >1405 when initiator sends data greater than 1MB. >Why this limitation ? Apparently to avoid allocating an arbitrary sized buffer. In my experience the iscsi target (and the userland iscsi initiator) are pretty limited and somewhat broken. I suggest you use the iscsi target from pkgsrc (net/istgt). Much better, faster and more compatible. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Fwd: NetBSD 9.0 randomly boots
Le 21/02/2020 à 10:57, BERTRAND Joël a écrit : Maxime Villard a écrit : Hi, 1) How much ram does your system have? 16 GB 2) If you add "#define NO_X86_ASLR" at the top of sys/arch/x86/x86/pmap.c, does the system boot fine? I cannot try. Maybe the next week. Actually, you don't need to try this; I had a sudden doubt yesterday, but in the end it is fine and there is no problem. I have tried to reboot this server and I cannot obtain panic anymore (?). But kernel randomly enters in loop : [ 1.004775] pciide0: primary channel configured to native-PCI mode [ 1.004775] pciide0: using ioapic0 pin 18 for native-PCI interrupt [ 1.004775] atabus2 at pciide0 channel 0 [ 1.004775] pciide0: secondary channel configured to native-PCI mode [ 1.004775] atabus3 at pciide0 channel 1 [ 1.004775] i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 0412 (rev. 0x06) [ 1.004775] hdaudio0 at pci0 dev 3 function 0: HD Audio Controller [ 1.004775] hdaudio0: interrupting at msi1 vec 0 [ 1.004775] hdaudio0: autoconfiguration error: unsol: codec id 0x01 not valid [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured ... [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] xhci0 at pci0 dev 20 function 0: vendor 8086 product 8cb1 (rev. 0x00) [ 1.004775] xhci0: interrupting at msi2 vec 0 [ 1.004775] xhci0: xHCI version 1.0 [ 1.004775] usb0 at xhci0: USB revision 3.0 [ 1.004775] usb1 at xhci0: USB revision 2.0 [ 1.004775] vendor 8086 product 8cba (miscellaneous communications) at pci0 Fwiw, I've seen this happen too, on a laptop, with hdaudio0. If you reboot the machine, the device seems to be keeping its previous "state", and is not reset. It looks like NetBSD doesn't reset it manually either. If you shut down your machine, wait a few seconds, and then boot it again cleanly, the problem never occurs. Maxime
Re: iSCSI: NetBSD-9 target, Linux initiator
If I understand... Error is triggered by test /usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c line 1405 when initiator sends data greater than 1MB. Why this limitation ? JKB
iSCSI: NetBSD-9 target, Linux initiator
Hello, My swap over iSCSI runs slowly. Very slowly. I have checked server log and I have found : Feb 21 18:20:12 legendre iscsi-target: > iSCSI Normal login successful from iqn.1993-08.org.debian:01:f44d59dfc4a1 on 192.168.10.103 disk 0, ISID 9613344773, TSIH 4359 Feb 21 18:20:12 legendre iscsi-target: pid 17370:/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:1405: ***ERROR*** bytec > 1081344m Feb 21 18:20:12 legendre iscsi-target: pid 17370:/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:1266: ***ERROR*** disk_write() failed Feb 21 18:20:12 legendre iscsi-target: pid 17370:/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/target.c:475: ***ERROR*** scsi_cmd.bytes_recv Feb 21 18:20:12 legendre iscsi-target: pid 17370:/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/target.c:1398: ***ERROR*** scsi_command_t() failed Feb 21 18:20:12 legendre iscsi-target: pid 17370:/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/target.c:1502: ***ERROR*** execute_t() failed Feb 21 18:20:14 legendre iscsi-target: > iSCSI Normal login successful from iqn.1993-08.org.debian:01:f44d59dfc4a1 on 192.168.10.103 disk 0, ISID 9613344773, TSIH 4360 Feb 21 18:20:14 legendre iscsi-target: pid 17370:/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:1405: ***ERROR*** bytec > 1134592m Feb 21 18:20:14 legendre iscsi-target: pid 17370:/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/disk.c:1266: ***ERROR*** disk_write() failed Feb 21 18:20:14 legendre iscsi-target: pid 17370:/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/target.c:475: ***ERROR*** scsi_cmd.bytes_recv Feb 21 18:20:14 legendre iscsi-target: pid 17370:/usr/src/netbsd-9/src/external/bsd/iscsi/lib/../dist/src/lib/target.c:1398: ***ERROR*** scsi_command_t() failed I'm not sure it was expected. If I understand, target returns an error and initiator tries a reconnection. I have done a tcmdump capture I can send here if required. How can I fix this trouble ? Regards, JKB
FFSv2 log option with SD card
Hi, is it advisable to NOT enable log option for FFSv2 that resides on SD card due to flash memory wearing out in those regions, or does it make no practical difference because of built-in wear levelling?
Re: ZFS status
On Fri, 21 Feb 2020 13:40:03 + David Brownlee wrote: > On Fri, 21 Feb 2020 at 10:45, Sad Clouds > wrote: > > > > Hi, anyone knows the current status of ZFS for recently released > > NetBSD-9? There is a message on the console - "WARNING: ZFS on > > NetBSD is under development". OK, but what does this mean? There is > > a good chance it may lose/corrupt data, or it's pretty stable but > > watch out for minor issues? > > I would say the latter - I'm using it on a couple of boxes and they > have had the usual selection of test cases - apps filling up file > systems, switching between zfs and legacy mount and back, the box > being rebooted with the disks on different ports, disks moved between > boxes, and at least one case with a disk from a set missing then added > back on next reboot. Not lost any data yet (though see note below on > disklabel partitions) OK thanks, this is good news.
Re: iSCSI target
Chavdar Ivanov writes: [snip] >> > You export raw partition device; if you want to have many targets from >> > one physical disk, you split the disk in any way you can - fdisk, >> > gpt/dkctl or ZFS zvols and export the raw varieties of those. >> >> I have tried to export /dev/rwd0e to only export a slice (created by >> disklabel). It doesn't work (and initiator is unable to use target). I >> haven't tested with a partition created by fdisk. > > If you have a good reason not to use zfs and zvols, then I'd suggest > gpt slices, wich definitely work. > > Zvols are best, IMHO, as you can snapshot them and send/receive them > elsewhere for backup. Pretty much any character based (raw) storage device is usable for iSCSI export, this would include raw zvols (/dev/zvol/rdsk/POOL_NAME/VOL_NAME), /dev/r and LVM (/dev/VG_NAME/rLV_NAME). I have used a couple of these personally with NetBSD and MS-WINDOWS. But as mentioned, unless you have a very specific reason, you will probably want to make sure that the entire device is exported. That is, you could export /dev/rsd0e where 'e' is not the entire device, but you may have more likely meant /dev/rsd0[c|d]. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: Getting NetBSD on this new machine
Todd mailed me photos off list, the error is: nouveau0: error: unknown chipset (16800a1) and later it fails (kernel page fault) in nvkm_vdevice_* Martin
Re: ZFS status
On Fri, 21 Feb 2020 at 10:45, Sad Clouds wrote: > > Hi, anyone knows the current status of ZFS for recently released > NetBSD-9? There is a message on the console - "WARNING: ZFS on NetBSD > is under development". OK, but what does this mean? There is a good > chance it may lose/corrupt data, or it's pretty stable but watch out > for minor issues? I would say the latter - I'm using it on a couple of boxes and they have had the usual selection of test cases - apps filling up file systems, switching between zfs and legacy mount and back, the box being rebooted with the disks on different ports, disks moved between boxes, and at least one case with a disk from a set missing then added back on next reboot. Not lost any data yet (though see note below on disklabel partitions) I've encountered two issues - I have one box where zfs does not work - trying to mount a new filesystem or existing one copied from another machine just panics - If you make a zfs filesystem on a disklabel partition (eg wd0f) and the disk moves zfs does not seem to be able to find it again. If you run MAKEDEV for the affected device into a new directory and point zfs at that then it picks up the disk. This gave me something of a scare. zfs best practice is to use raw devices, so this shouldn't be an issue for most people David
Re: iSCSI target
On Fri, 21 Feb 2020 at 13:20, BERTRAND Joël wrote: > > Chavdar Ivanov a écrit : > > On Fri, 21 Feb 2020 at 12:41, BERTRAND Joël > > wrote: > >> > >> With > >> > >> # extentfile or device start length > >> extent0 /dev/rwd0 0 32GB > >> > >> # targetflags storage netmask > >> target0 rw extent0 192.168.10.103/32 > >> > >> iscsid seems to run as expected. But if I want to export a second > >> target, how can I modify targets file ? I suppose I have to add > >> > >> extent1 /dev/rwd032GB+1sector 32GB > > > > You export raw partition device; if you want to have many targets from > > one physical disk, you split the disk in any way you can - fdisk, > > gpt/dkctl or ZFS zvols and export the raw varieties of those. > > I have tried to export /dev/rwd0e to only export a slice (created by > disklabel). It doesn't work (and initiator is unable to use target). I > haven't tested with a partition created by fdisk. If you have a good reason not to use zfs and zvols, then I'd suggest gpt slices, wich definitely work. Zvols are best, IMHO, as you can snapshot them and send/receive them elsewhere for backup. > > JKB --
Re: iSCSI target
Chavdar Ivanov a écrit : > On Fri, 21 Feb 2020 at 12:41, BERTRAND Joël wrote: >> >> With >> >> # extentfile or device start length >> extent0 /dev/rwd0 0 32GB >> >> # targetflags storage netmask >> target0 rw extent0 192.168.10.103/32 >> >> iscsid seems to run as expected. But if I want to export a second >> target, how can I modify targets file ? I suppose I have to add >> >> extent1 /dev/rwd032GB+1sector 32GB > > You export raw partition device; if you want to have many targets from > one physical disk, you split the disk in any way you can - fdisk, > gpt/dkctl or ZFS zvols and export the raw varieties of those. I have tried to export /dev/rwd0e to only export a slice (created by disklabel). It doesn't work (and initiator is unable to use target). I haven't tested with a partition created by fdisk. JKB
Re: iSCSI target
On Fri, 21 Feb 2020 at 12:41, BERTRAND Joël wrote: > > With > > # extentfile or device start length > extent0 /dev/rwd0 0 32GB > > # targetflags storage netmask > target0 rw extent0 192.168.10.103/32 > > iscsid seems to run as expected. But if I want to export a second > target, how can I modify targets file ? I suppose I have to add > > extent1 /dev/rwd032GB+1sector 32GB You export raw partition device; if you want to have many targets from one physical disk, you split the disk in any way you can - fdisk, gpt/dkctl or ZFS zvols and export the raw varieties of those. Im my case I have a 250GB disk which used to be GPT and split in some 10-12 partitions, some of which - 3 or 4 - were iSCSI exported; the rest were used by NVMM virtual machines. Lately I destroyed these and created a zpool in their place, now I am using zvols for the same purpose, e.g. my targets file is: ... extent0/dev/zvol/rdsk/pail/iscsia 0 30GB extent1 /dev/zvol/rdsk/pail/nbsd04GB # targetflags storage netmask target0 rw extent0 0.0.0.0/0 target1 rw extent1 0.0.0.0/0 The rest of the volumes are for VMs: ... zfs list -t volume [12:57:24] NAME USED AVAIL REFER MOUNTPOINT pail/f12 4.13G 13.6G 1.24G - pail/iscsia 30.9G 16.3G 25.4G - pail/lxmint 24.8G 20.5G 15.0G - pail/mxlinux 24.8G 16.3G 19.2G - pail/nbsd 4.13G 14.2G 714M - pail/omnios 24.8G 34.7G 785M - pail/openbsd 4.13G 14.1G 832M - pail/truecommand 20.6G 26.5G 4.90G - pail/w10 44.8G 37.7G 11.8G - pail/w19 30.9G 28.0G 13.7G - ... > target1 > > How can I configure extent1 to begin just after extent0 ? > > Regards, > > JKB --
Re: Getting NetBSD on this new machine
On Fri, Feb 21, 2020 at 07:13:03AM -0500, Todd Gruhn wrote: > At the end of the boot sequence, it drops me into the > kernel debugger. Give us a hint, what does it say? I would expect something like: panic: followed by a stack backtrace that might be longish. If in doubt, take a photo of the screen at the debugger prompt. Martin
Getting NetBSD on this new machine
I have a new box with a Gigabyte Z390 Gaming X motherboard. I comes with UEFI and UEFI-compatibility support module. At the end of the boot sequence, it drops me into the kernel debugger. This is an initial install -- I am currently running the latest version of Windoze. Any help would be greatly appreciated.
Re: iSCSI target
With # extentfile or device start length extent0 /dev/rwd0 0 32GB # targetflags storage netmask target0 rw extent0 192.168.10.103/32 iscsid seems to run as expected. But if I want to export a second target, how can I modify targets file ? I suppose I have to add extent1 /dev/rwd032GB+1sector 32GB target1 How can I configure extent1 to begin just after extent0 ? Regards, JKB
iSCSI target
Hello, I'm trying to configure a iSCSI target on a NetBSD 9.0. I have added a new disk in my NIS/NFS server that appears as /dev/rwd0. legendre# fdisk /dev/wd0 Disk: /dev/wd0d NetBSD disklabel disk geometry: cylinders: 310101, heads: 16, sectors/track: 63 (1008 sectors/cylinder) total sectors: 312581808, bytes/sector: 512 BIOS disk geometry: cylinders: 1024, heads: 255, sectors/track: 63 (16065 sectors/cylinder) total sectors: 312581808 Partitions aligned to 16065 sector boundaries, offset 63 Partition table: 0: NetBSD (sysid 169) start 63, size 312581745 (152628 MB, Cyls 0-19457/80/63) PBR is not bootable: All bytes are identical (0x00) 1: 2: 3: No active partition. Drive serial number: 1696063557 (0x6517e045) legendre# disklabel /dev/rwd0 # /dev/rwd0d: type: ESDI disk: wd0 label: fictitious flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 310101 total sectors: 312581808 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 5 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] c: 31258174563 unused 0 0# (Cyl. 0*- 310100) d: 312581808 0 unused 0 0# (Cyl. 0 - 310100) e: 6553600063 swap # (Cyl. 0*- 65015*) legendre# I want to only export /dev/wd0e. Thus, I have written in /etc/iscsi/targets : # extentfile or device start length extent0 /dev/rwd0e 0 32000MB # targetflags storage netmask target0 rw extent0 192.168.10.103/32 and restarted iscsid : Starting iscsi_target. Reading configuration from `/etc/iscsi/targets' target0:rw:192.168.10.103/32 extent0:/dev/rwd0e:0:33554432000 DISK: 1 logical unit (65536000 blocks, 512 bytes/block), type iscsi fs DISK: LUN 0: 32000 MB disk storage for "target0" TARGET: iSCSI Qualified Name (IQN) is iqn.1994-04.org.netbsd.iscsi-target On client side (Linux debian) : iscsiadm --mode node --targetname iqn.1994-04.org.netbsd.iscsi-target:target0 --portal 192.168.10.128 --login and I obtain in dmesg : [11435.508280] scsi host6: iSCSI Initiator over TCP/IP [11435.517173] scsi 6:0:0:0: Direct-Access NetBSD NetBSD iSCSI 0PQ: 0 ANSI: 3 [11435.517315] sd 6:0:0:0: Attached scsi generic sg1 type 0 [11435.517709] sd 6:0:0:0: [sdb] 65536000 512-byte logical blocks: (33.6 GB/31.3 GiB) [11435.517825] sd 6:0:0:0: [sdb] Write Protect is off [11435.517828] sd 6:0:0:0: [sdb] Mode Sense: 0e 00 00 08 [11435.518042] sd 6:0:0:0: [sdb] Incomplete mode parameter data [11435.518046] sd 6:0:0:0: [sdb] Assuming drive cache: write through [11435.722414] sd 6:0:0:0: [sdb] Attached SCSI disk But mkswap does't run as expected : root@hilbert:/etc/iscsi/nodes# mkswap /dev/sdb mkswap: /dev/sdb: warning: wiping old ext2 signature. Setting up swapspace version 1, size = 31,3 GiB (33554427904 bytes) no label, UUID=1573d8e2-4479-47fa-a1a2-b2398c8390c1 mkswap: write failed: Erreur d'entrée/sortie and fdisk returns : root@hilbert:/etc/iscsi/nodes# fdisk /dev/sdb Welcome to fdisk (util-linux 2.34). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/sdb: 31,26 GiB, 33554432000 bytes, 65536000 sectors Disk model: NetBSD iSCSI Geometry: 16 heads, 63 sectors/track, 310101 cylinders Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: bsd Slice Start End Sectors Size Type Fsize Bsize Cpg c63 312581807 312581745 149,1G unused 0 0 0 d 0 312581807 312581808 149,1G unused 0 0 0 e63 65536062 65536000 31,3G swap 0 0 0 Partition table entries are not in disk order. Command (m for help): I don't understand why whole disk seems to be accessible and why /var/log/syslog contains : [11732.405047] connection4:0: Got CHECK_CONDITION but invalid data buffer size of 0 [11732.405060] sd 6:0:0:0: [sdb] tag#28 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK [11732.405066] sd 6:0:0:0: [sdb] tag#28 CDB: Write(10) 2a 00 00 00 00 00 00 00 08 00 [11732.405069] print_req_error: I/O error, dev sdb, sector 0 [11732.405072] Buffer I/O error on dev sdb, logical block 0, lost async page write [11732.439371] connection4:0: Got CHECK_CONDITION but invalid data buffer size of 0 [11732.439382] sd 6:0:0:0: [sdb] tag#57 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK [11732.439387] sd 6:0:0:0: [sdb] tag#57 CDB: Write(10) 2a 00 00 00 00 00 00 00 08 00 [11732.439390] print_req_error: I/O error, dev sdb, sector 0 [11732.439393] Buffer I/O error on dev sdb, logical block 0, lost async page write Any
ZFS status
Hi, anyone knows the current status of ZFS for recently released NetBSD-9? There is a message on the console - "WARNING: ZFS on NetBSD is under development". OK, but what does this mean? There is a good chance it may lose/corrupt data, or it's pretty stable but watch out for minor issues?
Re: Fwd: NetBSD 9.0 randomly boots
Maxime Villard a écrit : > Hi, > > 1) How much ram does your system have? 16 GB > 2) If you add "#define NO_X86_ASLR" at the top of > sys/arch/x86/x86/pmap.c, does > the system boot fine? I cannot try. Maybe the next week. I have tried to reboot this server and I cannot obtain panic anymore (?). But kernel randomly enters in loop : [ 1.004775] pciide0: primary channel configured to native-PCI mode [ 1.004775] pciide0: using ioapic0 pin 18 for native-PCI interrupt [ 1.004775] atabus2 at pciide0 channel 0 [ 1.004775] pciide0: secondary channel configured to native-PCI mode [ 1.004775] atabus3 at pciide0 channel 1 [ 1.004775] i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 0412 (rev. 0x06) [ 1.004775] hdaudio0 at pci0 dev 3 function 0: HD Audio Controller [ 1.004775] hdaudio0: interrupting at msi1 vec 0 [ 1.004775] hdaudio0: autoconfiguration error: unsol: codec id 0x01 not valid [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured ... [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] unknown at hdaudio0 not configured [ 1.004775] xhci0 at pci0 dev 20 function 0: vendor 8086 product 8cb1 (rev. 0x00) [ 1.004775] xhci0: interrupting at msi2 vec 0 [ 1.004775] xhci0: xHCI version 1.0 [ 1.004775] usb0 at xhci0: USB revision 3.0 [ 1.004775] usb1 at xhci0: USB revision 2.0 [ 1.004775] vendor 8086 product 8cba (miscellaneous communications) at pci0 Best regards, JKB
Re: Cannot boot NetBSD under qemu-kvm
On 21/02/2020 03:38, Julien Savard wrote: Hi, it seems that since my last fedora upgrade ( 30 -> 31 ) I cannot boot any NetBSD Guest running on KVM-Qemu. Actual version on Fedora 31 is qemu-kvm-4.1.1-1. NetBSD 8.0/8.1 On HD hang on : "NetBSD/x86 ffsv2 Primary Bootstrap" NetBSD 9.0 booting on CD(iso) hangs on "acpicpu1: at cpu1: ACPI CPU". Booting with ACPI disabled ( boot -2) hangs on : "attimer0: attached to pcppi0" I tried on 2 different x86_64 hosts. One Intel ( Core 2) based and the other AMD (Opteron) based. Booting OpenBSD or Linux works wells Only NetBSD seems to be an issue. Has anybody experienced this issue? What's your full command line? This is mine: qemu-system-x86_64 \ -drive if=virtio,file=/home/oc/VM/img/netbsd.image,index=0,media=disk \ -M q35,accel=kvm -m 350M -cpu host -smp $(nproc) \ -nic user,hostfwd=tcp::6665-:22,model=virtio-net-pci,ipv6=off -nographic It is possible that you have to tweak the "M q35" parameter, if you moved from a previous version of qemu. "qemu-system-x86_64 -M help" will give you all the possible values. -- Ottavio Caruso
