Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Tue, Jun 4, 2024 at 3:52 PM John Hixson wrote: > > On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote: > > On 16/06/2022 15:56, Rick Macklem wrote: > > > Miroslav Lachman <000.f...@quip.cz> wrote: > > > > On 24/01/2022 16:13, Rick Macklem wrote: > > > > > > > [...] > > > > > > > > > So, I think Mark and Yuri are correct and looking at up to date > > > > > Illumos sources is the next step. > > > > > (As I mentioned, porting the Apple sources is beyond what I am > > > > >willing to attempt.) > > > > > > > > > > rick > > > > > > > > Hello Rick, > > > > I would like to ask you I there is some progress with porting newer > > > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a > > > > possibility where to start porting? > > > Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date > > > and I agree that it should be easier than the Apple stuff to port into > > > FreeBSD. I don't think it is "straightforward" as someone involved > > > with Illumos said, due to the big differences in VFS/locking, but... > > > > > > Having said the above, I have not done much yet. I've been cleaning up > > > NFS stuff, although I am nearly done with that now. > > > I do plan on starting to work on it soon, but have no idea if/when I > > > will have something that might be useful for others. > > > > I'm glad to hear that. > > > > > > We have more and more problems with current state of mount_smbfs. I > > > > would be really glad if "somebody" can do the heroic work of > > > > implementing SMBv2 in FreeBSD. > > > > Maybe it's time to start some fundraising for sponsoring this work? > > > Well, funding isn't an issue for me (I'm just a retired guy who does this > > > stuff as a hobby). However, if there is someone else who is capable of > > > doing it if they are funded, I have no problem with that. > > > I could either help them, or simply stick with working on NFS and leave > > > SMBv23 to them. > > > > > > Sorry, but I cannot report real progress on this as yet, rick > > > > No need to sorry. I really appreciate your endless work on NFS and that you > > still have kind of interest to try porting SMBv2/3. > > Unfortunately I don't know anybody else trying to do this tremendous work. > > > > I am working on a from scratch implementation of smbfs. I do not have > any kind of time estimate since it is in my spare time. I chose this > route after spending considerable time looking at Apple and Solaris > implementations and wanting something without all of the legacy 1.0 > crap. I do have a very minimal working FUSE version at this point, but > there is much to do, and even more to abide by the various > specifications. > > I just thought I'd share in case anyone is interested. > > - John I am indeed interested. smbfs is an important feature to have. Let me know if you need help with the fuse parts. -Alan
Re: ZPool on iSCSI storage not available after a reboot
On Tue, Mar 12, 2024 at 1:28 PM Dennis Clarke wrote: > > > This is a somewhat odd problem and may have nothing to do with iSCSI > config at all. Suffice it to say that I have the following in the server > /etc/rc.conf : > > # > # the iSCSI initiator > iscsid_enable="YES" > iscsictl_enable="YES" > iscsictl_flags="-Aa" > # > > During boot I see this on the console : > > > cannot import 'proteus': no suchpid 55 (zpool) is attempting to use > unsafe AIO requests - not logging anymore > pool or dataset > Destroy and re-create the pool from > a backup source. > cachefile import failed, retrying > no pools available to import > > > Sure enough the machine brings up a 10Gbit link with jumboframes *after* > the above messages : > > > ix0: flags=1008843 > metric 0 mtu 9000 > > options=4e53fbb > ether 8c:dc:d4:ae:18:b8 > inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 > media: Ethernet autoselect (10Gbase-Twinax > ) > status: active > nd6 options=29 > > > Then a little later I see iscsi doing its goodness : > > > da0 at iscsi1 bus 0 scbus8 target 0 lun 0 > da0: Fixed Direct Access SPC-5 SCSI device > da0: Serial Number MYSERIAL > da0: 150.000MB/s transfers > da0: Command Queueing enabled > da0: 2097152MB (4294967296 512 byte sectors) > add net ::0.0.0.0: gateway ::1 > Starting iscsid. > Starting iscsictl. > > The storage exists just fine and iSCSI seems to be doing its thing : > > root@titan:~ # > root@titan:~ # camcontrol devlist > at scbus0 target 0 lun 0 (pass0,ada0) > at scbus1 target 0 lun 0 (pass1,ada1) >at scbus2 target 0 lun 0 (ses0,pass2) >at scbus6 target 0 lun 0 (ses1,pass3) > at scbus7 target 0 lun 1 (pass4,nda0) > at scbus8 target 0 lun 0 (da0,pass5) > root@titan:~ # > root@titan:~ # gpart show da0 > =>40 4294967216 da0 GPT (2.0T) >40 8 - free - (4.0K) >48 42949672001 freebsd-zfs (2.0T) >4294967248 8 - free - (4.0K) > > root@titan:~ # > > However the zpool therein is not seen : > > root@titan:~ # > root@titan:~ # zpool list > NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP > HEALTH ALTROOT > iota 7.27T 597G 6.68T- - 0% 8% 1.00x > ONLINE - > t0 444G 40.8G 403G- - 4% 9% 1.00x > ONLINE - > root@titan:~ # > > > Of course I can manually import it : > > > root@titan:~ # zpool import > pool: proteus > id: 15277728307274839698 >state: ONLINE > status: Some supported features are not enabled on the pool. > (Note that they may be intentionally disabled if the > 'compatibility' property is set.) > action: The pool can be imported using its name or numeric identifier, > though > some features will not be available without an explicit 'zpool > upgrade'. > config: > > proteus ONLINE >da0p1 ONLINE > root@titan:~ # > > It seems as if there is something out of sequence and the iSCSI > processes should be happening earlier in the boot process? I really do > not know and am wondering why that zpool proteus on the iSCSI storage > needs to be manually import'ed after a reboot. > > Any insights would be wonderful. > > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken Yes, this looks exactly like an ordering problem. zpools get imported early in the boot process, under the assumption that most of them are local. Networking comes up later, under the assumption that networking might require files that are mounted on ZFS. For you, I suggest setting proteus's cachefile to a non-default location and importing it from /etc/rc.local, like this: zpool set cachefile=/var/cache/iscsi-zpools.cache proteus Then in /etc/rc.local: zpool import -a -c /var/cache/iscsi-zpools.cache -o cachefile=/var/cache/iscsi-zpools.cache -Alan
Re: something magic about the size of a ports tree
With ZFS, you might be using transparent compression. "du -sh" will show you a file's compressed size. But "ls -lh" will show you the logical size. That's probably why the tarball looked so much bigger than the ports tree on the first system. If you do "du -sh" on the tarball, I bet you'll see a much smaller number. On Tue, Oct 3, 2023 at 9:27 AM Matthias Apitz wrote: > > El día martes, octubre 03, 2023 a las 06:14:23p. m. +0200, Olivier Certner > escribió: > > > Hi Matthias, > > > > Some ZFS dataset with zstd compression on jet, and no compression on > > c720-1400094? > > > > Yes, on jet it is ZFS: > > root@jet:/usr/local/poudriere/ports # mount | grep ports2023 > poudriere/poudriere/ports/ports20230806 on > /usr/local/poudriere/ports/ports20230806 (zfs, local, noatime, nfsv4acls) > > on c720-1400094 it is only plain UFS. > > matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub >
Re: ZFS deadlock in 14
On Tue, Aug 8, 2023 at 10:08 AM Dag-Erling Smørgrav wrote: > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > August) and is 100% reproducable just by starting poudriere bulk in a > 16-core VM and waiting a few hours until deadlkres kicks in. In the > latest instance, deadlkres complained about a bash process: Do you have ZFS block cloning enabled on your pool? There were a lot of bugs associated with that feature. I think that was merged on 3-April. > zpool get feature@block_cloning zroot NAME PROPERTY VALUE SOURCE zroot feature@block_cloning disabled local
Re: No new FreeBSD images on Google Cloud since 13-April
On Mon, Jun 19, 2023 at 12:11 PM Alan Somers wrote: > > New builds of stable/13, stable/12, and current used to appear in > Google Cloud about once per week. But the latest builds all date from > 13-April-2023. Does some script need to be kicked? To see the > currently available images, do: > > pkg install google-cloud-sdk > gcloud compute images list --project freebsd-org-cloud-dev > --no-standard-images The situation just got worse. As a result of the libssl-3.0 upgrade on 14, all 14.0 images on google cloud are now basically useless. Among other problems, this means that most downstream projects' CI workflows on FreeBSD 14 are broken now. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272354
No new FreeBSD images on Google Cloud since 13-April
New builds of stable/13, stable/12, and current used to appear in Google Cloud about once per week. But the latest builds all date from 13-April-2023. Does some script need to be kicked? To see the currently available images, do: pkg install google-cloud-sdk gcloud compute images list --project freebsd-org-cloud-dev --no-standard-images
Re: what do I do when git cherry-pick works, but results are bogus?
On Wed, May 17, 2023 at 9:44 AM Rick Macklem wrote: > > So, the subject line basically says it. > I do a git cherry-pick to MFC. It works, but the resultant file(s) are not > correct. What do I do to fix this? > (If the merge fails, then it's easy, but there doesn't seem to be an option > on cherry-pick that forces it into "merge failed", so you can edit/add the > file > and then "git cherry-pick --continue".) > > Thanks for any help with this, rick After a cherry-pick that doesn't give you quite what you want, edit the file until it has the correct contents, then do "git commit --amend /path/to/file".
Re: [FUSEFS] File close() failures relating to attempted atime update
Thanks for the head's up. Hopefully I'll be able to look at it later this week. On Mon, Apr 10, 2023 at 4:40 PM Jamie Landeg-Jones wrote: > > There is a replicable problem with file closing on fusefs, since > 0bade34633f997c22f5e4e0931df0d534f560a38, Alan Somers > 2021-11-29 01:53:31 + > > It appears to be related to attempting to update atime on a file you > don't have write-access to. > > I've posted much more details, and a potential fix to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270749 > > Cheers, Jamie
Re: textdumps are too slow
On Fri, Apr 7, 2023, 4:07 PM Rodney W. Grimes wrote: > > On Fri, Apr 7, 2023 at 12:08?PM Warner Losh wrote: > > > > > > > > > > > > On Fri, Apr 7, 2023 at 6:20?AM Poul-Henning Kamp > wrote: > > >> > > >> > > >> Alan Somers writes: > > >> > On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp < > p...@phk.freebsd.dk> wrote: > > >> > > >> > > I would expect them to be limited by the serial console speed > before > > >> > > the video system speed ? > > >> > > > >> > That was my first guess, too. But my serial console is 115200 baud, > > >> > which is faster than the low performance server grade video card. > > >> > > >> Ok, that must truly be sucky hardware... > > > > > > > > > That's 10x slower than 1990s era VGA cards then... 115200 is 11k > characters a second, > > > and FreeBSD on 1990s era VGA cards was in excess of 1MB/s, faster if > not a pure ISA > > > card... Video hardware that's slower than *THAT* likely indicates a > big big problem in > > > our video stack. > > > > > > Warner > > > > While I'm logged into the video terminal in a normal login session, I > > measure about 28M characters/second. So maybe the slow speed is due > > to something inefficient in ddb(4). > > Do you mean to a physically connected vga display and usb/ps2 connected > keyboard, or do you mean a serially connected video terminal, or something > else like a console created by a BMC? > > One other thing that could be at issue is a console redirection via > serial port, that can make "VGA device" performance appear abismal. > > > -- > Rod Grimes > rgri...@freebsd.org It's a BMC video console. I'm also using a BMC serial port, but during panic I measured the serial port as faster than the video port. >
Re: textdumps are too slow
On Fri, Apr 7, 2023 at 12:08 PM Warner Losh wrote: > > > > On Fri, Apr 7, 2023 at 6:20 AM Poul-Henning Kamp wrote: >> >> >> Alan Somers writes: >> > On Fri, Apr 7, 2023 at 2:22=E2=80=AFAM Poul-Henning Kamp >> > wrote: >> >> > > I would expect them to be limited by the serial console speed before >> > > the video system speed ? >> > >> > That was my first guess, too. But my serial console is 115200 baud, >> > which is faster than the low performance server grade video card. >> >> Ok, that must truly be sucky hardware... > > > That's 10x slower than 1990s era VGA cards then... 115200 is 11k characters a > second, > and FreeBSD on 1990s era VGA cards was in excess of 1MB/s, faster if not a > pure ISA > card... Video hardware that's slower than *THAT* likely indicates a big big > problem in > our video stack. > > Warner While I'm logged into the video terminal in a normal login session, I measure about 28M characters/second. So maybe the slow speed is due to something inefficient in ddb(4).
Re: textdumps are too slow
On Fri, Apr 7, 2023 at 2:22 AM Poul-Henning Kamp wrote: > > ---- > Alan Somers writes: > > > However, these servers also have about 10,000 threads > > apiece, so textdumps are also slow. They take tens of minutes. > > I have dual console setup: both serial and video. It seems to me that > > the speed of the textdump might be limited by the video system. > > I would expect them to be limited by the serial console speed before > the video system speed ? That was my first guess, too. But my serial console is 115200 baud, which is faster than the low performance server grade video card.
Re: textdumps are too slow
On Thu, Apr 6, 2023 at 9:08 AM Alan Somers wrote: > > I have servers with lots of RAM yet slow swap disks. So full crash > dumps are too slow. Instead, I use textdumps, which are theoretically > much faster. However, these servers also have about 10,000 threads > apiece, so textdumps are also slow. They take tens of minutes. I > have dual console setup: both serial and video. It seems to me that > the speed of the textdump might be limited by the video system. So is > there anyway to capture a textdump without printing everything to the > console? textdump(4) implies that there isn't; you must print stuff > to console in order to capture it, and you must capture in order to > dump. Would somebody please tell me that I'm wrong? > > -Alan I'll answer my own question. It turns out that ddb can mute the console, just like "conscontrol mute on" would. That makes textdumps much much faster. The command is "write cn_mute 1". So to use this trick, write the following to /etc/ddb.conf: script kdb.enter.panic=textdump set; capture on; write cn_mute 1; run lockinfo; show pcpu; bt; ps; alltrace; capture off; textdump dump; reset
textdumps are too slow
I have servers with lots of RAM yet slow swap disks. So full crash dumps are too slow. Instead, I use textdumps, which are theoretically much faster. However, these servers also have about 10,000 threads apiece, so textdumps are also slow. They take tens of minutes. I have dual console setup: both serial and video. It seems to me that the speed of the textdump might be limited by the video system. So is there anyway to capture a textdump without printing everything to the console? textdump(4) implies that there isn't; you must print stuff to console in order to capture it, and you must capture in order to dump. Would somebody please tell me that I'm wrong? -Alan
head's up: disk physical paths changing
I'm planning to commit a change to the format of disk physical paths, as reported by DIOCGPHYSPATH, and viewable by "diskinfo -v". This will only affect disks in a SES enclosure (which are most SAS enclosures with more than about 8 slots). Technically, this is a backwards-incompatible change. But I only know of two cases that are likely to be affected: * If anybody uses a /dev/enc@... device alias in /etc/fstab, they'll need to update it. * If anybody is using zfsd with autoreplace-by-physical-path, *and* happens to have a disk missing at the time they install this change, then zfsd won't autoreplace it when they replace the disk. They'll have to replace the disk manually with "zpool replace". If you think this will be a problem, or if you've thought of any more cases I haven't, then speak up. I'll commit in 2 weeks if nobody objects. https://reviews.freebsd.org/D39141
Re: RFC: Should fspacectl() commit changes to stable storage?
On Mon, Feb 6, 2023 at 6:23 PM Rick Macklem wrote: > > PR#269328 reports an issue related to fspacectl() being > mixed with mmap'd I/O. > > When working on a fix for this for the NFS client, I realized that > "man fspacectl" does not clarify if the deallocation should commit > changes to stable storage before returning success. > vop_stddeallocate() currently does not do this so, if a machine > crashes immediately after fspacectl() returns success, the hole > may not be there when the machine reboots. > > For POSIX writes, it is clear that recently written data may be > lost when a machine crashes/reboots and fsync(2) is used to > ensure the data is on stable storage and won't be lost when a > crash/reboot occurs. > > The question is "Should fsync(2) be required to ensure a hole > punched by fspacectl(2) is not lost or should it be guaranteed > to not be lost when fspacectl(2) returns? > Since fspacectl(2) is FreeBSD specific and there is no standard, > it could be defined either way. > > So, what do you think? rick It think it should be just like write. An fsync should be required to ensure that the effects will be visible after a reboot.
Re: py-libzfs build failure on current, zpool_search_import() missing
Thanks! But for the record, what was the actual required change? Could you like to the PR? On Thu, Feb 2, 2023 at 8:44 AM Ryan Moeller wrote: > > I've updated the py-libzfs port to fix the build. > > -- > Ryan Moeller > iXsystems, Inc. > OS Developer > Email: r...@ixsystems.com
Re: py-libzfs build failure on current, zpool_search_import() missing
Unfortunately libzfs doesn't have a stable API, so this kind of breakage is to be expected. libzfs_core does, but libzfs_core is incomplete. You should report this problem upstream at https://github.com/truenas/py-libzfs . On Thu, Feb 2, 2023 at 2:37 AM Alexander Leidinger wrote: > > Hi, > > the build of py-libzfs fails on -current due to a missing > zpool_search_import(), and as such iocage can not be build (and the > old iocage segfaults, so the ABI seems to have changed too). The > symbol is available in libzutil, but I can not find > zpool_search_import() in /usr/include. > > Anyone with an idea if there is something missing (maybe something to > be installed into /usr/include), or what needs to be done to py-libzfs? > > Bye, > Alexander. > > -- > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
Re: What to do about a few lines in vfs_domount() never executed?
If you're 100.0% percent sure that it will never be run, you can
delete it. But if you're only 99.9%, then I suggest converting it
into a KASSERT.
On Tue, Dec 13, 2022 at 3:20 PM Rick Macklem wrote:
>
> Hi,
>
> While working on getting mountd/nfsd to run in a vnet
> prison, I came across the following lines near the
> beginning of vfs_domount() in sys/kern/vfs_mount.c:
>
> if (fsflags & MNT_EXPORTED) {
> error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED);
> if (error)
>return (error);
> }
>
> #1 - Since MNT_EXPORTED is never set in fsflags, this code never
> gets executed.
> --> I am asking what to do with the above code, since that
> changes for the patch that allows mountd to run in a vnet
> prison.
> #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0
> because nothing in sys/kern/kern_priv.c checks
> PRIV_VFS_MOUNT_EXPORTED.
>
> I don't know what the original author's thinking was w.r.t. this.
> Setting exports already checks that the mount operation can be
> done by the requestor.
>
> So, what do you think should be done with the above code snippet?
> - Consider it cruft and delete it.
> - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?
> - Leave it as is. After the patch that allows mountd to run in
> a vnet prison, MNT_EXPORTED will be set in fsflags, but the
> priv_check() call will just return 0. (A little overhead,
> but otherwise no semantics change.)
>
> rick
>
Re: RFC: nfsd in a vnet jail
> I don't care for any of it. It looks like additional overhead with the > addition of potential security risks. All for a very limited (and as yet > unknown) use case. Here's an example of a real-world use case. I'm responsible for supporting multiple products involving NFS, iSCSI, and other protocols. For security reasons, each product is placed on its own VLAN. Sometimes it's not practical to dedicate a physical server to a single product, so I have to double-up. For the products that don't involve NFS or iSCSI, I place them in a VNET jail. That way their processes can only access the correct VLAN. But NFS and iSCSI can't (yet) be jailed, so those products need to be served by JID 0. Therefore, those products' processes can access each other's VLANs. Clearly that's not ideal. Jailing different products is also good for manageability. It's easier to manage the list of packages that must be installed for each product, config file settings, etc. For example, some of our NFS products require vfs.nfsd.enable_stringtouid=1, but others could work without it. Right now, we're forced to turn it on for all products. -Alan
Re: RFC: nfsd in a vnet jail
On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem wrote: > > > > On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson wrote: >> >> Keep the global variables as defaults that apply to all nfsds and allow (at >> least some subset) to be overridden inside the net jails if some things need >> to be changed from the defaults? >> > This is pretty much a reply to one of the posts selected at random, > but I thought that better than starting a new email thread. > > bz@ and asomers@ have both asked about running mountd within a vnet prison > (one via offlist email and the other on phabricator). > > I think it is worth discussing here... > mountd (rightly or wrongly) does two distinctly different things: > 1 - It pushes the exports into the kernel via nmount() so they > can be hung off of the "struct mount" for a file system's > mount point. > --> This can only work for file system mount points and can > only be done once for any given file system mount point. > > At this time, I have it done once globally outside of the prisons. > The alternative I can see is doing it within each prison, but I > think that would require that each prison have its own file system(s). > (ie. The prison's root would always be a file system mount point.) > > 2 - It handles RPC Mount protocol requests from NFSv3 clients. This one > is NFSv3 specific, which is why I have done this NFSv4 only at > this time. To do this, it must be able to register with rpcbind, > and I have no idea if running rpcbind in a vnet jail is practical. > > Enforcing the use for separate file systems for each jail also makes > things safer, since the exports are enforced by the kernel. Without > this, a malicious NFSv4 client could "guess" a file handle for a file > outside the jail and gain access to that file. Put another way, without > a separate file system, there is no way to stop a malicious client from > finding files above the Root file handle. (Normal clients will use > PutRootFH and LookupParent and these won't be able to go above the top > of the jail.) > > So, what do others think of enforcing the requirement that each jail > have its own file systems for this? I think that's a totally reasonable requirement. Especially so for ZFS users, who already create a filesystem per jail for other reasons. > > rick > >> >> - Peter >> >> >> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem wrote: >>> >>> Hi, >>> >>> bz@ has encouraged me to fiddle with the nfsd >>> so that it works in a vnet jail. >>> I have now basically done so, specifically for >>> NFSv4, since NFSv3 presents various issues. >>> >>> What I have not yet done is put global variables >>> in the vnet. This needs to be done so that the nfsd >>> can be run in multiple jail instances and/or in and >>> outside of a jail. >>> The problem is that there are 100s of global variables. >>> >>> I can see two approaches: >>> 1 - Move them all into the vnet jail. This would imply >>> that all the sysctls need to somehow be changed, >>> which would seem to be a POLA violation. >>> It also implies a lot of stuff in the vnet. >>> 2 - Just move the global variables that will always >>> differ from one nfsd to another (this would make >>> the sysctls global and apply to all nfsds). >>> This will keep the number of globals in the vnet >>> smaller. >>> >>> I am currently leaning towards #2, put what do others >>> think? >>> >>> rick >>> ps: Personally, I don't know what use there is of >>> running the nfsd inside a vnet jail, but bz@ has >>> some use case. >> >>
Re: RFC: nfsd in a vnet jail
On Fri, Nov 25, 2022, 4:24 PM Rick Macklem wrote: > Hi, > > bz@ has encouraged me to fiddle with the nfsd > so that it works in a vnet jail. > I have now basically done so, specifically for > NFSv4, since NFSv3 presents various issues. > > What I have not yet done is put global variables > in the vnet. This needs to be done so that the nfsd > can be run in multiple jail instances and/or in and > outside of a jail. > The problem is that there are 100s of global variables. > > I can see two approaches: > 1 - Move them all into the vnet jail. This would imply > that all the sysctls need to somehow be changed, > which would seem to be a POLA violation. > It also implies a lot of stuff in the vnet. > 2 - Just move the global variables that will always > differ from one nfsd to another (this would make > the sysctls global and apply to all nfsds). > This will keep the number of globals in the vnet > smaller. > > I am currently leaning towards #2, put what do others > think? > > rick > ps: Personally, I don't know what use there is of > running the nfsd inside a vnet jail, but bz@ has > some use case. > This is super-awesome! Thank you so much! I've got a use case too. I think it would be fine to leave most of the settings global, like max_threads. But we should probably decide on a case by case basis . > >
Re: Good practices with bectl
On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira wrote:
>
> Hello to all,
>
> I will use becl for the first time for current upgrades.
> Just to check that I'm thinking correctly:
>
> Create a test environment for upgrade:
> > bectl create -r test (should I use '-r'?)
> Activate test:
> > bectl activate test
> > reboot
> ...
> > upgrade OS on test
> > reboot
> ...
> if a problem happens, reboot default from BE loader
> ---
> if everything fine destroy default and rename test to default
> > bectl destroy -o default
> > bectl rename test default
> repeat on next upgrade
>
> Don't know if a faster way exists with chroot or bectl jail...
>
> Any hints appreciated.
>
> Thanks,
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
I don't think you need to use "-r". Also, you're forgetting one of
the best things about boot environments: you can upgrade them even
when not booted into them. That's faster than upgrading the running
BE. Here is the procedure I use:
RELEASE=Whatever
sudo bectl create ${RELEASE}
sudo bectl mount ${RELEASE}
BASEDIR=/tmp/be_mount.# Use mount point returned by bectl mount
sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
upgrade -r ${RELEASE}
sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
# Ignore admonitions to reboot, since we're using a boot environment
sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
sudo bectl activate ${RELEASE}
sudo reboot
This general procedure works just as well if you're upgrading from source, too.
sudo make DESTDIR=${BASEDIR} installworld
sudo mergemaster -m $PWD -D $BASEDIR -U
-Alan
Re: Header symbols that shouldn't be visible to ports?
On Wed, Sep 7, 2022 at 8:55 AM Cy Schubert wrote: > > In message om> > , Alan Somers writes: > > On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov > > wro > > te: > > > > > > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote: > > > > Our /usr/include headers define a lot of symbols that are used by > > > > critical utilities in the base system like ps and ifconfig, but aren't > > > > stable across major releases. Since they aren't stable, utilities > > > > built for older releases won't run correctly on newer ones. Would it > > > > make sense to guard these symbols so they can't be used by programs in > > > > the ports tree? There is some precedent for that, for example > > > > _WANT_SOCKET and _WANT_MNTOPTNAMES. > > > _WANT_SOCKET is clearly about exposing parts of the kernel definitions > > > for userspace code that wants to dig into kernel structures. Similarly > > > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable. The > > > definitions are guarded by additional defines not due to their > > > instability, > > > but because using them in userspace requires (much) more preparation from > > > userspace environment, which is either not trivial (_WANT_SOCKET) or > > > contradicts to standartized use of the header (_WANT_MNTOPTNAMES + > > > sys/mount.h). > > > > > > > > > > > I'm particular, I'm thinking about symbols like the following: > > > > MINCORE_SUPER > > > Why this symbol should be hidden? It is implementation-defined and > > > intended to be exposed to userspace. All MINCORE_* not only MINCORE_SUPER > > > are under BSD_VISIBLE braces, because POSIX does not define the symbols. > > > > Because it isn't stable. It changed for example in rev 847ab36bf22 > > for 13.0. Programs using the older value (including virtually every > > Rust program) won't work on 13.0 and later. > > > > > > > > > TDF_* > > > These symbols coming from non-standard header sys/proc.h. If userspace > > > includes the header, it is already outside any formal standard, and I > > > do not see a reason to make the implementation more convoluted there. > > > > > > > PRI_MAX* > > > > PRI_MIN* > > > > PI_*, PRIBIO, PVFS, etc > > > > IFCAP_* > > > These are all implementation-specific and come from non-standard headers, > > > unless I am mistaken, then please correct me. > > > > > > > RLIM_NLIMITS > > > > IFF_* > > > Same. > > > > > > > *_MAXID > > > This is too broad. > > > > I'm talking about symbols like IPV6CTL_MAXID, which record the size of > > sysctl lists. Obviously, these symbols can't be stable, and probably > > aren't useful outside of the base system. > > > > > > > > > > > > > Clearly delineating private symbols like this would ease the > > > > maintenance burden on languages that rely on FFI, like Ruby and Rust. > > > > FFI basically assumes that symbols once defined will never change. > > > > > > Why e.g. sys/proc.h is ever consumed by FFI wrappers? > > > > I should add a little detail. Rust uses FFI to access C functions, > > and #define'd constants are redefined in the Rust bindings. For most > > Rust programs, the build process doesn't check the contents of > > /usr/include in any way. Instead, all of that stuff is hard-coded in > > the Rust bindings. That makes cross-compiling a breeze! But it does > > cause problems when the C library changes. Adding a new symbol, like > > copy_file_range, isn't so bad. If your Rust program doesn't use it, > > then the Rust binding will become an unused symbol and get eliminated > > by the linker. If your Rust program does use it OTOH, then it will be > > resolved by the dynamic linker at runtime - if you're running on > > FreeBSD 13 or newer. Otherwise, your program will fail to run. A > > bigger problem is with symbols that change. For example, the 64-bit > > inode stuff. Rust programs still use a FreeBSD 11 ABI (we're working > > on that). But other symbols change more frequently. Things like > > PRI_MAX_REALTIME can change between any two releases. That creates a > > big maintenance burden to keep track of them in the FFI bindings. And > > they also aren't very useful in cross-compiled programs targeting a > > FreeBSD 11 ABI. Instead, they really need to have bindings > > automatically generated at bu
Re: Header symbols that shouldn't be visible to ports?
On Tue, Sep 6, 2022 at 9:07 AM Warner Losh wrote: > > > > On Tue, Sep 6, 2022 at 7:34 AM Konstantin Belousov > wrote: >> >> On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote: >> > On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov >> > wrote: >> > > >> > > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote: >> > > > Our /usr/include headers define a lot of symbols that are used by >> > > > critical utilities in the base system like ps and ifconfig, but aren't >> > > > stable across major releases. Since they aren't stable, utilities >> > > > built for older releases won't run correctly on newer ones. Would it >> > > > make sense to guard these symbols so they can't be used by programs in >> > > > the ports tree? There is some precedent for that, for example >> > > > _WANT_SOCKET and _WANT_MNTOPTNAMES. >> > > _WANT_SOCKET is clearly about exposing parts of the kernel definitions >> > > for userspace code that wants to dig into kernel structures. Similarly >> > > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable. The >> > > definitions are guarded by additional defines not due to their >> > > instability, >> > > but because using them in userspace requires (much) more preparation from >> > > userspace environment, which is either not trivial (_WANT_SOCKET) or >> > > contradicts to standartized use of the header (_WANT_MNTOPTNAMES + >> > > sys/mount.h). >> > > >> > > > >> > > > I'm particular, I'm thinking about symbols like the following: >> > > > MINCORE_SUPER >> > > Why this symbol should be hidden? It is implementation-defined and >> > > intended to be exposed to userspace. All MINCORE_* not only >> > > MINCORE_SUPER >> > > are under BSD_VISIBLE braces, because POSIX does not define the symbols. >> > >> > Because it isn't stable. It changed for example in rev 847ab36bf22 >> > for 13.0. Programs using the older value (including virtually every >> > Rust program) won't work on 13.0 and later. >> As Mark replied, older values still mostly work. It was considered to >> not make unacceptable ABI change. >> >> > >> > > >> > > > TDF_* >> > > These symbols coming from non-standard header sys/proc.h. If userspace >> > > includes the header, it is already outside any formal standard, and I >> > > do not see a reason to make the implementation more convoluted there. >> > > >> > > > PRI_MAX* >> > > > PRI_MIN* >> > > > PI_*, PRIBIO, PVFS, etc >> > > > IFCAP_* >> > > These are all implementation-specific and come from non-standard headers, >> > > unless I am mistaken, then please correct me. >> > > >> > > > RLIM_NLIMITS >> > > > IFF_* >> > > Same. >> > > >> > > > *_MAXID >> > > This is too broad. >> > >> > I'm talking about symbols like IPV6CTL_MAXID, which record the size of >> > sysctl lists. Obviously, these symbols can't be stable, and probably >> > aren't useful outside of the base system. >> The programs are not forced to use the symbols. FFI bindings should not >> provide them, why do we need to specifically hide such defines? Because if anybody ever adds it to the libc crate, then it's basically stuck there forever. There's precedent for hiding defines like this: https://reviews.freebsd.org/D25816 >> >> > >> > > >> > > > >> > > > Clearly delineating private symbols like this would ease the >> > > > maintenance burden on languages that rely on FFI, like Ruby and Rust. >> > > > FFI basically assumes that symbols once defined will never change. >> > > >> > > Why e.g. sys/proc.h is ever consumed by FFI wrappers? >> > >> > I should add a little detail. Rust uses FFI to access C functions, >> > and #define'd constants are redefined in the Rust bindings. For most >> > Rust programs, the build process doesn't check the contents of >> > /usr/include in any way. Instead, all of that stuff is hard-coded in >> > the Rust bindings. That makes cross-compiling a breeze! >> Well, at the cost of the maintaining Rust libc crate. >> [Sorry, cannot refrain https://kib.kiev.ua/kib/rust_c_ffi.png ] >> >> > But it does >> > cause problems
Re: Header symbols that shouldn't be visible to ports?
On Mon, Sep 5, 2022 at 8:53 AM Mark Johnston wrote: > > On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote: > > On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov > > wrote: > > > > > > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote: > > > > Our /usr/include headers define a lot of symbols that are used by > > > > critical utilities in the base system like ps and ifconfig, but aren't > > > > stable across major releases. Since they aren't stable, utilities > > > > built for older releases won't run correctly on newer ones. Would it > > > > make sense to guard these symbols so they can't be used by programs in > > > > the ports tree? There is some precedent for that, for example > > > > _WANT_SOCKET and _WANT_MNTOPTNAMES. > > > _WANT_SOCKET is clearly about exposing parts of the kernel definitions > > > for userspace code that wants to dig into kernel structures. Similarly > > > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable. The > > > definitions are guarded by additional defines not due to their > > > instability, > > > but because using them in userspace requires (much) more preparation from > > > userspace environment, which is either not trivial (_WANT_SOCKET) or > > > contradicts to standartized use of the header (_WANT_MNTOPTNAMES + > > > sys/mount.h). > > > > > > > > > > > I'm particular, I'm thinking about symbols like the following: > > > > MINCORE_SUPER > > > Why this symbol should be hidden? It is implementation-defined and > > > intended to be exposed to userspace. All MINCORE_* not only MINCORE_SUPER > > > are under BSD_VISIBLE braces, because POSIX does not define the symbols. > > > > Because it isn't stable. It changed for example in rev 847ab36bf22 > > for 13.0. Programs using the older value (including virtually every > > Rust program) won't work on 13.0 and later. > > Why won't they work? Code that tests (vec[i] & MINCORE_SUPER) using the > old value will still give the same result when running on a newer > kernel, since MINCORE_PSIND(1) is 0x20, the old MINCORE_SUPER value. > This isn't to say that the change was perfectly backwards compatible, > but I haven't seen an example of code which was broken by the change. Well, from mincore(2): In particular, applications compiled using the old value of MINCORE_SUPER will not identify large pages with size index 2 as being large pages.
Re: Header symbols that shouldn't be visible to ports?
On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov wrote: > > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote: > > Our /usr/include headers define a lot of symbols that are used by > > critical utilities in the base system like ps and ifconfig, but aren't > > stable across major releases. Since they aren't stable, utilities > > built for older releases won't run correctly on newer ones. Would it > > make sense to guard these symbols so they can't be used by programs in > > the ports tree? There is some precedent for that, for example > > _WANT_SOCKET and _WANT_MNTOPTNAMES. > _WANT_SOCKET is clearly about exposing parts of the kernel definitions > for userspace code that wants to dig into kernel structures. Similarly > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable. The > definitions are guarded by additional defines not due to their instability, > but because using them in userspace requires (much) more preparation from > userspace environment, which is either not trivial (_WANT_SOCKET) or > contradicts to standartized use of the header (_WANT_MNTOPTNAMES + > sys/mount.h). > > > > > I'm particular, I'm thinking about symbols like the following: > > MINCORE_SUPER > Why this symbol should be hidden? It is implementation-defined and > intended to be exposed to userspace. All MINCORE_* not only MINCORE_SUPER > are under BSD_VISIBLE braces, because POSIX does not define the symbols. Because it isn't stable. It changed for example in rev 847ab36bf22 for 13.0. Programs using the older value (including virtually every Rust program) won't work on 13.0 and later. > > > TDF_* > These symbols coming from non-standard header sys/proc.h. If userspace > includes the header, it is already outside any formal standard, and I > do not see a reason to make the implementation more convoluted there. > > > PRI_MAX* > > PRI_MIN* > > PI_*, PRIBIO, PVFS, etc > > IFCAP_* > These are all implementation-specific and come from non-standard headers, > unless I am mistaken, then please correct me. > > > RLIM_NLIMITS > > IFF_* > Same. > > > *_MAXID > This is too broad. I'm talking about symbols like IPV6CTL_MAXID, which record the size of sysctl lists. Obviously, these symbols can't be stable, and probably aren't useful outside of the base system. > > > > > Clearly delineating private symbols like this would ease the > > maintenance burden on languages that rely on FFI, like Ruby and Rust. > > FFI basically assumes that symbols once defined will never change. > > Why e.g. sys/proc.h is ever consumed by FFI wrappers? I should add a little detail. Rust uses FFI to access C functions, and #define'd constants are redefined in the Rust bindings. For most Rust programs, the build process doesn't check the contents of /usr/include in any way. Instead, all of that stuff is hard-coded in the Rust bindings. That makes cross-compiling a breeze! But it does cause problems when the C library changes. Adding a new symbol, like copy_file_range, isn't so bad. If your Rust program doesn't use it, then the Rust binding will become an unused symbol and get eliminated by the linker. If your Rust program does use it OTOH, then it will be resolved by the dynamic linker at runtime - if you're running on FreeBSD 13 or newer. Otherwise, your program will fail to run. A bigger problem is with symbols that change. For example, the 64-bit inode stuff. Rust programs still use a FreeBSD 11 ABI (we're working on that). But other symbols change more frequently. Things like PRI_MAX_REALTIME can change between any two releases. That creates a big maintenance burden to keep track of them in the FFI bindings. And they also aren't very useful in cross-compiled programs targeting a FreeBSD 11 ABI. Instead, they really need to have bindings automatically generated at build time. That's possible, but it's not the default. So what the Rust community really needs is a way to know which symbols will be stable across releases, and which might vary. Are you suggesting that anything from a non-POSIX header file should be considered variable?
Header symbols that shouldn't be visible to ports?
Our /usr/include headers define a lot of symbols that are used by critical utilities in the base system like ps and ifconfig, but aren't stable across major releases. Since they aren't stable, utilities built for older releases won't run correctly on newer ones. Would it make sense to guard these symbols so they can't be used by programs in the ports tree? There is some precedent for that, for example _WANT_SOCKET and _WANT_MNTOPTNAMES. I'm particular, I'm thinking about symbols like the following: MINCORE_SUPER TDF_* PRI_MAX* PRI_MIN* PI_*, PRIBIO, PVFS, etc IFCAP_* RLIM_NLIMITS IFF_* *_MAXID Clearly delineating private symbols like this would ease the maintenance burden on languages that rely on FFI, like Ruby and Rust. FFI basically assumes that symbols once defined will never change. -Alan
Re: panic: make_dev_alias_v: bad si_name
On Sat, Jun 4, 2022 at 1:04 PM Warner Losh wrote:
>
>
>
> On Sat, Jun 4, 2022, 11:13 AM Yuri wrote:
>>
>> Getting the following panic on HPE system with HPE enclosure:
>>
>> panic: make_dev_alias_v: bad si_name (error=22,
>> si_name=enc@n../type@0/slot@1/elmdesc@{"Name":"DriveBay1"}/pass4)
>>
>> db_trace_self_wrapper()
>> vpanic()
>> panic()
>> make_dev_alias_v()
>> make_dev_alias_p()
>> make_dev_physpath_alias()
>> pass_add_physpath()
>> taskqueue_run_locked()
>> taskqueue_thread_loop()
>> fork_exit()
>> fork_trampoline()
>>
>> I have skipped typing all the frame information as the cause of panic
>> seems to be apparent -- enclosure replies with "Name":"DriveBay1" via
>> ses (it does the same weirdness for sensors and other elements), and
>> make_dev_alias_v() does not like the double quotes. Probably we need to
>> sanitize the input somewhere?
>
>
>
> Likely. I'll take a look. Can you file a bug, include CAM in the title and
> cc imp@ please?
>
> Warner
Also, it would help to include the output of "sg_ses -p7 /dev/sesXXX",
where sg_ses comes from sysutils/sg3_utils.
Re: Upgrade automation
On Tue, May 10, 2022 at 9:08 AM Cristian Cardoso wrote: > > Hi > > I have some FreeBSD servers in my machine park and I would like to perform > the version upgrade in an automated way with ansible. > > In my example, I want to perform the upgrade from version 12.3 to 13, it is > possible to run the upgrade with the command below: > > freebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE > > I ask this, because I don't know if it's the most correct way to execute this. > > Grateful for any assistance. Yes, that's perfect. But there's another step too. You'll have to do: freebsd-update install And _this_ step isn't easy to perfectly automate, because etcupdate may ask for your input when it merges config files. If you know exactly which etc files you've modified, you can add them to IgnorePaths. That way etcupdate won't run interactively, it will simply throw away changes from upstream. Whenever I need to upgrade multiple machines at once, I start tmux, split it into multiple panes, ssh to each server from one pane, then do ":synchronize-panes on" so my input will be directed to multiple panes simultaneously. Usually, that works for 90% of the upgrade. But invariably there are a few files that aren't synchronized between the servers, and I have to desynchronize my panes to deal with that. -Alan
Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery
On Thu, Apr 28, 2022 at 1:29 PM Marek Zarychta wrote: > > W dniu 28.04.2022 o 21:21, FreeBSD User pisze: > > Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to > > rescue them and > > store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD > > 12.3 obviously > > lack in some etx2 features, namely "needs_recovery". The kernel reports: > > > > WARNING: mount of da4p3 denied due to unsupported optional features: > > needs_recovery > > > > How can this problem be solved? > > > > Thanks in advance, > > > > oh > > > Probably as the name of the mailing list suggest you should upgrade to > 14.0-CURRENT and maybe run fsck.ext2(8) on this partition to fix it. > > -- > Marek Zarychta > You might also try sysutils/fusefs-ext2 from ports.
fspacectl meets DIOCGDELETEE
fspacectl(2) does for regular files the same thing that DIOCGDELETE does for GEOM devices. The only differences are that DIOCGDELETE requires the operation to be block-aligned, and if interrupted DIOCGDELETE doesn't give feedback about partial progress. Can we connect the two? That would allow a user to free space with a single API for both files and devices. It would require: * Adding a d_fspacectl_t member to struct cdevsw * Implementing d_fspacectl_t for g_dev_cdevsw by using DIOCGDELETE * Implementing .fo_fspacectl for devfs * Optionally implementing d_fspacectl on other device types, like zvols. -Alan
Fixing VOP_READDIR for 64-bit directory cookies
tldr; this change allows the NFS server to export file systems that use 64-bit directory cookies https://reviews.freebsd.org/D33404 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260375 Long story: NFSv2 included a 32-bit directory cookie with each readdir entry. NFSv3 widened it to 64-bits, and FreeBSD's SVN r22521 raised VOP_READDIR's cookies argument to a u_long. That's 64-bits on some architectures, but 32-bits on others. But since the NFS server is the only caller that uses cookies, VOP_READDIR really ought to use a 64-bit type on all architectures. For NVSv2-exported file systems, the NFS server will ignore the top 32-bits of the cookie. There are no in-tree file systems that use more than 32 bits for their directory cookies, but it matters for some FUSE file systems. Does anybody have any opinions about this change, or about whether/how to MFC it? -Alan
Re: root passwd lost
On Sun, Dec 12, 2021 at 7:33 PM Frank Hwa wrote: > > Can you help me with the case I lost my root password for the dedicated > server which has freebsd installed? > > Thanks in advance. Easy, you just need console access. First reboot it. At the loader prompt, select "Boot single user". Then after the kernel loads you'll find yourself automatically at a root prompt, without needing to login. Change your password using passwd, then exit the shell to continue normal boot. You may need to remount your / filesystem rw in order to change the password. That can be done with "mount -u -w /" -Alan
Re: CURRENT: ZFS freezes system beyond reboot
On Sun, Dec 12, 2021 at 2:22 AM FreeBSD User wrote: > > Running CURRENT (FreeBSD 14.0-CURRENT #52 main-n251260-156fbc64857: Thu > Dec 2 14:45:55 CET 2021 amd64), out of the sudden the ZFS RAIDZ pool > suffered from an error: > > Solaris: WARNING: Pool 'POOL00' has encountered an uncorrectable I/O > failure and has been suspended. > > The system does not repsond anymore on that pool, transactions to and > from that pool are frozen, the system is 99.9% idle. > The most "not so funny" part is: the box doesn't even recognize a > "shutdown -r now" or a brute force "reboot". I still can login via ssh, > but any action regarding the ZFS pool freezes the console/terminal. > > ZFS very often renders the system unresponsible forever. How can this > be mitigated? The system in question is on a remote site and it seems > not only to be bound to CURRENT, we realised similar problems on > 13-STABLE as well. > > What can I do to "unfreeze" the ZFS? The main OS is, luckily, on an > UFS/FFS filesystem and so not affected from that problem. > > By the way, here some more details, as far as I can pick those up: > > zpool clear POOL00 cannot clear errors for POOL00: I/O error > > Whatever took out the ZFS pool (can not see any hardware errors, the > pool is part of services and especially a poudriere build system and > under heavy load all the time, the box has 16 GB RAM), it also renders > the rest of the system unusable in a way which is beyond a "reboot". > > Kind regrads, > oh You need to look at what's causing those errors. What kind of disks are you using, with what HBA? It's not surprising that any access to ZFS hangs; that's what it's designed to do when a pool is suspended.
Re: FreeBSD 14.0-CURRENT snapshots in Google Compute Engine
Thanks! That's just what I was looking for. On Tue, Nov 16, 2021 at 9:20 PM Li-Wen Hsu wrote: > > On Wed, Nov 17, 2021 at 11:56 AM Alan Somers wrote: > > > > Google Compute Engine has images for 11.4-RELEASE, 12.2-RELEASE, and > > 13.0-RELEASE. Are there any images for current snapshots, and if so > > what are their names? > > -Alan > > You can use this command to list all the images built by re: > > gcloud compute images list --no-standard-images > --project=freebsd-org-cloud-dev > > gcloud is from net/google-cloud-sdk > > Li-Wen
FreeBSD 14.0-CURRENT snapshots in Google Compute Engine
Google Compute Engine has images for 11.4-RELEASE, 12.2-RELEASE, and 13.0-RELEASE. Are there any images for current snapshots, and if so what are their names? -Alan
Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd
On Sat, Oct 9, 2021 at 11:57 PM Rick Macklem wrote: > > Alan Somers wrote: > >On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote: > >> > >> Hi, > >> > >> I ran into an issue this week during the nf...@ietf.org's testing event. > >> UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). > >> ZFS - just return EINVAL for VOP_ALLOCATE(). > >> > >> An NFSv4.2 server can either support Allocate or not, but it has to be > >> for all exported file systems. > > > >That seems like a protocol bug to me. Could this be fixed in a future > >NFS revision? > Who knows. I don't see any interest in a 4.3. 4.2 is extensible, but I think > this is now "cast in stone". > > >> > >> This leads me to a couple of questions: > >> - Is there a good reason for not using vop_stdallocate() for ZFS? > > > >Yes. posix_fallocate is supposed to guarantee that subsequent writes > >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write > >file system, cannot possibly guarantee that. See SVN r325320. > However, vop_stdallocate() just does VOP_WRITE()s to the area (with > bytes of data all zeros). Wouldn't that satisfy the criteria? No. It works for UFS, which is an overwriting file system. But for ZFS, when the user comes back later to rewrite those same offsets, ZFS will actually allocate new LBAs for them. > > >> - Should I try and support both file system types via vop_stdallocate() > >> or not support Allocate at all? > > > >Since you can't possibly support it for ZFS (not to mention other file > >systems like fusefs) you'll have to not support it at all. > It does sound like not supporting it is the best alternative. > > rick > > > > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > > such as offset=0, len=1. Why, I have no idea? > > > > Thanks in advance for any comments, rick > >
Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd
On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote: > > Hi, > > I ran into an issue this week during the nf...@ietf.org's testing event. > UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). > ZFS - just return EINVAL for VOP_ALLOCATE(). > > An NFSv4.2 server can either support Allocate or not, but it has to be > for all exported file systems. That seems like a protocol bug to me. Could this be fixed in a future NFS revision? > > This leads me to a couple of questions: > - Is there a good reason for not using vop_stdallocate() for ZFS? Yes. posix_fallocate is supposed to guarantee that subsequent writes to the file will not fail with ENOSPC. But ZFS, being a copy-on-write file system, cannot possibly guarantee that. See SVN r325320. > - Should I try and support both file system types via vop_stdallocate() > or not support Allocate at all? Since you can't possibly support it for ZFS (not to mention other file systems like fusefs) you'll have to not support it at all. > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > such as offset=0, len=1. Why, I have no idea? > > Thanks in advance for any comments, rick >
Re: witness_lock_list_get: witness exhausted
On Mon, Jan 8, 2018 at 5:31 PM Mateusz Guzik wrote: > > On Tue, Jan 9, 2018 at 12:41 AM, Michael Jung wrote: > > > On 2018-01-08 13:39, John Baldwin wrote: > > > >> On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote: > >> > >>> Hi! > >>> > >>> I've recently up'd my processor count on our poudriere box and have > >>> started noticing the error > >>> "witness_lock_list_get: witness exhausted" on the console. The kernel > >>> *DOES NOT* crash but I > >>> thought the report may be useful to someone. > >>> > >>> $ uname -a > >>> FreeBSD poudriere 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r325999: Sun Nov > >>> 19 18:41:20 EST 2017 > >>> mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > >>> > >>> The machine is pretty busy running four poudriere build instances. > >>> > >>> last pid: 76584; load averages: 115.07, 115.96, 98.30 > >>> > >>> up 6+07:32:59 14:44:03 > >>> 763 processes: 117 running, 581 sleeping, 2 zombie, 63 lock > >>> CPU: 59.0% user, 0.0% nice, 40.7% system, 0.1% interrupt, 0.1% idle > >>> Mem: 12G Active, 2003M Inact, 44G Wired, 29G Free > >>> ARC: 28G Total, 11G MFU, 16G MRU, 122M Anon, 359M Header, 1184M Other > >>> 25G Compressed, 32G Uncompressed, 1.24:1 Ratio > >>> > >>> Let me know what additional information I might supply. > >>> > >> > >> This just means that WITNESS stopped working because it ran out of > >> pre-allocated objects. In particular the objects used to track how > >> many locks are held by how many threads: > >> > >> /* > >> * XXX: This is somewhat bogus, as we assume here that at most 2048 > >> threads > >> * will hold LOCK_NCHILDREN locks. We handle failure ok, and we should > >> * probably be safe for the most part, but it's still a SWAG. > >> */ > >> #define LOCK_NCHILDREN 5 > >> #define LOCK_CHILDCOUNT 2048 > >> > >> Probably the '2048' (max number of concurrent threads) needs to scale with > >> MAXCPU. 2048 threads is probably a bit low on big x86 boxes. > >> > > > > > > Thank you for you explanation. We are expanding our ESXi cluster and even > > though with standard edition I can only assign 64 vCPU's to a guest and as > > much > > RAM as I want, I do like to help with edge cases if I can make them occur > > pushing > > boundaries as I can towards additianional improvements in FreeBSD. > > > > Can you apply this and re-run the test? > > https://people.freebsd.org/~mjg/witness.diff > > It bumps the counters to be "high enough" but also starts tracking usage. > If you get > the message again, bump the values even higher. > > Once you get a complete poudriere run which did not result in the problem, > do: > $ sysctl debug.witness.list_used debug.witness.list_max_used > > to dump the actual usage. This is a nice little patch. Can we commit to head? Even better would be if LOCK_CHILDCOUNT could be a tunable. On my largish system, here's what I get shortly after boot: debug.witness.list_max_used: 8432 debug.witness.list_used: 8420 -Alan
Re: Building ZFS disk images
On Tue, Sep 28, 2021 at 10:15 AM Rodney W. Grimes wrote: > > > On Tue, Sep 28, 2021 at 9:48 AM Rodney W. Grimes > > wrote: > > > > > > > On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston wrote: > > > > > > > > > > On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote: > > > > > > There's this: > > > > > > https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html . > > > > > > I > > > > > > haven't used it myself. > > > > > > > > > > Would it be useful to have an rc.d script that can run this, probably > > > > > just on the root pool? It could be configured to run only upon the > > > > > first boot, like growfs already does. > > > > > > > > Absolutely! > > > > > > Eww! :-) > > > > > > > > > > > > > > On Thu, Aug 5, 2021, 9:29 AM David Chisnall > > > > > > wrote: > > > > > > > > > > > > > On 05/08/2021 13:53, Alan Somers wrote: > > > > > > > > I don't know of any way to do it using the official release > > > > > > > > scripts > > > > > > > > either. One problem is that every ZFS pool and file system is > > > > > > > > supposed > > > > > > > > to have a unique GUID. So any kind of ZFS release builder > > > > > > > > would need to > > > ^^^ > > > > > > > > re-guid the pool on first boot. > > > > > > Isnt the proper place to solve this lack of Unique UUID creation > > > in the tool(s) that are creating the zfs pool in the first place. > > > > > > Fixing it "post boot" seems to be a far to late hack and doesnt > > > fix any of the situations where one might import these pools > > > between creation and first boot. > > > > No, because you might create a VM image once, then instantiate it > > dozens or thousands of times. The firstboot solution is great because > > it lets you reuse the same image file. > > I would continue to argue that the place to fix this is in the > "instantiate tool". ESXI vmfs deals with this all the time > when you clone a disk. And again the "fix at boot" does not > deal with the problem in that if I "instatiate" 10 copies of > a zpool for VM's and then try to mount 2 of them at once on > the host this problem rares it head. Fix the problem as close > to point of creation as possible for minimal issues in all > operations for everyone. But that requires ESXI, or whatever VM system you're using, to know about ZFS and GPT, and to know to look for a zpool on the 3rd partition, right? That seems like a lot to ask, especially since the logic would have to be duplicated for ESXI, vm-bhyve, OpenNebula, etc etc. > > > > > > > > > > > > > > > > > > > > Is there a tool / command to do this? I've hit this problem in > > > > > > > the > > > > > > > past: I have multiple FreeBSD VMs that are all created from the > > > > > > > same > > > > > > > template and if one dies I can't import its zpool into another > > > > > > > because > > > > > > > they have the same UUID. > > > > > > > > > > > > > > It doesn't matter for modern deployments where the VM is > > > > > > > stateless and > > > > > > > reimaged periodically but it's annoying for classic deployments > > > > > > > where I > > > > > > > have things I care about on the VM. > > > > > > > > > > > > > > David > > > > > > > > > > > > > > -- > > > Rod Grimes > > > rgri...@freebsd.org > > > > -- > Rod Grimes rgri...@freebsd.org
Re: Building ZFS disk images
On Tue, Sep 28, 2021 at 9:48 AM Rodney W. Grimes wrote: > > > On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston wrote: > > > > > > On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote: > > > > There's this: > > > > https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html . I > > > > haven't used it myself. > > > > > > Would it be useful to have an rc.d script that can run this, probably > > > just on the root pool? It could be configured to run only upon the > > > first boot, like growfs already does. > > > > Absolutely! > > Eww! :-) > > > > > > > > On Thu, Aug 5, 2021, 9:29 AM David Chisnall > > > > wrote: > > > > > > > > > On 05/08/2021 13:53, Alan Somers wrote: > > > > > > I don't know of any way to do it using the official release scripts > > > > > > either. One problem is that every ZFS pool and file system is > > > > > > supposed > > > > > > to have a unique GUID. So any kind of ZFS release builder would > > > > > > need to > ^^^ > > > > > > re-guid the pool on first boot. > > Isnt the proper place to solve this lack of Unique UUID creation > in the tool(s) that are creating the zfs pool in the first place. > > Fixing it "post boot" seems to be a far to late hack and doesnt > fix any of the situations where one might import these pools > between creation and first boot. No, because you might create a VM image once, then instantiate it dozens or thousands of times. The firstboot solution is great because it lets you reuse the same image file. > > > > > > > > > > > Is there a tool / command to do this? I've hit this problem in the > > > > > past: I have multiple FreeBSD VMs that are all created from the same > > > > > template and if one dies I can't import its zpool into another because > > > > > they have the same UUID. > > > > > > > > > > It doesn't matter for modern deployments where the VM is stateless and > > > > > reimaged periodically but it's annoying for classic deployments where > > > > > I > > > > > have things I care about on the VM. > > > > > > > > > > David > > > > > > -- > Rod Grimes rgri...@freebsd.org
Re: Building ZFS disk images
On Mon, Sep 27, 2021 at 1:54 PM Mark Johnston wrote: > > On Thu, Aug 05, 2021 at 10:54:19AM -0500, Alan Somers wrote: > > There's this: > > https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html . I > > haven't used it myself. > > Would it be useful to have an rc.d script that can run this, probably > just on the root pool? It could be configured to run only upon the > first boot, like growfs already does. Absolutely! > > > On Thu, Aug 5, 2021, 9:29 AM David Chisnall wrote: > > > > > On 05/08/2021 13:53, Alan Somers wrote: > > > > I don't know of any way to do it using the official release scripts > > > > either. One problem is that every ZFS pool and file system is supposed > > > > to have a unique GUID. So any kind of ZFS release builder would need to > > > > re-guid the pool on first boot. > > > > > > Is there a tool / command to do this? I've hit this problem in the > > > past: I have multiple FreeBSD VMs that are all created from the same > > > template and if one dies I can't import its zpool into another because > > > they have the same UUID. > > > > > > It doesn't matter for modern deployments where the VM is stateless and > > > reimaged periodically but it's annoying for classic deployments where I > > > have things I care about on the VM. > > > > > > David
Using modern APIs in Rust on FreeBSD
tldr; should the Rust ecosystem ditch FreeBSD 10 compat for new code? Rust uses FFI to talk to the OS's C library. That makes cross-compiling a breeze. Unfortunately, it also fossilizes the ABI. FreeBSD's libc makes careful use of ELF symbol versioning. That's how we were able to change ino_t to 64-bits while maintaining backwards-compatibility with old binaries, for example. But the Rust toolchain isn't able to take advantage. Right now, the toolchain uses a FreeBSD 10 ABI, and the libc crate (which virtually all crates depend on) uses a FreeBSD 11 ABI. That means, for example, that no crate can use: * The offset field in a struct dirent * 64-bit nlink_t * 64-bit ino_t * No NOTE_ABSTIME with kevent * filesystem and mountpoint names in statfs(2) limited to 88 characters Until somebody fixes that hard problem, the easy thing for Rust to do would be to drop support for EoL versions. FreeBSD 10 has been EoL for nearly 3 years, and FreeBSD 11 will be EoL in a few days. I for one think that it would be fine for new Rust toolchains and libc releases to drop support for FreeBSD 10 and 11. People who need to build for old releases can easily get old toolchains from rustup, or even from old Ports snapshots. But the Rust core developers are conservative, and don't want to upset users of a platform that many of them don't understand. Do you agree with me? If so (or even if you don't), make some noise on this Github issue! Give the Rust core team the confidence they need to move forward. https://github.com/rust-lang/rust/issues/89058 -Alan
Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool"
On Thu, Sep 16, 2021 at 4:02 PM Mark Millard wrote: > > > On 2021-Sep-16, at 13:39, Alan Somers wrote: > > > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current < > freebsd-current@freebsd.org> wrote: > > What do I go about: > > > > QUOTE > > # zpool import > >pool: zopt0 > > id: 18166787938870325966 > > state: FAULTED > > status: One or more devices contains corrupted data. > > action: The pool cannot be imported due to damaged devices or data. > >see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > config: > > > > zopt0 FAULTED corrupted data > > nda0p2UNAVAIL corrupted data > > > > # zpool status -x > > all pools are healthy > > > > # zpool destroy zopt0 > > cannot open 'zopt0': no such pool > > END QUOTE > > > > (I had attempted to clean out the old zfs context on > > the media and delete/replace the 2 freebsd swap > > partitions and 1 freebsd-zfs partition, leaving the > > efi partition in place. Clearly I did not do everything > > require [or something is very wrong]. zopt0 had been > > a root-on-ZFS context and would be again. I have a > > backup of the context to send/receive once the pool > > in the partition is established.) > > > > For reference, as things now are: > > > > # gpart show > > => 40 937703008 nda0 GPT (447G) > > 40 532480 1 efi (260M) > > 532520 2008- free - (1.0M) > > 534528 937166848 2 freebsd-zfs (447G) > > 937701376 1672- free - (836K) > > . . . > > > > (That is not how it looked before I started.) > > > > # uname -apKU > > FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 > releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 > > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > > > I have also tried under: > > > > # uname -apKU > > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 > main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 > > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > > > after reaching this state. It behaves the same. > > > > The text presented by: > > > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > > > does not deal with what is happening overall. > > > > So you just want to clean nda0p2 in order to reuse it? Do "zpool > labelclear -f /dev/nda0p2" > > > > I did not extract and show everything that I'd tried but > there were examples of: > > # zpool labelclear -f /dev/nda0p2 > failed to clear label for /dev/nda0p2 > > from when I'd tried such. So far I've not > identified anything with official commands > to deal with the issue. > That is the correct command to run. However, the OpenZFS import in FreeBSD 13.0 brought in a regression in that command. It wasn't a code bug really, more like a UI bug. OpenZFS just had a less useful labelclear command than FreeBSD did. The regression has now been fixed upstream. https://github.com/openzfs/zfs/pull/12511 > > Ultimately I zeroed out areas of the media that > happened to span the zfs related labels. After > that things returned to normal. I'd still like > to know a supported way of dealing with the > issue. > > The page at the URL it listed just says: > > QUOTE > The pool must be destroyed and recreated from an appropriate backup source > END QUOTE > It advised to to "destroy and recreate" the pool because you ran "zpool import", so ZFS thought that you actually wanted to import the pool. The error message is appropriate if that had been the case. > > But the official destroy commands did not work: > Because "zpool destroy" only works for imported pools. The error message meant "destroy" in a more generic sense. > same sort of issue of reporting that nothing > appropriate was found to destroy and no way to > import the problematical pool. > > > Note: I use ZFS because of wanting to use bectl, not > for redundancy or such. So the configuration is very > simple. > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > >
Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool"
On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current < freebsd-current@freebsd.org> wrote: > What do I go about: > > QUOTE > # zpool import >pool: zopt0 > id: 18166787938870325966 > state: FAULTED > status: One or more devices contains corrupted data. > action: The pool cannot be imported due to damaged devices or data. >see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > config: > > zopt0 FAULTED corrupted data > nda0p2UNAVAIL corrupted data > > # zpool status -x > all pools are healthy > > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE > > (I had attempted to clean out the old zfs context on > the media and delete/replace the 2 freebsd swap > partitions and 1 freebsd-zfs partition, leaving the > efi partition in place. Clearly I did not do everything > require [or something is very wrong]. zopt0 had been > a root-on-ZFS context and would be again. I have a > backup of the context to send/receive once the pool > in the partition is established.) > > For reference, as things now are: > > # gpart show > => 40 937703008 nda0 GPT (447G) > 40 532480 1 efi (260M) > 532520 2008- free - (1.0M) > 534528 937166848 2 freebsd-zfs (447G) > 937701376 1672- free - (836K) > . . . > > (That is not how it looked before I started.) > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 > releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 > > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > I have also tried under: > > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 > main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 > > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > after reaching this state. It behaves the same. > > The text presented by: > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > does not deal with what is happening overall. > So you just want to clean nda0p2 in order to reuse it? Do "zpool labelclear -f /dev/nda0p2"
Re: ses ioctl API/ABI stability
On Thu, Aug 26, 2021 at 2:21 AM David Chisnall wrote: > On 25/08/2021 22:19, Alan Somers wrote: > > We usually try to maintain backwards compatibility forever. But is that > > necessary for the ses(4) ioctls? There are several problems with them as > > currently defined. They lack type safety, lack automatic copyin/copyout > > handling, and one of them can overrun a user buffer. I would like to fix > > them, but adding backwards-compatibility versions would almost negate the > > benefit. Or, can we consider this to be an internal API, changeable at > > will, as long as sesutil's CLI remains the same? > > -Alan > > I've been pondering for a little while the possibility of using CUSE for > compat ioctls (particularly for jails, but potentially in general). > This might be a good candidate. If you rename ses and provide a CUSE > implementation of ses that runs in a Capsicum sandbox with access to the > new device then the worst that a type-safety bug can do is issue the > wrong ioctl (but not an invalid one, because the kernel will catch that > with the new interfaces). sesutil can move to the new interface and so > only things that want to directly talk to the old interface (for > example, sesutil in a FreeBSD 12 jail) will need to load the userspace > compat interface. > > David > Wild. I never thought about doing it that way. In this case though, ses isn't terribly useful for jails. I'm going to use imp's gone_in API instead, which I only discovered just this morning.
ses ioctl API/ABI stability
We usually try to maintain backwards compatibility forever. But is that necessary for the ses(4) ioctls? There are several problems with them as currently defined. They lack type safety, lack automatic copyin/copyout handling, and one of them can overrun a user buffer. I would like to fix them, but adding backwards-compatibility versions would almost negate the benefit. Or, can we consider this to be an internal API, changeable at will, as long as sesutil's CLI remains the same? -Alan
Re: Building multiple kernels with "make release"
On Thu, Jul 29, 2021 at 12:43 PM Emmanuel Vadot
wrote:
> On Thu, 29 Jul 2021 00:13:54 +
> Glen Barber wrote:
>
> > On Wed, Jul 28, 2021 at 06:00:28PM -0600, Alan Somers wrote:
> > > On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz>
> wrote:
> > >
> > > > On 28/07/2021 20:46, Juraj Lutter wrote:
> > > > >
> > > > >
> > > > >> On 28 Jul 2021, at 20:37, Glen Barber wrote:
> > > > >>
> > > > >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> > > > >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber
> wrote:
> > > > >>>> Just on a hunch, could you try with adding
> INSTALLKERNEL="${KERNEL}"
> > > > to
> > > > >>>> your release.conf?
> > > > >>>>
> > > > >>>> I now seem to recall some weirdness with this, but the exact
> details
> > > > >>>> elude me at the moment.
> > > > >>>>
> > > > >>>
> > > > >>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make
> installkernel"
> > > > >>> overrides whatever KERNCONF was set to. But it still only
> installs one
> > > > >>> kernel. Trying to set that variable to a list doesn't work.
> > > > >>
> > > > >> Ok. Give me a day or so to try to figure out what is (or isn't)
> > > > >> happening here. I do not recall any recent-ish changes that
> would have
> > > > >> caused this, and I am 95% certain it has worked in the past.
> > > > >
> > > > > According to Makefile.inc1:
> > > > >
> > > > > make installkernel KERNCONF=?KERN1 KERN2?
> > > > >
> > > > > should install KERN1 and KERN2. Similar goes for buildkernel.
> > > > >
> > > > > Or is there something I am missing?
> > > >
> > > > Does 'make installkernel KERNCONF=?KERN1 KERN2?' really install both
> > > > kernels? Under which names?
> > > > I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
> > > > kernels are built by "make buildkernel" but only one installed by
> "make
> > > > installkernel".
> > > >
> > > > To install other kernels I use:
> > > >
> > > > make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
> > > >
> > > > make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
> > > >
> > >
> > > Miroslav is right. Despite the comment that Juraj found, "make
> > > installkernel" only installs the first kernel listed in KERNCONF.
> >
> > Good find. I honestly thought this worked as expected versus as
> > written. In fact, I *thought* secondary, tertiary, etc. kernels were
> > installed as /boot/kernel.KERN2, /boot/kernel.KERN3 (using the example
> > above).
>
> You need to set NO_INSTALLEXTRAKERNELS=no for that to happens (yes the
> variable name and double no sucks if anyone have a patch for that that
> would be awesome).
>
> > Although, I may be misremembering, and 'kernel.KERN2.txz' may be created
> > instead, although not installed/extracted. Though, we are going back at
> > least seven years, and I do not even remember what I had eaten for
> > dinner last night, so there's that...
> >
> > Glen
> >
>
>
> --
> Emmanuel Vadot
>
NO_INSTALLEXTRAKERNELS=no works for "make installkernel". However, it
still doesn't work with release.sh. It seems there is work left to do.
-Alan
Re: Building ZFS disk images
There's this: https://openzfs.github.io/openzfs-docs/man/8/zpool-reguid.8.html . I haven't used it myself. On Thu, Aug 5, 2021, 9:29 AM David Chisnall wrote: > On 05/08/2021 13:53, Alan Somers wrote: > > I don't know of any way to do it using the official release scripts > > either. One problem is that every ZFS pool and file system is supposed > > to have a unique GUID. So any kind of ZFS release builder would need to > > re-guid the pool on first boot. > > Is there a tool / command to do this? I've hit this problem in the > past: I have multiple FreeBSD VMs that are all created from the same > template and if one dies I can't import its zpool into another because > they have the same UUID. > > It doesn't matter for modern deployments where the VM is stateless and > reimaged periodically but it's annoying for classic deployments where I > have things I care about on the VM. > > David
Re: Building ZFS disk images
I don't know of any way to do it using the official release scripts either. One problem is that every ZFS pool and file system is supposed to have a unique GUID. So any kind of ZFS release builder would need to re-guid the pool on first boot. On Thu, Aug 5, 2021, 6:41 AM David Chisnall wrote: > Hi, > > Does anyone know how to build ZFS disk images from any existing tooling? > > I haven't used UFS for over a decade now and the official cloud images > are all UFS, so I end up doing an install from the CD ISO into Hyper-V > locally and then exporting the VHD, but that can't be the most efficient > way of getting a FreeBSD VHD with ZFS. > > I haven't been able to find any documentation and reading the release > scripts they seem to hard-code UFS. > > David > >
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz> wrote:
> On 28/07/2021 20:46, Juraj Lutter wrote:
> >
> >
> >> On 28 Jul 2021, at 20:37, Glen Barber wrote:
> >>
> >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
> >>>> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}"
> to
> >>>> your release.conf?
> >>>>
> >>>> I now seem to recall some weirdness with this, but the exact details
> >>>> elude me at the moment.
> >>>>
> >>>
> >>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
> >>> overrides whatever KERNCONF was set to. But it still only installs one
> >>> kernel. Trying to set that variable to a list doesn't work.
> >>
> >> Ok. Give me a day or so to try to figure out what is (or isn't)
> >> happening here. I do not recall any recent-ish changes that would have
> >> caused this, and I am 95% certain it has worked in the past.
> >
> > According to Makefile.inc1:
> >
> > make installkernel KERNCONF=“KERN1 KERN2”
> >
> > should install KERN1 and KERN2. Similar goes for buildkernel.
> >
> > Or is there something I am missing?
>
> Does 'make installkernel KERNCONF=“KERN1 KERN2”' really install both
> kernels? Under which names?
> I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
> kernels are built by "make buildkernel" but only one installed by "make
> installkernel".
>
> To install other kernels I use:
>
> make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
>
> make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
>
> Miroslav Lachman
>
Miroslav is right. Despite the comment that Juraj found, "make
installkernel" only installs the first kernel listed in KERNCONF.
-Alan
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
> On Wed, Jul 28, 2021 at 05:32:03PM +, Glen Barber wrote:
> > On Wed, Jul 28, 2021 at 11:30:44AM -0600, Alan Somers wrote:
> > > On Wed, Jul 28, 2021 at 11:28 AM Glen Barber wrote:
> > >
> > > > On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote:
> > > > > On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote:
> > > > > > Is it possible to build multiple different kernels and include
> them
> > > > all in
> > > > > > a release image? release.conf says so. But from experiment,
> what I
> > > > see is
> > > > > > that:
> > > > > >
> > > > > > * release.sh does pass both kernels in the KERNCONF variable to
> "make
> > > > > > buildkernel"
> > > > > > * "make buildkernel" dutifully builds both
> > > > > > * BUT, "make installkernel" only installs the first kernel and
> ignores
> > > > the
> > > > > > rest
> > > > > > * Only the first kernel ends up in the final image
> > > > > > * It's not really clear where an alternate kernel should go,
> anyway.
> > > > > > Probably someplace like /boot/kernel.debug , but release.conf
> doesn't
> > > > > > provide a way to specify that.
> > > > > >
> > > > > > So is the "multiple kernels in release.conf" feature
> unfinished? If
> > > > so,
> > > > > > does anybody have a good idea about the best way to finish it?
> > > > > >
> > > > > >
> > > >
> https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32
> > > > > >
> > > > >
> > > > > Last I was aware, based on a patch sent to me privately, I
> believe, it
> > > > > should work.
> > > > >
> > > > > Let me take a look.
> > > > >
> > > >
> > > > Oh, wait. Are you using 'make release' or release/release.sh?
> > > >
> > >
> > > I'm using release.sh. I thought that was just a wrapper for "make
> > > release".
> >
> > It is, I just want to make sure I'm looking in the right place(s).
> >
>
> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
> your release.conf?
>
> I now seem to recall some weirdness with this, but the exact details
> elude me at the moment.
>
> Glen
>
Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
overrides whatever KERNCONF was set to. But it still only installs one
kernel. Trying to set that variable to a list doesn't work.
-Alan
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 11:28 AM Glen Barber wrote: > On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote: > > On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote: > > > Is it possible to build multiple different kernels and include them > all in > > > a release image? release.conf says so. But from experiment, what I > see is > > > that: > > > > > > * release.sh does pass both kernels in the KERNCONF variable to "make > > > buildkernel" > > > * "make buildkernel" dutifully builds both > > > * BUT, "make installkernel" only installs the first kernel and ignores > the > > > rest > > > * Only the first kernel ends up in the final image > > > * It's not really clear where an alternate kernel should go, anyway. > > > Probably someplace like /boot/kernel.debug , but release.conf doesn't > > > provide a way to specify that. > > > > > > So is the "multiple kernels in release.conf" feature unfinished? If > so, > > > does anybody have a good idea about the best way to finish it? > > > > > > > https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32 > > > > > > > Last I was aware, based on a patch sent to me privately, I believe, it > > should work. > > > > Let me take a look. > > > > Oh, wait. Are you using 'make release' or release/release.sh? > > Glen > I'm using release.sh. I thought that was just a wrapper for "make release".
Building multiple kernels with "make release"
Is it possible to build multiple different kernels and include them all in a release image? release.conf says so. But from experiment, what I see is that: * release.sh does pass both kernels in the KERNCONF variable to "make buildkernel" * "make buildkernel" dutifully builds both * BUT, "make installkernel" only installs the first kernel and ignores the rest * Only the first kernel ends up in the final image * It's not really clear where an alternate kernel should go, anyway. Probably someplace like /boot/kernel.debug , but release.conf doesn't provide a way to specify that. So is the "multiple kernels in release.conf" feature unfinished? If so, does anybody have a good idea about the best way to finish it? https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32 -Alan
Re: PATH: /usr/local before or after /usr ?
On Fri, Jul 16, 2021 at 10:46 AM Ian Lepore wrote: > On Fri, 2021-07-16 at 09:01 -0600, Alan Somers wrote: > > FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. > > AFAICT that convention began with SVN revision 37 "Initial import of > 386BSD > > 0.1 othersrc/etc". Why is that? It would make sense to me that > > /usr/local/X should come first. That way programs installed from ports > can > > override FreeBSD's defaults. Is there a good reason for this convention, > > or is it just inertia? > > -Alan > > I have a hierarchy on my machines rooted at /local and /local/bin is > before /bin and /usr/bin in my PATH, so I can override system tools > when I explicitly want to without suffering any problems of an > unexpected override from installing a port or package. > > If you're using ports as a development environment to work on a new > gstat replacement, you could do something similar and put PREFIX=/local > in your port makefile while you're developing on it. > > -- Ian > Thanks for the feedback everyone. Here's what I'm going to do: * If you install it from cargo, it will go into ~/.cargo/bin/gstat, which (for cargo users) comes first in PATH * If you install it from ports, it will become /usr/local/sbin/gstat-rs, with a pkg-message advising you to setup an alias. -Alan
Re: PATH: /usr/local before or after /usr ?
On Fri, Jul 16, 2021 at 9:54 AM Cameron Katri via freebsd-current < freebsd-current@freebsd.org> wrote: > On Fri, Jul 16, 2021 at 09:01:49AM -0600, Alan Somers wrote: > > FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. > > AFAICT that convention began with SVN revision 37 "Initial import of > 386BSD > > 0.1 othersrc/etc". Why is that? It would make sense to me that > > /usr/local/X should come first. That way programs installed from ports > can > > override FreeBSD's defaults. Is there a good reason for this convention, > > or is it just inertia? > > The biggest example I can think of this being a problem is having > binutils installed, it will cause any calls to elftoolchain or > llvm-binutils to go to GNU binutils which is platform specific, so cross > compiling, or LTO could be broken because of using GNU binutils which > don't support cross compiling or LTO. > > - Cameron Katri > > > -Alan > Ugh, that's a good example. I was thinking more about interactive programs, like say /usr/bin/vi vs editors/vim. Hypothetically how would one solve the conflict if /usr/local/bin came before /usr/bin ? Install binutils's binaries to /usr/local/libexec/binutils/ ? But a lot of ports depend on binutils. That would be a ton of ports to update. BTW my motivation for this thread is a new replacement for gstat that I'm working on. I would like to name it "gstat", but if /usr/sbin must come before /usr/local/sbin, then that won't be a very helpful name. -Alan
PATH: /usr/local before or after /usr ?
FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. AFAICT that convention began with SVN revision 37 "Initial import of 386BSD 0.1 othersrc/etc". Why is that? It would make sense to me that /usr/local/X should come first. That way programs installed from ports can override FreeBSD's defaults. Is there a good reason for this convention, or is it just inertia? -Alan
Re: git MFC/cherry-pick question
On Thu, Jun 3, 2021 at 8:13 PM Rick Macklem wrote: > Hi, > > I am trying to MFC a commit to stable/12. > The cherry-pick works, but the resultant code > is not correct and won't build. > --> I broke the build yesterday and manually >reverted the breakage. > > So, how do I do this? > > Do I have to manually edit the file after the > cherry-pick and then do something like a > git commit -a > to get the edited change in, or is there a > way to tell it to add it to the cherry-pick or ?? > > Thanks anyone, for help with this, rick > Is the resulting code incorrect because of a git merge error, or because stable/13 requires slightly different code than main? If it's the latter, then after the "git cherry-pick", you should edit the file manually and do a "git commit -a --amend". That will produce the right result. You don't have to worry about screwing up merge history by using "--amend", because "git cherry-pick" already screws up merge history. If your problem is the former, then the same solution will work, although you might be able to solve it by using some fancy git merge options instead. -Alan
Help wanted: volunteer yourselves in .github/CODEOWNERS
Strangers are submitting pull requests to our Github mirror, but we rarely pay attention. I just added a .github/CODEOWNERS file to our repo to automatically assign reviewers to PRs. I based it off of the contents of the current MAINTAINERS file. But it's incomplete. Please add yourself if: * You don't have a github account associated with your FreeBSD email address. I'm talking to you, adrian@, macklem@, and rrs@ . * You are part of a team, like secteam@ or re@ . You'll have to create the team at https://github.com/orgs/freebsd/teams then you can add it to the list. * You previously signed up for Phabricator notifications with Herald, but didn't sign up in MAINTAINERS. I can't see everybody's Phabricator assignments. * You never signed up in MAINTAINERS before, but you really ought to because you care deeply about some particular subsystem. -Alan
Re: FreeBSD - rc.conf man page splitting.
That man page is getting pretty big. However, it's not always obvious which section a particular setting should be in. Right now, you can always just search through the entire thing. But searching would be harder if it were split up. So I vote to keep it together. -Alan On Mon, May 24, 2021 at 8:28 AM Santiago Martinez wrote: > Ok, noted. my proposal come after looking for network parameters (which > also is a topic to talk about) the list is so huge that it doesn't not > make it simple. But if this work for most, then i have to accommodate > to that! > > Thanks for your feedback! > > Santi > > > > On 5/23/21 9:26 PM, Steve Kargl wrote: > > On Sun, May 23, 2021 at 09:20:45PM +0100, Santiago Martinez wrote: > >> Just wondering whats your view on splitting rc.conf man pages (per > >> section/topic), something similar to what it was done with zfs. > >> > >> For example rc.conf-fw, rc.conf-network and so on. And yes if people > think > >> is a good idea im happy to take the task. > >> > > IMO, Bad idea (tm). > > > >
Re: RFC: changing the default NFSv4 minor version?
On Thu, May 13, 2021 at 5:02 PM Rick Macklem wrote: > Hi, > > I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main. > I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0. > (In particular, the sessions mechanism for "exactly once RPC semantics" > is a significant improvement over the duplicate request cache for NFSv4.0, > plus other improvements.) > > Right now, the FreeBSD NFSv4 client will use NFSv4.0 unless the > "minorversion" mount option is used to set the minor version to 1 or 2. > > The Linux client uses the highest minor version supported by both > client and server by default. > I'd like to propose that the default behaviour of the FreeBSD client > be changed to do the same, so that NFSv4.1/4.2 will be used when possible. > --> The "minorversion" mount option could still be used to override the > above default. > > I have hesitated doing this change because it could be considered a POLA > violation, but I think the change from 4.0->4.1/4.2 will normally be a > neutral to positive experience. (To be honest, I suspect most won't notice > the change.) > > How do others feel about this change? > > rick > +1 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Building ZFS-based VM images
It's easy to build a UFS-based VM image just by setting WITH_VMIMAGES in release.conf and running release.sh. But what about ZFS-based images? What's the easiest way to build a ZFS-based VM image, using a pool layout similar to what the interactive installer uses? -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is OpenZFS doing during boot?
On Fri, Apr 30, 2021 at 7:21 AM Ulrich Spörlein wrote: > Hi folks, this is a stable/13 question but I figured it's still close > enough to -CURRENT to count. > > So I wanted to update my (remote) system with freebsd-update, but that > installed half a kernel and bricked the machine upon reboot. Lucky me I > fixed OOB access just the day before. > > Did the usual world/kernel build and ran etcupdate, merging in my > local changes. This bricked the system again, as it removed the -x bit on > /etc/rc.d/netif, I filed > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255514 for that though > (I > never had such trouble with mergemaster, just even understanding what > etcupdate is trying to do and how to bootstrap it is a mystery to me). > > Anyway, I have a data zpool on 2x encrypted GELI providers that I can only > unlock (and zpool import) with 2 passphrases after the system has booted. > > Color me surprised when some RC script thought otherwise and tried to > import the pool during boot. Why does it do that, that's not supposed to > work and it should not even touch the encrypted bits (yet). > > mountroot: waiting for device /dev/mirror/gm0a... > Dual Console: Serial Primary, Video Secondary > GEOM_ELI: Device gpt/swap0.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: accelerated software > GEOM_ELI: Device gpt/swap1.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: accelerated software > Setting hostuuid: d7902500-4c7c-0706-0025-90d77c4c0e0f. > Setting hostid: 0x8a2b4277. > cannot import 'data': no such pool or dataset > Destroy and re-create the pool fipmi0: Unknown IOCTL 40086481 > ipmi0: Unknown IOCTL 40086481 > rom > a backup source. > cachefile import failed, retrying > nvpair_value_nvlpid 69 (zpool), jid 0, uid ist(nvp, ) == 0 (0x16 == 0) > ASSERT at /usr/src/sys/contrib/openzfs/module/nv0: exited on signal 6 > pair/fnvpair.c:586:fnvpair_value_nvlist()Abort trap > cannot import 'data': no such pool or dataset > ipmi0: Unknown IOCTL 40086481 > ipmi0: Unknown IOCTL 40086481 > Destroy and re-cpid 74 (zpool), jid 0, uid 0: exited on signal 6 > reate the pool from > a backup source. > cachefile import failed, retrying > nvpair_value_nvlist(nvp, ) == 0 (0x16 == 0) > ASSERT at > > /usr/src/sys/contrib/openzfs/module/nvpair/fnvpair.c:586:fnvpair_value_nvlist()Abort > trap > Starting file system checks: > /dev/mirror/gm0a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0a: clean, 370582 free (814 frags, 46221 blocks, 0.2% > fragmentation) > /dev/mirror/gm0d: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0d: clean, 867640 free (1160 frags, 108310 blocks, 0.1% > fragmentation) > /dev/mirror/gm0e: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/mirror/gm0e: clean, 1267948 free (17228 frags, 156340 blocks, 0.7% > fragmentation) > Mounting local filesystems:. > > > What do I need to do to _not_ have any zpool operations be attempted during > startup? How does it even know of the existence of that pool? > > I guess it's zfs_enable=NO to stop /etc/rc.d/zpool from messing about. But > more importantly, the GELI providers don't exist yet, why does it then > segfault? Shouldn't it be a bit more robust on that front? > > Thanks all > Uli > Your problem is the zpool cache file. As soon as ZFS loads, it tries to import all pools mentioned in /boot/zfs/zpool.cache. If you're using ZFS on top of GELI, then obviously you don't want that. What you should is move the cachefile somewhere else. Do it like this: $ zpool set cachefile=/some/where/else my-data-pool And on every boot, import it like this: $ service geli start $ zpool import -a -c /some/where/else -o cachefile=/some/where/else Hope this helps. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
How to delete comment spam from bugzilla?
Somebody, or more likely some bot, is posting comment spam in our bugzilla. How can we delete spammy comments ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.1 from main?
Because we have a policy of never releasing anything even a little bit backwards-incompatible in a minor release. imp, for example, has been removing obsolete drivers in main. We can remove old drives in a major release, but not in a minor one. That's why we can't release 13.1 from the main branch. -Alan On Thu, Apr 22, 2021 at 3:37 PM Ronald Klop wrote: > Hi, > > Just wondering a bit. Why wouldn't the FreeBSD project release 13.1 from > the main branch in about six months or some other time period? While making > some monthly errata releases in the meantime. > - This saves a lot of back porting of commits. > - It prevents branches with old code like the current 11-branch with an > old openssl version. Release early. > - Saves some people time in maintaining the branches. > - Saves time in coordinating the releases. Release often. > - Reduces the number of needed RC's. Because the main branch doesn't > divert a lot of what people are running in production. > - Most people start testing/production use after the release. So this > should be used as input for the main branch to improve the next release. > Currently the feedback of 13.0 is put in 14.0 which is 2 years in the > future. > > Just some thoughts. Which I really like. :-) > > Regards, > Ronald. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD/arm64 becoming Tier 1 in FreeBSD 13
On Fri, Apr 9, 2021 at 7:23 AM Ed Maste wrote: > Summary > > FreeBSD will promote arm64 to a Tier 1 architecture in FreeBSD 13. > This means we will provide release images, binary packages, and > security and errata updates. While we anticipate there will be minor > issues with this first release, we believe the port is mature enough > that they can be resolved during the life of FreeBSD 13. > > Details > > Development efforts on FreeBSD/arm64 (also known as AArch64) started > in 2014, with generous financial and technical support from Arm, > Cavium and the FreeBSD Foundation. FreeBSD 11.0 arrived in October > 2016 as the first release with support for the architecture. > Improvements to the kernel, tool chain, userland, and ports and > package infrastructure have been ongoing since that time, with > improvements arriving in each minor and major release. > > The FreeBSD base system is ready for the promotion of arm64 to Tier 1, > and the Release Engineering, Security, and Ports teams are prepared to > support the Tier 1 requirements for arm64. Security updates via > freebsd-update now include arm64 support (starting with the FreeBSD > 13.0 release candidates). > > Required ports infrastructure is in place for arm64 and most ports > build successfully. The project now has several Ampere eMAG systems > acting as package build servers. These machines were obtained through > a combination of FreeBSD Foundation purchases and generous donations > from Ampere. > > To support port maintainers who do not have access to arm64 hardware > we will be improving ports CI and testing resources (and this effort > will benefit all architectures). We will also be suggesting one or > more low-cost reference platforms for FreeBSD/arm64. > > The guarantees included in Tier 1 status are described in > > https://docs.freebsd.org/en_US.ISO8859-1/articles/committers-guide/archs.html > > In particular, for Tier 1 architectures the project provides release > images, binary package sets, and binary and source updates for > Security Advisories and Errata Notices. > > The AArch64 ecosystem’s maturity ensures follow on generations of > hardware. The diversity of offerings, as well as the multiple > generations of hardware shows that the FreeBSD project will benefit > from adding support for this platform. The growth trajectory suggests > this will be a significant portion of the market in the coming years, > and FreeBSD will benefit from tapping into this market with this Tier > 1 platform. > > (on behalf of core) > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Wow, great news! I look forward to seeing your reference platform recommendations. But the next obvious question that comes to mind is: how to do hosted CI testing for FreeBSD/arm64? Cirrus-CI and sr.ht work well but only for amd64. Are there any options for arm64 at all? I think it should be possible to hook up Cirrus's management to one of Amazon's arm64 instances, but somebody would have to go to the trouble of creating a custom ami image, and every user would need to create an EC2 account. Are there any better options? -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 13.0-RC5 Now Available
On Sun, Apr 4, 2021 at 3:38 PM Colin Percival wrote: > On 4/4/21 1:50 PM, Alan Somers wrote: > > On Sat, Apr 3, 2021 at 9:34 AM Glen Barber > <mailto:g...@freebsd.org>> wrote: > > > > The fifth RC build of the 13.0-RELEASE release cycle is now available. > > > > In the past, making these releases required pushing updates to > > https://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/ . > > Historically, we often made changes directly on the update builders and > then brought the svn tree back into sync later. > > > However, that repo is read-only now. I assume that it's been gitified, > but > > I can't find the new location. Where is it? > > I think the freebsd-update build code might be homeless right now. I know > I > have seen emails mentioning that it needs to land somewhere but I don't > recall > any decision being reached. > I vote for https://github.com/freebsd/freebsd-update-build . ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 13.0-RC5 Now Available
On Sat, Apr 3, 2021 at 9:34 AM Glen Barber wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > The fifth RC build of the 13.0-RELEASE release cycle is now available. > > Installation images are available for: > > o 13.0-RC5 amd64 GENERIC > o 13.0-RC5 i386 GENERIC > o 13.0-RC5 powerpc GENERIC > o 13.0-RC5 powerpc64 GENERIC64 > o 13.0-RC5 powerpc64le GENERIC64LE > o 13.0-RC5 powerpcspe MPC85XXSPE > o 13.0-RC5 armv6 RPI-B > o 13.0-RC5 armv7 GENERICSD > o 13.0-RC5 aarch64 GENERIC > o 13.0-RC5 aarch64 RPI > o 13.0-RC5 aarch64 PINE64 > o 13.0-RC5 aarch64 PINE64-LTS > o 13.0-RC5 aarch64 PINEBOOK > o 13.0-RC5 aarch64 ROCK64 > o 13.0-RC5 aarch64 ROCKPRO64 > o 13.0-RC5 riscv64 GENERIC > o 13.0-RC5 riscv64 GENERICSD > > Note regarding arm SD card images: For convenience for those without > console access to the system, a freebsd user with a password of > freebsd is available by default for ssh(1) access. Additionally, > the root user password is set to root. It is strongly recommended > to change the password for both users after gaining access to the > system. > > Installer images and memory stick images are available here: > > https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/ > > The image checksums follow at the end of this e-mail. > > If you notice problems you can report them through the Bugzilla PR > system or on the -stable mailing list. > > If you would like to use Git to do a source based update of an existing > system, use the "releng/13.0" branch. > > A summary of changes since 13.0-RC4 includes: > > o COMPAT_FREEBSD32 fill/set dbregs/fpregs has been implemented for > aarch64. > > o Miscellaneous DTrace updates. > > o An issue that could potentially affect some services to properly > restart, notably Nginx, has been addressed. > > o Miscellaneous networking fixes. > > A list of changes since 12.2-RELEASE is available in the releng/13.0 > release notes: > > https://www.freebsd.org/releases/13.0R/relnotes.html > > Please note, the release notes page is not yet complete, and will be > updated on an ongoing basis as the 13.0-RELEASE cycle progresses. > > === Virtual Machine Disk Images === > > VM disk images are available for the amd64, i386, and aarch64 > architectures. Disk images may be downloaded from the following URL > (or any of the FreeBSD download mirrors): > > https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC5/ > > The partition layout is: > > ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) > ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) > ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) > > The disk images are available in QCOW2, VHD, VMDK, and raw disk image > formats. The image download size is approximately 135 MB and 165 MB > respectively (amd64/i386), decompressing to a 21 GB sparse image. > > Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI > loader file is needed for qemu-system-aarch64 to be able to boot the > virtual machine images. See this page for more information: > > https://wiki.freebsd.org/arm64/QEMU > > To boot the VM image, run: > > % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ > -bios QEMU_EFI.fd -serial telnet::,server -nographic \ > -drive if=none,file=VMDISK,id=hd0 \ > -device virtio-blk-device,drive=hd0 \ > -device virtio-net-device,netdev=net0 \ > -netdev user,id=net0 > > Be sure to replace "VMDISK" with the path to the virtual machine image. > > BASIC-CI images can be found at: > > https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-RC5/ > > === Amazon EC2 AMI Images === > > FreeBSD/amd64 EC2 AMIs are available in the following regions: > > af-south-1 region: ami-0fe76e3a8c6a8d108 > eu-north-1 region: ami-0fe9d5e3fd7bd2972 > ap-south-1 region: ami-0090069af2f905566 > eu-west-3 region: ami-042ea753bff8d6a9d > eu-west-2 region: ami-08e0358d71a41ce97 > eu-south-1 region: ami-0a1cb76bf83c3c49c > eu-west-1 region: ami-0559fa7d3edc6e607 > ap-northeast-3 region: ami-04492324222abcb1b > ap-northeast-2 region: ami-0e851ff1f260888fd > me-south-1 region: ami-087ab54ec6e4d0cbb > ap-northeast-1 region: ami-0796973b853fba5e0 > sa-east-1 region: ami-03f738fc556689a14 > ca-central-1 region: ami-05f22cba7be241fbe > ap-east-1 region: ami-07ac68b5cc29039bc > ap-southeast-1 region: ami-04a8c807e53f07e72 > ap-southeast-2 region: ami-097dc8195cad3a688 > eu-central-1 region: ami-013f760d364d2d6a7 > us-east-1 region: ami-0e5adeb6a86cb63c4 > us-east-2 region: ami-04aac5053216613b1 > us-west-1 region: ami-07a9e536124bc5cd3 > us-west-2 region: ami-0d590e9beb5038bd0 > > FreeBSD/aarch64 EC2 AMIs are available in the following regions: > > af-south-1 region: ami-085df8d192daddc93 > eu-north-1 region: ami-035b8e0f104183bde > ap-south-1 region: ami-0224f547eb20ded51 > eu-west-3 region: ami-092ad93b82e3a558a > eu-west-2 region: ami-0567fa1f5daa6c238 >
Re: 13.0 RC4 might be delayed
On Sun, Mar 28, 2021 at 10:36 PM Gleb Popov wrote: > On Mon, Mar 29, 2021 at 4:37 AM David G Lawrence via freebsd-current < > freebsd-current@freebsd.org> wrote: > > > > > On 27/03/21 06:04, David G Lawrence via freebsd-current wrote: > > > >>> On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin < > > grahamper...@gmail.com> > > > >>> wrote: > > > >>> > > > On 26/03/2021 03:40, The Doctor via freebsd-current wrote: > > > > ??? if people are having issues with ports like ??? > > > > > > If I'm not mistaken: > > > > > > * 13.0-RC3 seems to be troublesome, as a guest machine, with > > > emulators/virtualbox-ose 6.1.18 as the host > > > > > > * no such trouble with 12.0-RELEASE-p5 as a guest. > > > > > > I hope to refine the bug report this weekend. > > > > > > >>> > > > >>> Had nothing but frequent guest lockups on 6.1.18 with my Win7 > > system. > > > >>> That > > > >>> was right after 6.1.18 was put into ports. Fell back to legacy (v5) > > and > > > >>> will try again shortly to see if it's any better. > > > >> > > > >> Kevin, > > > >> > > > >> ?? Make sure you have these options in your /etc/sysctl.conf : > > > >> > > > >> vfs.aio.max_buf_aio=8192 > > > >> vfs.aio.max_aio_queue_per_proc=65536 > > > >> vfs.aio.max_aio_per_proc=8192 > > > >> vfs.aio.max_aio_queue=65536 > > > >> > > > >> ?? ...otherwise the guest I/O will random hang in VirtualBox. > > This > > > >> issue was > > > >> mitigated in a late 5.x VirtualBox by patching to not use AIO, but > > the > > > >> issue > > > >> came back in 6.x when that patch wasn't carried forward. > > > > > > > > Sorry I lost that patch. Can you point me to the patch? Maybe it can > > be > > > > easily ported. > > > > > > > > > > I found the relevant commit. Please give me some time for testing and > > > I'll put this patch back in the tree. > > > >If you're going to put that patch back in, then AIO should probably be > > made an option in the port config, as shutting AIO off by default will > > have a significant performance impact. Without AIO, all guest IO will > > be become synchronous. > > > > Are you sure about that? Without AIO, VBox uses a generic POSIX backend, > which is based on pthread, I think. > We should also consider changing the defaults. vfs.aio.max_buf_aio: this is the maximum number of buffered AIO requests per process. Buffered AIO requests are only used when directing AIO to device nodes, not files, and only for devices that don't support unmapped I/O. Most devices do support unmapped I/O, including all GEOM devices. For devices that do support unmapped I/O, the number of AIO requests per process is unlimited. So this knob isn't very important. However, it is more important on powerpc and mips, where unmapped I/O isn't always possible. 16 is probably pretty reasonable for mips. vfs.aio.max_aio_queue_per_proc: this is the maximum queued aio requests per process. This applies to all AIO requests, whether to files or devices. So it ought to be large. If your program is too unsophisticated to handle EAGAIN, then it must be very large. Otherwise, a few multiples of max(vfs.aio.max_aio_per_proc, your SSD's queue depth) is probably sufficient. vfs.aio.max_aio_per_proc: this is the max number of active aio requests in the slow path (for I/O to files, or other cases like misaligned I/O to disks). Setting this too low won't cause programs to fail, but it could hurt performance. Setting it higher than vfs.aio.max_aio_procs probably won't have any benefit. vfs.aio.max_aio_queue: like max_aio_per_proc, but global instead of per-process. Doesn't need to be more than a few multiples of max_aio_per_proc. Finally, I see that emulators/virtualbox-ose's pkg-message advises checking for the AIO kernel module. That advice is obsolete. AIO is nowadays builtin to the kernel and always enabled. There is no kernel module any longer. Actually, the defaults don't look unreasonable to me, for an amd64 system with disk, file, or zvol-backed VMs. Does virtualbox properly handle EAGAIN as returned by aio_write, aio_read, and lio_listio? If not, raising these limits is a poor substitute for fixing virtualbox. If so, then I'm really curious. If anybody could tell me which limit actually solves the problem, I would like to know. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting started with ktls
On Sun, Mar 14, 2021 at 8:57 AM tech-lists wrote: > On Thu, Mar 11, 2021 at 03:42:55PM +, Rick Macklem wrote: > >I'm going to cheat and top post (the discussion looks > >pretty convoluted). > > > >- The kernel must be built with "options KERN_TLS" > >- OpenSSL must be built with KTLS enabled > >- These two sysctls need to be set to 1 > > kern.ipc.tls.enable > > kern.ipc.mb_use_ext_pgs > > Hello, > > I'd like to try ktls but have found the following: > > On AMD64 (stable/13) this option is present in the GENERIC kernel > of world built about a month ago: stable/13-n244496-618dee60231 > and openssl version is 1.1.1i-freebsd > > On ARM64 (stable/13) it's *not* present in a world built earlier > today from stable/13-n244876-0b45290603b. Here, the openssl version > is 1.1.1j-freebsd > > On another ARM64 (main/14) it *is* present in main-n245445-07564e17620 > built with sources from the 11th March. openssl is 1.1.1j-freebsd here > as well. > > I'd like to have it (ktls) available on the ARM64 > stable/13-n244876-0b45290603b. Is it just a matter of adding the option, > and then the sysctls become available? Is it "better" with openssl[-devel] > in ports or openssl in base? > > thanks, > -- > J.\ It's present in current kernels for both 13 and 14, amd64 and aarch64. However, it's not present in 13's openssl. To use it, you must either rebuild world with WITH_OPENSSL_KTLS=YES in /etc/src.conf, install security/openssl-devel from pkg, or built security/openssl from ports with the KTLS option enabled. I don't know if any version of openssl is "better" than another. The sysctls should be available in any case. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting started with ktls
On Thu, Mar 11, 2021 at 11:49 AM John Baldwin wrote: > On 3/10/21 4:18 PM, Alan Somers wrote: > > I'm trying to make ktls work with "zfs send/recv" to substantially reduce > > the CPU utilization of applications like zrepl. But I have a few > questions: > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a > > successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported > > Libraries" section says "Applications using a supported library should > > generally work with ktls without any changes". These sentences seem to > be > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > necessary, but OpenSSL sets it automatically? > > Yes, you can do it by hand if you want but you'd have to do all the key > exchange by hand as well. > > > * When using OpenSSL, the library will automatically call setsockopt(_, > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > application to tell if ktls is enabled on a particular socket or OpenSSL > > session? > > BIO_get_ktls_send() and BIO_get_ktls_recv() on the write and read BIO's of > the connection, respectively. > > > * From experiment, I can see that OpenSSL attempts to set > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? > > From reading ktls_start and ossl_statem_server_post_work, it looks like > > maybe a single socket cannot have ktls enabled for both sending and > > receiving at the same time. Is that true? > > Neither FreeBSD nor OpenSSL yet support RX offload on TLS 1.3. If you use > TLS 1.2 you will get KTLS in both directions (or if you use TLS 1.1 with > TOE offload on a Chelsio T6). > > -- > John Baldwin > Switching to TLS 1.2 turned out to be key. Once I did that, ... it just worked. I was expecting to need minor changes throughout the kernel and libzfs. However, that wasn't necessary. Here is my proof-of-concept program. So far only the recv path is implemented. I'll probably implement the send path too, but I'm not currently planning to integrate this into any open-source application. Thanks for all the help! https://github.com/asomers/freebsd-src/tree/ktls-zfs/tools/zfs-ktls -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting started with ktls
On Wed, Mar 10, 2021 at 8:15 PM Benjamin Kaduk wrote: > On Wed, Mar 10, 2021 at 06:17:42PM -0700, Alan Somers wrote: > > On Wed, Mar 10, 2021 at 5:31 PM Benjamin Kaduk wrote: > > > > > On Wed, Mar 10, 2021 at 05:18:24PM -0700, Alan Somers wrote: > > > > I'm trying to make ktls work with "zfs send/recv" to substantially > reduce > > > > the CPU utilization of applications like zrepl. But I have a few > > > questions: > > > > > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by > a > > > > successful set of the TCP_TXTLS_ENABLE socket option", but the > "Supported > > > > Libraries" section says "Applications using a supported library > should > > > > generally work with ktls without any changes". These sentences seem > to > > > be > > > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > > > necessary, but OpenSSL sets it automatically? > > > > > > Yes, OpenSSL sets it automatically for the builtin socket and > connection > > > BIO classes. Applications using other BIO classes will need to do > things > > > manually (or implement the appropriate _ctrl() parameters for their BIO > > > class). > > > > > > > * When using OpenSSL, the library will automatically call > setsockopt(_, > > > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > > > application to tell if ktls is enabled on a particular socket or > OpenSSL > > > > session? > > > > > > IIRC the lack of answer for this is part of why upstream OpenSSL > doesn't > > > have specific KTLS tests enabled in the automated test suite. > > > > > > > getsockopt(_. TCP_TXTLS_ENABLE) returns ENOPROTOOPT. Is there any reason > > why it's not implemented? That might be the easiest way to check for the > > ktls status of an individual socket. > > I think that's probably more of a question for jhb than me. I don't know > of a reason why not, but I do know that there is some desire to keep the > functionality that openssl exposes roughly compatible between linux and > FreeBSD KTLS. I don't know whether Linux has something similar. > > > > > > > > > > * From experiment, I can see that OpenSSL attempts to set > > > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why > not? > > > > From reading ktls_start and ossl_statem_server_post_work, it looks > like > > > > maybe a single socket cannot have ktls enabled for both sending and > > > > receiving at the same time. Is that true? > > > > > > No. They just get enabled separately, since change_cipher_state() is > > > called separately for read and write transitions. > > > > > > > Apologies if I'm too ignorant, but what is a transition in SSL-speak? > This > > is my first attempt at any kind of SSL programming. What I know from > > ktrace is that TCP_RXTLS_ENABLE never gets set. > > Sorry! I'm pretty conversant with this stuff (I'm the security area > director that is responsible for the IETF TLS working group) and don't > always target the right level. Basically, for a decent encrypting protocol > you want different encrytion keys for the read and write direction > (whichever peer you are), and the TLS (1.3) handshake has a multi-stage key > hierarchy to try to encrypt as much of it as possible. So, for example, > the client will need to update it's encryption key for reading once it > reads the ServerHello (and before reading the Encrypted Extensions) > message, even though the keys the client uses for writing don't change at > that time. Internally, OpenSSL implements this "transition" of key > material with a change_cipher_state() abstraction, that takes a flags > argument (`which`). The flags indicate which set of keys to update, and > which direction (read or write). So, by my read of the code, what's > *supposed* to happen is that we call: > > if (BIO_set_ktls(bio, _info, which & SSL3_CC_WRITE)) > > And if SSL3_CC_WRITE is set, that translates to calling BIO_set_ktls() with > an `is_txt` value that evaluates to true; otherwise, `is_txt` is false, > which corresponds to the RX case that you're failing to see happen. > > Just to get the boring stuff out of the way: what version of openssl are > you testing against, and did you verify that OPENSSL_NO_KTLS_RX is not > defined when ktls_start() is being compiled (so that the setsockopt(fd, > IPPROTO_TCP, TCP_RXTLS_ENABLE, .) is compiled in at all)? > > Thanks, > > Ben > I'm using the OpenSSL that's in base in 14.0-CURRENT: 1.1.1j-freebsd . I haven't recompiled the code to check whether OPENSSL_NO_KTLS_RX is defined, but it sure looks like it shouldn't be, based on my reading of the source. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting started with ktls
On Wed, Mar 10, 2021 at 5:31 PM Benjamin Kaduk wrote: > On Wed, Mar 10, 2021 at 05:18:24PM -0700, Alan Somers wrote: > > I'm trying to make ktls work with "zfs send/recv" to substantially reduce > > the CPU utilization of applications like zrepl. But I have a few > questions: > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a > > successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported > > Libraries" section says "Applications using a supported library should > > generally work with ktls without any changes". These sentences seem to > be > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > necessary, but OpenSSL sets it automatically? > > Yes, OpenSSL sets it automatically for the builtin socket and connection > BIO classes. Applications using other BIO classes will need to do things > manually (or implement the appropriate _ctrl() parameters for their BIO > class). > > > * When using OpenSSL, the library will automatically call setsockopt(_, > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > application to tell if ktls is enabled on a particular socket or OpenSSL > > session? > > IIRC the lack of answer for this is part of why upstream OpenSSL doesn't > have specific KTLS tests enabled in the automated test suite. > getsockopt(_. TCP_TXTLS_ENABLE) returns ENOPROTOOPT. Is there any reason why it's not implemented? That might be the easiest way to check for the ktls status of an individual socket. > > > * From experiment, I can see that OpenSSL attempts to set > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? > > From reading ktls_start and ossl_statem_server_post_work, it looks like > > maybe a single socket cannot have ktls enabled for both sending and > > receiving at the same time. Is that true? > > No. They just get enabled separately, since change_cipher_state() is > called separately for read and write transitions. > Apologies if I'm too ignorant, but what is a transition in SSL-speak? This is my first attempt at any kind of SSL programming. What I know from ktrace is that TCP_RXTLS_ENABLE never gets set. > > -Ben > > > Based on the man page and rmacklem's previous mailing list posts, I think > > this should be workable with minor modifications to the kernel and > libzfs. > > I just need to figure out how to use ktls first. > > > > -Alan > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Getting started with ktls
I'm trying to make ktls work with "zfs send/recv" to substantially reduce the CPU utilization of applications like zrepl. But I have a few questions: * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported Libraries" section says "Applications using a supported library should generally work with ktls without any changes". These sentences seem to be contradictory. I think it means that the TCP_TXTLS_ENABLE option is necessary, but OpenSSL sets it automatically? * When using OpenSSL, the library will automatically call setsockopt(_, TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an application to tell if ktls is enabled on a particular socket or OpenSSL session? * From experiment, I can see that OpenSSL attempts to set TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? >From reading ktls_start and ossl_statem_server_post_work, it looks like maybe a single socket cannot have ktls enabled for both sending and receiving at the same time. Is that true? Based on the man page and rmacklem's previous mailing list posts, I think this should be workable with minor modifications to the kernel and libzfs. I just need to figure out how to use ktls first. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KTLS with zfs recv
On Sat, Feb 27, 2021 at 7:10 AM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes < > > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > My understanding is that KTLS works very well with OpenSSL for > sending, > > > but > > > > not as well for receiving, because there's nothing like a recvfile > > > > syscall. However, it works great for both send and receive with NFS, > > > where > > > > all the data remains in the kernel. What about zfs recv? A very > common > > > > pattern is for an application to read from an SSL socket and then > pipe > > > the > > > > data to zfs recv. For example, zrepl does that. Could zfs recv > instead > > > > read directly from the KTLS socket, bypassing userspace? That could > > > > potentially save a _lot_ of cycles for a _lot_ of people. > > > > > > I did some patches and a short presentation at BSDCan that basically > > > shoves the whole zfs send and zfs recv process into the kernel, ie > > > it opens the sockets up, makes the connections, then the socket > > > is passed into the kernel(s) and it all runs in kernel mode. > > > > > > > > > > https://www.bsdcan.org/2018/schedule/attachments/479_BSDCan-2018-zfs-send.pdf > > > > > > A few things need fixed like reversing who does the listen for > > > security reasons, but this feature is probably ready for prime > > > time. > > > > > > > -Alan > > > > > > -- > > > Rod Grimes > > > rgri...@freebsd.org > > > > > > That looks potentially useful, but it doesn't use encryption. Would it > > work if the socket had been opened by openssl with ktls? > > Alan, > Should I revise the code to meet the state that was discussed > during the BSDCan talk so that it can be committed? Matt Aherns said > at the time he felt if I just reversed the listen/connect relationship > between send and recv that it addressed enough of the security concern > to be usable "on a local and well administered" network and would > probably be safe to import into upstream ZFS. (This was prior to > FreeBSD moving to openzfs.) > > From other discussion in this thread it does not sound difficult to > implement the KTLS end of it, but I doubt that would be portable > enough to upstream, maybe someone can speak to that issue? > > -- > Rod Grimes > rgri...@freebsd.org Rod, it would be great if we can get that code committed. I'll try to come up with a OpenSSL->zfs recv POC program next week. And I think we should try to upstream it to OpenZFS, too. They aren't strict about portability; plenty of OS-specific features have made it into their repo. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KTLS with zfs recv
On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > My understanding is that KTLS works very well with OpenSSL for sending, > but > > not as well for receiving, because there's nothing like a recvfile > > syscall. However, it works great for both send and receive with NFS, > where > > all the data remains in the kernel. What about zfs recv? A very common > > pattern is for an application to read from an SSL socket and then pipe > the > > data to zfs recv. For example, zrepl does that. Could zfs recv instead > > read directly from the KTLS socket, bypassing userspace? That could > > potentially save a _lot_ of cycles for a _lot_ of people. > > I did some patches and a short presentation at BSDCan that basically > shoves the whole zfs send and zfs recv process into the kernel, ie > it opens the sockets up, makes the connections, then the socket > is passed into the kernel(s) and it all runs in kernel mode. > > > https://www.bsdcan.org/2018/schedule/attachments/479_BSDCan-2018-zfs-send.pdf > > A few things need fixed like reversing who does the listen for > security reasons, but this feature is probably ready for prime > time. > > > -Alan > > -- > Rod Grimes > rgri...@freebsd.org That looks potentially useful, but it doesn't use encryption. Would it work if the socket had been opened by openssl with ktls? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
KTLS with zfs recv
My understanding is that KTLS works very well with OpenSSL for sending, but not as well for receiving, because there's nothing like a recvfile syscall. However, it works great for both send and receive with NFS, where all the data remains in the kernel. What about zfs recv? A very common pattern is for an application to read from an SSL socket and then pipe the data to zfs recv. For example, zrepl does that. Could zfs recv instead read directly from the KTLS socket, bypassing userspace? That could potentially save a _lot_ of cycles for a _lot_ of people. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS assertions
On Tue, Feb 9, 2021 at 5:37 PM Graham Perrin wrote: > On 09/02/2021 14:41, Alan Somers wrote: > > Re: Current - kernel dump while plasma loading. > > … ZFS assertions weren't actually enabled until last night. … > > < > https://cgit.freebsd.org/src/commit/?id=174a7e578a33c01401e33f9bfcc077fc3155251c> > > noted with thanks. > > I typically use a GENERIC-NODEBUG kernel config, does this partially > negate the benefits of assertions? > > (If so: for the ZFS case, I'll change it.) > > Thanks > That's right. Most assertions are disabled in GENERIC-NODEBUG. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Current - kernel dump while plasma loading.
On Tue, Feb 9, 2021 at 3:52 AM Santiago Martinez wrote: > Hi there, this morning i did the usual git pull and make.. > > After reboot and loading the desktop (while starting plasma with drm), i > get a kernel dump. > > This was ok until this morning... > > This is the info: > > root@tucho:/var/crash # cat info.last > Dump header from device: /dev/ada0p2 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 1381969920 > Blocksize: 512 > Compression: none > Dumptime: 2021-02-09 10:24:21 + > Hostname: tucho > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 14.0-CURRENT #5 main-n244705-504ebd612ec6: Tue > Feb 9 10:20:32 GMT 2021 > root@tucho:/usr/obj/usr/src/amd64.amd64/sys/TUCHO > Panic String: VERIFY(avl_find(tree, new_node, ) == NULL) failed > > Dump Parity: 2603051126 > Bounds: 6 > Dump Status: good > > > Best regards. > > Santi > I can tell you why it was "fine" until this morning. It's because ZFS assertions weren't actually enabled until last night. So this isn't a newly introduced ZFS bug, just a newly noticed one. Could you please post the full stack trace? -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot loader blank screen
On Mon, Jan 18, 2021 at 7:16 AM Johan Hendriks wrote: > > On 16/01/2021 21:15, Alan Somers wrote: > > On Sat, Jan 16, 2021 at 8:39 AM John Kennedy wrote: > > > >> On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote: > >>> Could you please check latest current now?:) > >>Success! With main-c255999-g0bc776f3da70, I've been able to comment > out > >> the > >> screen.textmode=0 (so, back to the default like I originally was). > >> > I needed to set vbe_max_resolution="800x600" to get the non text version > of the boot loader. > Oh, I see. "hw.vga.textmode" got renamed to "screen.textmode". And it works both ways now. No need to set vbe_max_resolution. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot loader blank screen
On Sat, Jan 16, 2021 at 8:39 AM John Kennedy wrote: > On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote: > > Could you please check latest current now?:) > > Success! With main-c255999-g0bc776f3da70, I've been able to comment out > the > screen.textmode=0 (so, back to the default like I originally was). > Sort of! Now textmode works again. But the hw.vga.textmode setting is ignored. Instead, I'm always in text mode; I can't boot into graphics mode. This is at main-c256008-gde57c3d88258 on an Ivy Bridge system. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot loader blank screen
Is there a bugzilla issue for this yet? It's affecting a lot of people, and it will be easier for us to monitor progress with Bugzilla than with the mailing list. -Alan On Thu, Jan 14, 2021 at 12:15 AM Jakob Alvermark wrote: > > On 1/14/21 4:49 AM, monochrome wrote: > > I should add my experience to this since its different and haven't > > seen anyone else mention it. > > I see the new boot loader, it's not blank, but its large text, and > > it's very SLOW. > > I can see each char drawn, and then when it gets to the bottom and has > > to redraw all the lines to scroll up for new lines, it loads so slowly > > it's like watching an 8086 on a 300 baud modem, or slower! Takes like > > an extra 30 seconds to get through all the loaded modules, then back > > to normal speed boot with the same large font. > > > > added these lines and everything is back to normal with new appearance > > and small font like before, and at normal speed. > > hw.vga.textmode="0" > > vbe_max_resolution=1280x800 > > > > also removed the old lines for the amdgpu efi problem with no effect > > so I assume those are no longer necessary and why I'm seeing this change? > > #hw.syscons.disable=1 > > #kern.vty=vt > > #hw.vga.textmode=1 > > > > am using X and everything seems fine for now > > > > system: > > AMD Ryzen 5 2400G, using integrated vega GPU > > ASRock B450M Pro4 > > 13-current > > > > > > > > On 1/5/21 8:54 PM, David Wolfskill wrote: > >> On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote: > >>> ... > the 58661b3ba9eb should hopefully fix the loader text mode issue, > it would be cool if you can verify:) > > thanks, > toomas > >>> > >>> I think, I got it fixed (at least idwer did confirm for his system, > >>> thanks). If you can test this patch: > >>> > http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch > >>> < > http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch> > > >>> it would be really nice. > >>> > >>> thanks, > >>> toomas > >> > >> I tested with each of the following "stanzas' in /boot/loader.conf, > >> using vt (vs. syscons) in each case (though that breaks video reset > >> on resume after suspend): > >> > >> # hw.vga.textmode="0" > >> vbe_max_resolution=1280x800 > >> > >> This works, and provides a graphical console (depth 32). > >> > >> > >> hw.vga.textmode="0" > >> # vbe_max_resolution=1280x800 > >> > >> This also works, and provides a low-resolution (and depth 16) > >> graphical console (800x320 or something similar, IIRC). > >> > >> > >> # hw.vga.textmode="0" > >> # vbe_max_resolution=1280x800 > >> > >> (That is, not specifying anything for hw.vga.textmode or > >> vbe_max_resolution.) > >> > >> This boots OK, but I see no kernel probe messages or single- to > >> multi-user mode messages. I can use (e.g.) Ctl+Alt+F2 to switch to > >> vty1, see a "login: " prompt, and that (also) works. (This is the > >> initial symptom I had reported.) > >> > >> > >> hw.vga.textmode="1" > >> # vbe_max_resolution=1280x800 > >> > >> This works -- boots OK, and I see kernel probe () messages; this is a > >> text console (mostly blue text; some white, against a dark background. > >> It's a medium-light blue, so it's easy enough to read (unlike a navy > >> blue, for example). > >> > >> > >> FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 > >> main-c255601-g9fd96b416c45-dirty: Tue Jan 5 17:24:45 PST 2021 > >> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > > >> amd64 > > > +1 on the slowness. > > I like the graphics mode, it's very pretty. > > But slow. It seems to depend a lot on the screen resolution. On my small > laptop, 1366x768, it's fairly OK. On the 1080p laptop it is very much > slower, it takes about 35 seconds longer compared to the old loader. > > Booting on a 4K monitor, well, I didn't time it... > > > Jakob > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Preparing ZFS drives
On Tue, Jan 12, 2021 at 11:10 AM joe mcguckin wrote: > Folks, > > I want to buy some 16TB drives and raid them up > > How should I label and prepare the drives for ZFS? Someone ought to write > a ‘cookbook’ on that! > > Do I need to start the volume on a particular sector boundary? > > Are the 4096 byte sector drives usable? > > Thanks, > > Joe > > Joe McGuckin > ViaNet Communications > > j...@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax > If you aren't going to boot from them, and you aren't using anything fancy like multipath JBODs, then you don't need to do anything at all. Just use the raw disks. And you don't need to worry about the sector size, unless you're planning to replace 512B disks with 4KB disks at some future date. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: git non-time-sequential logs
On Mon, Jan 4, 2021 at 9:58 AM Poul-Henning Kamp wrote: > > John Kennedy writes: > > > This might be perfectly natural and just new to me, but when I look at > the > > git logs this morning I see things like this (editing by me): > > > > Date: Mon Jan 4 17:30:00 2021 +0100 > > Date: Mon Dec 14 18:56:56 2020 +0100 > > Date: Tue Dec 15 13:50:00 2020 +0100 > > Date: Mon Jan 4 16:23:10 2021 +0100 > > > > I've always assumed that the "Date:" there was when the commit > happened, > > It is, but it is the time it was committed in the first git repos it was > committed to, > in this case the repos of the committer in question. > > Without taking a position on the merits of this design-choice, I > just want to point out that it means that timestamps should be > viewed very sceptically, since they depend on the *local* clock on > somebodys computer, not on the central repos machine. > I'll be more frank than phk: it sucks. Git's commit dates are basically useless. But there are a few ways to improve the situation: 1) If we start using Gitlab or something similar, we can ban pushes directly to head. Then we'll be able to trust the Dates on Gitlab's merge commits. 2) Perhaps we can use the Git Notes to add a field for the Date when a commit was pushed to the master server? 3) The internet is full of suggestions for how to change the way commits are displayed locally to mediate this problem. But they all seem to involve changes to the working copy's configuration, not the master's. And I haven't gotten any way to work. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cp(1) of large files is causing 100% CPU utilization and poor transfer
LGTM! This patch also fixes another problem: the previous version of cp, when copying a large sparse file on UFS, would create some UFS indirect blocks (because it would keep truncating the file to larger sizes). The output file would still be sparse, but it would take up more space than the original. IIRC about 0.2% of the empty space would get used by UFS indirect blocks. But your patch fixes it. What I said earlier about needing to modify vn_generic_copy_file_range wasn't quite correct. I confused len with xfer when I was reading the code. The change I proposed to vn_generic_copy_file_range would only make a difference if the process receives many interrupts. And here's some background for other people reading the thread: the reason that the initial copy_file_range implementation in cp only used a 2 MB block size is because vn_generic_copy_file_range wasn't always interruptible, and we didn't want cp to block for minutes or even hours during a long transfer. Subsequently rmacklem made vn_generic_copy_file_range interruptible, but we never raised the block size in cp. -Alan On Sat, Jan 2, 2021 at 2:42 PM Rick Macklem wrote: > The attached small patch seems to fix the problem. > My hunch is that, for a large non-sparse file, SEEK_DATA > SEEK_HOLE takes a fairly long time. > These are done for each copy_file_range(2) syscall. > > cp was doing lots of them because of the small len argument. > Bumping the len up to SSIZE_MAX results in far fewer sycalls > and, therefore, SEEK_DATAs and SEEK_HOLEs. > > Without the patch, cp took 6 times as long as dd. > With the patch, cp takes less time than dd. > > I'll put the patch on the bug report. Matthias, can you test > the patch? > > Thanks for reporting this, rick > ps: All my test programs use SSIZE_MAX unless they were > not supposed to copy to eof, which explains why I > missed this. My bad, for the testing.;-) > > > From: owner-freebsd-curr...@freebsd.org > on behalf of Matthias Apitz > Sent: Saturday, January 2, 2021 3:05 PM > To: Alan Somers > Cc: Rick Macklem; FreeBSD CURRENT; Konstantin Belousov; Kirk McKusick > Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor > transfer > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender and > know the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca > > > El día sábado, enero 02, 2021 a las 11:29:36a. m. -0700, Alan Somers > escribió: > > > > El día sábado, enero 02, 2021 a las 05:06:05p. m. +, Rick Macklem > > > escribió: > > > > > > > Just fyi, I've reproduced the problem. > > > > All I did was create a 20Gbyte file > > > > on UFS on a slow (4Gbyte or RAM, > > > > slow spinning disk) laptop. > > > > (The UFS file system is just what the installer creates these days.) > > > > > > > > cp still hasn't finished and is definitely > > > > taking a looott longer than dd did. > > > > > > > > I'll start drilling down later to-day. > > > > > > > > I'll admit doing lots of testing of copy_file_range(2) > > > > with large sparse files, but I may have missed testing > > > > a large non-sparse file. > > > > > > > > rick > > > > ps: I've added Kostik and Kirk to the cc. > > > > > > As the problem seems to be clear now, should I still file a PR? > > > I'm happy to do so. > > > > > > > Yes please . That will help ensure that we don't lose track of it. > > Here we go: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252358 > > Thanks > > matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit > Kuba an! > http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/ > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cp(1) of large files is causing 100% CPU utilization and poor transfer
On Sat, Jan 2, 2021 at 11:28 AM Matthias Apitz wrote: > El día sábado, enero 02, 2021 a las 05:06:05p. m. +, Rick Macklem > escribió: > > > Just fyi, I've reproduced the problem. > > All I did was create a 20Gbyte file > > on UFS on a slow (4Gbyte or RAM, > > slow spinning disk) laptop. > > (The UFS file system is just what the installer creates these days.) > > > > cp still hasn't finished and is definitely > > taking a looott longer than dd did. > > > > I'll start drilling down later to-day. > > > > I'll admit doing lots of testing of copy_file_range(2) > > with large sparse files, but I may have missed testing > > a large non-sparse file. > > > > rick > > ps: I've added Kostik and Kirk to the cc. > > As the problem seems to be clear now, should I still file a PR? > I'm happy to do so. > > matthias > Yes please . That will help ensure that we don't lose track of it. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cp(1) of large files is causing 100% CPU utilization and poor transfer
It seems pretty clear to me, based on my experiments, that FIOSEEKHOLE is O(n) in filesize on UFS (though not on ZFS). And vn_generic_copy_file_range calls VOP_IOCTL(..., FIOSEEKHOLE) once for every block it copies, where blocks can range from 4KB to 1 MB. So I think there are three required actions: 1) Fix vn_generic_copy_file_range to remember the hole locations across different iterations of its loop. 2) Increase the block size that cp uses with copy_file_range. Right now it's 2MB, but it should be much larger. 3) Optionally, improve UFS's FIOSEEKHOLE performance. But it probably won't be necessary if we fix 1 and 2. -Alan On Sat, Jan 2, 2021 at 10:06 AM Rick Macklem wrote: > Just fyi, I've reproduced the problem. > All I did was create a 20Gbyte file > on UFS on a slow (4Gbyte or RAM, > slow spinning disk) laptop. > (The UFS file system is just what the installer creates these days.) > > cp still hasn't finished and is definitely > taking a looott longer than dd did. > > I'll start drilling down later to-day. > > I'll admit doing lots of testing of copy_file_range(2) > with large sparse files, but I may have missed testing > a large non-sparse file. > > rick > ps: I've added Kostik and Kirk to the cc. > > > ____ > From: owner-freebsd-curr...@freebsd.org > on behalf of Alan Somers > Sent: Saturday, January 2, 2021 11:30 AM > To: Matthias Apitz; FreeBSD CURRENT > Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor > transfer > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender and > know the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca > > > On Sat, Jan 2, 2021 at 9:12 AM Matthias Apitz wrote: > > > El día sábado, enero 02, 2021 a las 09:06:24a. m. -0700, Alan Somers > > escribió: > > > > > > As I said, it can be reproduced using only the local file system. > This > > > > was setup recently on a SSD: > > > > > > > > # dmesg | grep ada0 > > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > > > ada0: ACS-2 ATA SATA 3.x device > > > > ada0: Serial Number F995890846 > > > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > > > > ada0: Command Queueing enabled > > > > ada0: 488386MB (1000215216 512 byte sectors) > > > > > > > > and by this procedure: > > > > > > > > # gpart create -s gpt ada0 > > > > # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0 > > > > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 > > > > # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0 > > > > # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0 > > > > # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0 > > > > # newfs -U -t /dev/gpt/ssdrootfs > > > > # newfs -U -t /dev/gpt/ssdvarfs > > > > # newfs -U -t /dev/gpt/ssdusrfs > > > > > > > > # gpart show -l ada0 > > > > =>40 1000215136 ada0 GPT (477G) > > > > 401024 1 ssdboot (512K) > > > > 1064 984- free - (492K) > > > > 2048 4194304 2 ssdrootfs (2.0G) > > > > 4196352 4194304 3 ssdvarfs (2.0G) > > > > 839065616777216 4 ssdswap (8.0G) > > > > 25167872 975046656 5 ssdusrfs (465G) > > > > 1000214528 648- free - (324K) > > > > > > > > # mount -t ufs > > > > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > > > > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > > > > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) > > > > > > > > When I run in the /usr fs the command > > > > > > > > # cp -p guru-20210102.tar.gz xxx > > > > > > > > it copies around 168M per minute. > > > > > > > > > Is that copying from /usr to /usr, or from /usr to /var or /? > > > > # cd /home/backups > > # cp -p guru-20210102.tar.gz xxx > > > > i.e. from /usr to /usr. > > > > matthias > > > > Ok, let's narrow this down. Could you please run the command with the > attached D script ? > sudo dtrace -s copy_file_range.d -c "cp -p guru-20210102.tar.gz xxx" > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cp(1) of large files is causing 100% CPU utilization and poor transfer
On Sat, Jan 2, 2021 at 9:12 AM Matthias Apitz wrote: > El día sábado, enero 02, 2021 a las 09:06:24a. m. -0700, Alan Somers > escribió: > > > > As I said, it can be reproduced using only the local file system. This > > > was setup recently on a SSD: > > > > > > # dmesg | grep ada0 > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > > ada0: ACS-2 ATA SATA 3.x device > > > ada0: Serial Number F995890846 > > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > > > ada0: Command Queueing enabled > > > ada0: 488386MB (1000215216 512 byte sectors) > > > > > > and by this procedure: > > > > > > # gpart create -s gpt ada0 > > > # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0 > > > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 > > > # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0 > > > # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0 > > > # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0 > > > # newfs -U -t /dev/gpt/ssdrootfs > > > # newfs -U -t /dev/gpt/ssdvarfs > > > # newfs -U -t /dev/gpt/ssdusrfs > > > > > > # gpart show -l ada0 > > > =>40 1000215136 ada0 GPT (477G) > > > 401024 1 ssdboot (512K) > > > 1064 984- free - (492K) > > > 2048 4194304 2 ssdrootfs (2.0G) > > > 4196352 4194304 3 ssdvarfs (2.0G) > > > 839065616777216 4 ssdswap (8.0G) > > > 25167872 975046656 5 ssdusrfs (465G) > > > 1000214528 648- free - (324K) > > > > > > # mount -t ufs > > > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > > > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > > > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) > > > > > > When I run in the /usr fs the command > > > > > > # cp -p guru-20210102.tar.gz xxx > > > > > > it copies around 168M per minute. > > > > > > Is that copying from /usr to /usr, or from /usr to /var or /? > > # cd /home/backups > # cp -p guru-20210102.tar.gz xxx > > i.e. from /usr to /usr. > > matthias > Ok, let's narrow this down. Could you please run the command with the attached D script ? sudo dtrace -s copy_file_range.d -c "cp -p guru-20210102.tar.gz xxx" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cp(1) of large files is causing 100% CPU utilization and poor transfer
On Sat, Jan 2, 2021 at 9:02 AM Matthias Apitz wrote: > El día sábado, enero 02, 2021 a las 08:42:01a. m. -0700, Alan Somers > escribió: > > > > # dd if=guru-20210102.tar.gz > of=/mnt/AcerC720/backups/guru-20210102.tar.gz > > > bs=8m > > > 4601+1 records in > > > 4601+1 records out > > > 38603862368 bytes transferred in 506.778929 secs (76174956 bytes/sec) > > > # ls -lh guru-20210102.tar.gz > > > -r 1 root wheel36G 2 ene. 12:19 guru-20210102.tar.gz > > > > > > When I use cp(1) what I normaly do the transfer is very poor and causes > > > 100% CPU itilization: > > > > > > # cp -p guru-20210102.tar.gz /mnt/AcerC720/backups/xxx > > > ^C > > > > > > killed after 1 minute; transfered in 1 minute: > > > > > > # ls -lh /mnt/AcerC720/backups/xxx > > > -r 1 root wheel 168M 2 ene. 15:34 > /mnt/AcerC720/backups/xxx > > > > > > 168*1024*1024/60 = 2936012 bytes/sec ./. 76174956 bytes/sec > > > > > > Trussing the cp(1) process shows these sys calls: > > > > > > # truss -p 37655 > > > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > > > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > > > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > > > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > > > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > > > > > > The problem is unrelated to the external disk, also a copy > > > in the local file system shows the same transfer speed of 168M per > > > minute. > > > Not an issue I've heard of before. Could you please describe how your > USB > > and local disk are formatted? Also, where is the source file stored? It > > could be that the source file's file system has a very slow > implementation > > of FIOSEEKDATA/FIOSEEKHOLE. > > -Alan > > > As I said, it can be reproduced using only the local file system. This > was setup recently on a SSD: > > # dmesg | grep ada0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: Serial Number F995890846 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > ada0: Command Queueing enabled > ada0: 488386MB (1000215216 512 byte sectors) > > and by this procedure: > > # gpart create -s gpt ada0 > # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0 > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 > # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0 > # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0 > # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0 > # newfs -U -t /dev/gpt/ssdrootfs > # newfs -U -t /dev/gpt/ssdvarfs > # newfs -U -t /dev/gpt/ssdusrfs > > # gpart show -l ada0 > =>40 1000215136 ada0 GPT (477G) > 401024 1 ssdboot (512K) > 1064 984- free - (492K) > 2048 4194304 2 ssdrootfs (2.0G) > 4196352 4194304 3 ssdvarfs (2.0G) > 839065616777216 4 ssdswap (8.0G) > 25167872 975046656 5 ssdusrfs (465G) > 1000214528 648- free - (324K) > > # mount -t ufs > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) > > When I run in the /usr fs the command > > # cp -p guru-20210102.tar.gz xxx > > it copies around 168M per minute. > > matthias > Is that copying from /usr to /usr, or from /usr to /var or /? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cp(1) of large files is causing 100% CPU utilization and poor transfer
On Sat, Jan 2, 2021 at 7:59 AM Matthias Apitz wrote: > > This is with: > > # uname -a > FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #23 r368166M: Thu > Dec 17 13:12:37 CET 2020 > guru@c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > > I copy often large backup files to an external USB disk and hit the > following problem since updating to r368166: > > A transfer with dd(1) works fast and as expected (~70M / sec): > > # dd if=guru-20210102.tar.gz of=/mnt/AcerC720/backups/guru-20210102.tar.gz > bs=8m > 4601+1 records in > 4601+1 records out > 38603862368 bytes transferred in 506.778929 secs (76174956 bytes/sec) > # ls -lh guru-20210102.tar.gz > -r 1 root wheel36G 2 ene. 12:19 guru-20210102.tar.gz > > When I use cp(1) what I normaly do the transfer is very poor and causes > 100% CPU itilization: > > # cp -p guru-20210102.tar.gz /mnt/AcerC720/backups/xxx > ^C > > killed after 1 minute; transfered in 1 minute: > > # ls -lh /mnt/AcerC720/backups/xxx > -r 1 root wheel 168M 2 ene. 15:34 /mnt/AcerC720/backups/xxx > > 168*1024*1024/60 = 2936012 bytes/sec ./. 76174956 bytes/sec > > Trussing the cp(1) process shows these sys calls: > > # truss -p 37655 > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > copy_file_range(0x3,0x0,0x4,0x0,0x20,0x0)= 2097152 (0x20) > > The problem is unrelated to the external disk, also a copy > in the local file system shows the same transfer speed of 168M per > minute. > > Is this a known issue or a regressionc ? > > I see in the man page of copy_file_range(2) that this is new with > FreeBSD 13... > > matthias > Not an issue I've heard of before. Could you please describe how your USB and local disk are formatted? Also, where is the source file stored? It could be that the source file's file system has a very slow implementation of FIOSEEKDATA/FIOSEEKHOLE. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Enabling AESNI by default
On Thu, Dec 31, 2020 at 3:20 PM Kristof Provost wrote: > On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote: > > Its for ever dead code on a large number of machines that do not have > > the hardware for it. I know that is a decreasing set, but imho it > > would be better to somehow ONLY load the module if you had CPU > > support for it. The down side is that detection would probably have > > to be in the laoder as this code can be used very early on. > > > According to kldstat it uses all of 42KB of memory. > > 161 0x83313000 a290 aesni.ko > > That’s such a trivial amount of memory it’s not even worth > mentioning. Even in tiny embedded systems (and who runs tiny embedded > systems on x86?) it’s utterly insignificant. > > Even if it were significant, how many of the systems without the > relevant hardware are ever going to run 13? > > Regards, > Kristof > And tiny embedded systems are probably running custom kernels anyway, so they can remove it. I'm sold. Let's put it in GENERIC. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: referencing one commit in another for git
On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem wrote: > Hi, > > So I just did my first git commit. Pretty scary, but it looks ok. > > Now, how do I reference one commit in another related > commit's log? > > By the long winded hash or ?? > > I'm not sure if I should ask here or on the git mailing list, > but I figured this isn't a technical git question... > > Thanks for any help with this, rick > Yeah, you should use the full hash. For temporary references, like during a code review, you can use the first "several" digits of the hash. For a project of FreeBSD's size, "several" is probably 11-13. But in permanent contexts, like commit logs, you should use the full hash. When somebody views the commit on a platform like Github, Github will automatically turn it into a hyperlink, and display only the first "several" digits. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On Thu, Dec 17, 2020 at 12:06 PM Warner Losh wrote: > On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn > wrote: > > > > > > > On 12/16/20 7:46 PM, Warner Losh wrote: > > > Greetings, > > > > > > The FreeBSD project will be moving it's source repo from subversion to > > git > > > starting this this weekend. The docs repo was moved 2 weeks ago. The > > ports > > > repo will move at the end of March, 2021 due to timing issues. > > > > > > The short version is that we're switching the version control we're > > using. > > > This switch will preserve much of the current FreeBSD development > > workflow. > > > After the switch, the subversion repo will become almost read-only. All > > > future work will be done in git, however as a transition aide we'll be > > > replaying the MFCs to stable/11, stable/12 and the related releng > > branches > > > for the life of those branches. > > > > > > For more detailed information, please see > > > https://github.com/bsdimp/freebsd-git-docs/ for the current > > documentation. > > > > > > Please see https://wiki.freebsd.org/git for the latest detailed > schedule > > > (please note that this schedule is subject to change). > > > > > > Warner > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > > > > > > > One question I didn't see in the (excellent!) docs is whether we should > > be PGP-signing commits or not. Is that encouraged? > > > > We've not started doing that in general. I don't think signing would cause > issues, but since it is a bit of an unknown, we've not taken a position on > this. > > Warner (on behalf of the git working group) > I hope we don't have to start signing all commits. saltstack/salt has that policy, and it's extremely annoying. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: port build fails with missing sys/smr_types.h
On Thu, Dec 3, 2020 at 2:09 PM Chuck Tuffli wrote: > Hi > > I'm trying to fix the build of qemu-utils but am seeing failures on > CURRENT (13.0-HEAD-9e082d278b9) like: > > In file included from util/oslib-posix.c:50: > In file included from /usr/include/sys/user.h:51: > In file included from /usr/include/sys/proc.h:50: > /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not > found > #include > ^ > > # uname -a > FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD > 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27 > 00:09:50 PST 2020 > root@freebsd > :/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG > amd64 > # ls -l /usr/include/sys/*smr* > -r--r--r-- 1 root wheel 1988 Nov 30 14:04 /usr/include/sys/_smr.h > -r--r--r-- 1 root wheel 7822 Nov 30 14:04 /usr/include/sys/smr.h > > So it appears the file is missing. Any ideas? > > --chuck > That file doesn't get installed into /usr/include, but it exists in /usr/src. A few ports need /usr/src. See devel/py-libzfs/Makefile for an example of how to find it. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS crash -- zvol_geom_bio_getattr called when volmode=dev
This sounds like it might be a regression introduced by the OpenZFS merge.
Have you compared vdev_geom.c in OpenZFS vs the old version?
-Alan
On Fri, Oct 9, 2020 at 3:48 PM Eric van Gyzen wrote:
> On 10/9/20 4:39 PM, Eric van Gyzen wrote:
> > Does this look familiar? I'm creating a zvol with volmode=dev, but some
> > geom code paths were taken. If this looks new, I'll provide more
> details.
>
> primarycache=none also seems to be a factor. I can easily repro with:
>
> zfs create -s -V 10G -o primarycache=none -o volmode=dev .../testvol
>
> > 13.0-CURRENT r366500+84ccaf49083c-c272054 GENERIC
> >
> > #8
> > #9 zvol_geom_bio_getattr (bp=0xf80376132900)
> > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:545
> > #10 zvol_geom_bio_start (bp=0xf80376132900)
> > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:519
> > #11 0x80b1c684 in g_io_schedule_down (tp=)
> > at /usr/src/sys/geom/geom_io.c:848
> > #12 0x80b1cfcc in g_down_procbody (arg=)
> > at /usr/src/sys/geom/geom_kern.c:111
> >
> > (kgdb) f 9
> > #9 zvol_geom_bio_getattr (bp=0xf80376132900)
> > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:545
> > 545spa_t *spa = dmu_objset_spa(zv->zv_objset);
> >
> > (kgdb) l
> > 540zvol_state_t *zv;
> > 541
> > 542zv = bp->bio_to->private;
> > 543ASSERT(zv != NULL);
> > 544
> > 545spa_t *spa = dmu_objset_spa(zv->zv_objset);
> > 546uint64_t refd, avail, usedobjs, availobjs;
> > 547
> > 548if (g_handleattr_int(bp, "GEOM::candelete", 1))
> > 549return (0);
> >
> > (kgdb) p zv
> > $1 = (zvol_state_t *) 0x0
> >
> > (kgdb) p *bp
> > $3 = {
> >bio_cmd = 4,
> >bio_flags = 0,
> >bio_cflags = 0,
> >bio_pflags = 0,
> >bio_dev = 0x0,
> >bio_disk = 0x0,
> >bio_offset = 0,
> >bio_bcount = 0,
> >bio_data = 0xf801fa687c00 "",
> >bio_ma = 0x0,
> >bio_ma_offset = 0,
> >bio_ma_n = 0,
> >bio_error = 0,
> >bio_resid = 0,
> >bio_done = 0x0,
> >bio_driver1 = 0x0,
> >bio_driver2 = 0x0,
> >bio_caller1 = 0x0,
> >bio_caller2 = 0x0,
> >bio_queue = {
> > tqe_next = 0x,
> > tqe_prev = 0x
> >},
> >bio_attribute = 0x81223c03 "GEOM::physpath",
> >bio_zone = {
> > zone_cmd = 0 '\000',
> > zone_params = {
> >disk_params = {
> > zone_mode = 0,
> > flags = 0,
> > optimal_seq_zones = 0,
> > optimal_nonseq_zones = 0,
> > max_seq_zones = 0
> >},
> >rwp = {
> > id = 0,
> > flags = 0 '\000'
> >},
> >report = {
> > starting_id = 0,
> > rep_options = 0 '\000',
> > header = {
> >same = 0 '\000',
> >maximum_lba = 0,
> >reserved = '\000'
> > },
> > entries_allocated = 0,
> > entries_filled = 0,
> > entries_available = 0,
> > entries = 0x0
> >}
> > }
> >},
> >bio_from = 0xf80006b92880,
> >bio_to = 0xf80006972500,
> >bio_length = 1024,
> >bio_completed = 0,
> >bio_children = 0,
> >bio_inbed = 0,
> >bio_parent = 0x0,
> >bio_t0 = {
> > sec = 50,
> > frac = 10248368299661698441
> >},
> >bio_task = 0x0,
> >bio_task_arg = 0x0,
> >bio_spare1 = 0x0,
> >bio_spare2 = 0x0,
> >bio_track_bp = 0x0,
> >bio_pblkno = 0
> > }
> >
> > (kgdb) p *bp->bio_to
> > $4 = {
> >name = 0xf80006972598 "zvol/disco_fast/vm/onefs1-1/disk7",
> >provider = {
> > le_next = 0x0,
> > le_prev = 0xf80006972428
> >},
> >geom = 0xf80006972400,
> >consumers = {
> > lh_first = 0xf80006b92880
> >},
> >acr = 1,
> >acw = 0,
> >ace = 0,
> >error = 0,
> >orphan = {
> > tqe_next = 0x0,
> > tqe_prev = 0x0
> >},
> >mediasize = 5368709120,
> >sectorsize = 512,
> >stripesize = 8192,
> >stripeoffset = 0,
> >stat = 0xf80006d3d120,
> >spare1 = 0,
> >spare2 = 0,
> >flags = 48,
> >aliases = {
> > lh_first = 0x0
> >},
> >private = 0x0,
> >index = 0
> > }
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 12.2-RC1 install media boot failure
I just tried to boot FreeBSD 12.1-RC1 in KVM/QEMU. Specifically, I booted FreeBSD-12.2-RC1-amd64-memstick.img as a virtual USB HDD. The console was flooded with error messages about "Device not configured"and errors from the rc scripts, then it hanged. Screenshot linked. Any ideas? http://bayimg.com/jaOnKAaga -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: should copy_file_range(2) remain Linux compatible or support special files?
On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen wrote: > > > I'll assume you are referring to the "flags" argument when you say > "param" above. > > Correct, I was misremembering the man page. > > > However, since the Linux man page says it will return EINVAL if > > the "flags" argument is non-zero, you've still introduced an > incompatibility > > w.r.t. the Linux behaviour. > > This would be a one-way incompatibility, i.e. code written on linux will > run unaltered on FreeBSD. > If the flag were along the lines of `FREEBSD_COPY_DEVICES` (or whatever, > important part is `FREEBSD`) it will be quite obvious that this code needs > to be adapted to other platforms: > ``` > #ifndef FREEBSD_COPY_DEVICES > #define FREEBSD_COPY_DEVICES 0 > #endif > ``` > > > Why require extra work for so little purpose? > > I'm sorry, I'm not sure what extra work you are referring to. Specifying > a flag on copy_file_range(2)? That's trivial. > It's easy to leave out, which could cause a lot of pain for users who don't understand why their application isn't working. > > > My opinion is that if we can make it work for character devices, we > should. > > Well, collecting opinions was the point, no? :) > > What's going to use this function besides system commands? I think I saw > `cp` and `dd` mentioned - I think it unlikely you need to be concerned > about their portability. > Userspace RAID-like applications could use it for rebuilds, and they'll need it to work on device nodes. Userspace NFS servers and iSCSI servers could obviously use it. And since the FUSE protocol includes a COPY_FILE_RANGE operation, many FUSE daemons could implement that with copy_file_range(2). -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: should copy_file_range(2) remain Linux compatible or support special files?
On Sat, Sep 26, 2020 at 8:52 PM Rick Macklem wrote: > Wall, Stephen wrote: > > Could the as yet unused options param have a bit assigned to trigger the > new > > behavior? Inform the linux community of the addition and let them > decide if they > > would like to adopt it as well. > I'll assume you are referring to the "flags" argument when you say "param" > above. > > You could. However, since the Linux man page says it will return EINVAL if > the "flags" argument is non-zero, you've still introduced an > incompatibility > w.r.t. the Linux behaviour. > It does make it clear that copy_file_range(2) will have the non-Linux > behaviour > when the flag is specified, which I think is a good idea. > I think it's just syntactic salt. Why require extra work for so little purpose? My opinion is that if we can make it work for character devices, we should. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build of poudriere 13-CURRENT jail is failed
Done. On Fri, Sep 11, 2020 at 2:27 PM Yasuhiro KIMURA wrote: > From: Michael Gmelin > Subject: Re: Build of poudriere 13-CURRENT jail is failed > Date: Fri, 11 Sep 2020 22:16:56 +0200 > > >> I made regular update of my 13-CUREENT amd64 environment from r365330 > >> to r365634. Host OS is successfully updated with regular steps written > >> in /usr/src/Makefile. But update of poudriere jail is failed with > >> error. > > > > Please see: https://reviews.freebsd.org/D26395 > > Thank you for quick reply. Then I'll wait until this review is > committed. > > --- > Yasuhiro KIMURA > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld: "cp: /dev/null: Invalid argument"
On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann wrote: > On Thu, 10 Sep 2020 10:44:08 -0600 > Alan Somers wrote: > > > No, it's devfs. I'll fix it. > > > > On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone wrote: > > > > > I'm curious: does this give a similar issue? > > > > > > touch /tmp/foo > > > cp /tmp/foo /tmo/foo2 > > > > > > I'm wondering if the issue is that copy_file_range isn't handling > > > empty files, or if it's a devfs issue. > > > > > > > > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > > > wrote: > > > > > > > > It seems that SVN r365549 broke "cp /dev/null ..." > > > > > > > > imb > > > > > > > > On 9/10/20 10:35 AM, Michael Butler wrote: > > > > > Is anyone else seeing failures like this in building world and, in > my > > > > > case, cron jobs as well? > > > > > > > > > > > > > > > Building > /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > > > > > --- all_subdir_sbin --- > > > > > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > > > > > --- all_subdir_stand --- > > > > > --- zfsboot.ldr --- > > > > > cp: /dev/null: Invalid argument > > > > > *** [zfsboot.ldr] Error code 1 > > > > > make[5]: *** zfsboot.ldr removed > > > > > --- all_subdir_kerberos5 --- > > > > > Building > > > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > > > > > --- all_subdir_stand --- > > > > > > > > > > make[5]: stopped in /usr/src/stand/i386/zfsboot > > > > > .ERROR_TARGET='zfsboot.ldr' > > > > > > > > > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > > > > > > > > .MAKE.LEVEL='5' > > > > > MAKEFILE='' > > > > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes > > > verbose' > > > > > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > > > > > .CURDIR='/usr/src/stand/i386/zfsboot' > > > > > .MAKE='make' > > > > > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > > > > > .TARGETS='all' > > > > > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > > > > > LD_LIBRARY_PATH='' > > > > > MACHINE='amd64' > > > > > MACHINE_ARCH='amd64' > > > > > MAKEOBJDIRPREFIX='' > > > > > MAKESYSPATH='/usr/src/share/mk' > > > > > MAKE_VERSION='20200902' > > > > > > > > > > ___ > > > > > freebsd-current@freebsd.org mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to " > > > freebsd-current-unsubscr...@freebsd.org" > > > > > > > > > > > > ___ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to " > > > freebsd-current-unsubscr...@freebsd.org" > > > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > I still get this error on a couple of boxes, while others seem to > buildworld > fine. All boxes are at CURRENT revision 365625. It is a bit looking weird > to > me. Running now a make cleanworld/cleandir on the specific boxes and start > building OS again. > > oh > I don't know why it's intermittent, but in any case this patch should fix it: https://reviews.freebsd.org/D26395 -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
