00:00:56 <rsjw> okay so it seems that it would write them out "occasionally," for some meaning of occasionally
00:02:05 <RhodiumToad> in practice, every mounted filesystem has a syncer thread, which schedules writing of every dirty page belonging to that filesystem at appropriate intervals, so that the disk copy of the data doesn't get too stale
00:02:18 <RhodiumToad> this is in addition to the pager's activity of reclaiming pages
00:03:03 <rsjw> right, makes sense.
00:03:08 <RhodiumToad> this is because if you mmap a file and keep writing to it, you usually want those changes written out in the background even if the system is under no pressure to free up memory
00:03:23 <RhodiumToad> you can use MAP_NOSYNC to disable this behavior, btw
00:04:24 <RhodiumToad> the syncer thread also ensures that filesystem metadata is pushed out to disk in cases where it didn't need to be immediately written
00:06:48 <rsjw> but, just to be clear, when doing regular file i/o, there are no more block devices and so the file i/o would not use this unified VM cache and instead it would be send straight to the disk, correct?
00:07:00 <RhodiumToad> no
00:09:26 <RhodiumToad> this is slightly complicated by the fact that although the old buffer pool was eliminated, the buffer _headers_ for it were not, they just now point to VM pages usually
00:10:05 <RhodiumToad> very broadly speaking, what happens if you do a write() call to an open file on a UFS filesystem is something like this:
00:11:19 <RhodiumToad> the write call goes through the file table and the vnode table and arrives at ffs_write, which repeats this sequence:
00:12:44 <RhodiumToad> allocate a buffer header, ask the VM to populate it with existing data if this is an unaligned write, move data from userspace into the buffer,
00:13:39 <RhodiumToad> then tell the buffer management code to possibly schedule a write (immediate write, async write or delayed write depending)
00:13:54 <RhodiumToad> and repeat until no more data is to be moved
00:14:56 <RhodiumToad> but the point is that the buffer headers don't point to some different part of memory, but rather the _same_ memory pages that would be mmapping the file if it is mmaped
00:15:35 <RhodiumToad> so e.g. if you mmap a file that was previously written to, the mmap will just map in the already-existing pages, it won't try and copy anything
00:15:51 <RhodiumToad> the buffer header management code works in coordination with the VM system
00:18:06 <rsjw> it indeed does sound quite "unified." :)
00:18:41 <RhodiumToad> obviously a fair amount of how this works is up to the filesystem code
00:19:06 <RhodiumToad> so for example ZFS does its own thing which is likely to be somewhat different
00:19:18 <RhodiumToad> (which has led to bugs in edge cases)
00:24:02 <RhodiumToad> the main thing to remember is that because it's all unified, there's no expectation that memory will be "free" on a system with any noticable amount of activity
00:24:24 <RhodiumToad> and also, if you look at something like this from top(1):
00:24:29 <RhodiumToad> Mem: 2432K Active, 3593M Inact, 3660K Laundry, 510M Wired, 165M Buf, 263M Free
00:25:08 <RhodiumToad> you shouldn't assume that any of those correspond to either application memory or filesystem cache, almost all of the categories are a mix of both
00:26:03 <rsjw> right, because it reflects the unified VM values
00:26:08 <RhodiumToad> in that particular example, most of the "Inact" category will be file data
00:26:49 <RhodiumToad> but under different kinds of workloads, you might have a large Inact queue containing mostly program memory
00:27:38 <RhodiumToad> the Active / Inact / Laundry distinction is based on whether the data has been recently touched or dirtied, not on what kind of data it is
00:28:15 <RhodiumToad> There are some optimizations specific to files. for example, file read()/write() calls can be detected as being sequential, and optimized accordingly
00:31:49 <rsjw> with freebsd having only raw (unbuffered) disk access and not block (buffered) disk access, how does that relate to the unified VM? does the raw access bypass the unified VM, or do the pages just not stick around in the unified VM as long as the buffer cache did, or are raw accesses actually buffered?
00:32:33 <RhodiumToad> if you write to the /dev/da* (raw) device using write(), those writes are both completely unbuffered and also synchronous
00:33:19 <RhodiumToad> (i.e. the write() call doesn't return until the hardware has said the write is complete - bear in mind the hardware may be lying about that)
00:34:36 <rsjw> does "unbuffered" refer to bypassing the unified VM?
00:34:40 <RhodiumToad> yes
00:35:03 <RhodiumToad> this is why for example when copying an image file to a usb drive using dd, one should use bs=128k or so
00:35:29 <RhodiumToad> (otherwise it will be much slower than necessary)
00:38:07 <rsjw> does this mean that the unified VM is only involved in file i/o when the file is mmapped, but not when you use, say, read/write while the filed is not mapped?
00:38:27 <rsjw> s/filed/file
00:38:49 <RhodiumToad> no, it means that the unified VM is involved in all _filesystem_ I/O, but not to accesses to /dev/*
00:42:43 <rsjw> when you say "filesystem i/o" are you referring to only the directory structure/metadata/etc of the filesystem and not to the data of the files?
00:43:55 <RhodiumToad> no, I mean all access that goes via a filesystem, including the file data
00:45:04 <rsjw> because if file i/o is always unbuffered due to lack of block devices, and "unbuffered" refers to bypassing the unified VM, then I don't see how file i/o would go through the unified VM
00:45:10 <RhodiumToad> i.e. writing to /home/andrew/myfile  is filesystem access, but writing to /dev/da0 is not
00:45:46 <RhodiumToad> I literally just explained to you how writing to a file goes through the unified VM
00:47:19 <rsjw> okay, I think I see what you're saying
00:47:44 <RhodiumToad> there are only two common cases where the lack of block devices makes a difference. One is when you copy data to/from raw devices using dd, for example to make disk images or boot media
00:47:58 <RhodiumToad> the other is when porting FUSE filesystems from linux
00:50:37 <rsjw> okay so it sounds like the old buffer cache cached data after it was written to disk, but the new unified VM cache caches data after it's written to the file system
00:51:23 <rsjw> so it basically shifted where it was in the processing pipeline (and got unified with the page cache, of course)
00:51:51 <rsjw> so file i/o is still cached, just not at the same point
00:52:21 <RhodiumToad> well the old-style cache didn't cache only after writing, it was a writeback cache
00:53:48 <rsjw> right
00:58:26 <rsjw> thanks for the information, it's been very helpful
00:59:48 <RhodiumToad> also bear in mind that the "new" unified VM has been around for, I think, at least as long as I've been using FreeBSD
01:00:07 <RhodiumToad> which is over 26 years now
03:59:39 <occ> where  can I find doc on how to configure ipv6 DHCP ?
04:37:06 <spork_css> got a kind of urgent one if anyone is around...
04:37:17 <RhodiumToad> ?
04:37:22 <spork_css> BTX loader ("1.00") BTX Version 1.02
04:37:34 <spork_css> Any way to make it NOT probe a bad disk and wait?
04:37:45 <RhodiumToad> oof, old-style
04:38:05 <RhodiumToad> sec
04:38:22 <spork_css> Like I know if I get to the next stage (beastie menu) there's lots to do, but I'm stumped on this.
04:38:37 <RhodiumToad> which disk is dead?
04:38:38 <spork_css> I don't even need the bad drive to function, I know it's bad.
04:38:54 <spork_css> It's part of an old zfs pool that's all HDDs.
04:40:31 <spork_css> It's reading out all the drives OK (2 boot SSDs, 2 HDDs on one SATA controller - 4 SSDs on the other), but the part where the spinner should be spinning, it's spinning like 1 notch every 15 minutes.
04:40:35 <RhodiumToad> what messages have come up before it hangs?
04:41:25 <spork_css> ie: https://i.imgur.com/rl3BlNT.png
04:41:29 <spork_css> That's it...
04:41:49 <spork_css> The BIOS alerts me that one of the drives is marked bad by SMART (which I know).
04:42:16 <RhodiumToad> can you disable the drive in the bios? that should be enough
04:42:45 <RhodiumToad> BTX is a dos-extender, i.e. it's still actually using the bios for doing i/o
04:43:04 <RhodiumToad> (you might then have to use the loader prompt to stop the kernel from accessing it)
04:44:18 <spork_css> Is there a prompt for BTX? I'm really fuzzy on it these days.
04:44:50 <spork_css> Also dug through the BIOS and was not seeing a way to disable a drive - I could set hot swap on/off, set drive type to SSD/HD and that's it.
04:45:45 <RhodiumToad> pretty sure there's no way to get to a useful prompt before loader is up
04:46:05 <RhodiumToad> how many drives are there and which one is bad?
04:46:29 <RhodiumToad> (I see there are 8 in the list, is that all of them?)
04:46:34 <spork_css> 8 drives and I'm not sure which one maps to which drive letter
04:47:34 <RhodiumToad> ok, so the fact that it prints the list means that it probed all the drives
04:47:38 <spork_css> I'm torn between waiting it out and going back into the BIOS
04:48:09 <spork_css> This is the first boot into 12.4 - just did a freebsd-update from (cough) 12.2.
04:48:23 <RhodiumToad> so it's hung at some point after bd_init, probably at the point where it tastes all the disks it found
04:48:26 <spork_css> And of course, the host is remote, so I can't physically pull the problematic drive.
04:48:50 <RhodiumToad> was it booting ok under 12.2, or had it been up for a long time?
04:50:05 <RhodiumToad>  /* XXX this gets called way way too often, investigate */
04:50:13 <RhodiumToad> gotta love comments like that
04:50:41 <spork_css> Up for about 4 months - last boot was a zfs scrub having issues with this same drive and it paniced a few times.
04:50:47 <RhodiumToad> fortunately that's not the problem
04:51:02 <RhodiumToad> ok, so the drive was known-bad from way back
04:51:08 <spork_css> It came up OK post-panic, then after I moved everything off the bad pool, I manually rebooted w/o issue.
04:53:02 <RhodiumToad> hm
04:53:14 <RhodiumToad> so it didn't get as far as printing the memory size
04:53:38 <RhodiumToad> which is literally the line after devinit(); so that's where it hung?
04:56:43 <RhodiumToad> so the next probe after that is vdisk_dev, which is probably not doing anything,
04:56:47 <spork_css> hold on, just rebooting again to get into bios and dig
04:56:51 <RhodiumToad> but then the next one is zfs_dev
04:57:09 <spork_css> It was still at the same spot as that imgur png above (if you saw that)
04:57:30 <RhodiumToad> so it looks like it's the point at which it tries to figure out the available zpools that's the problem, not unexpected
04:57:59 <RhodiumToad> I'm not seeing any way to disable individual disks before that point.
04:58:09 <spork_css> Kind of a not great design to have the thing that's necessary to boot have no config...
04:59:43 <RhodiumToad> well it does have a config, it's just that it wants to know what devices it has before doing a prompt
05:00:13 <RhodiumToad> and without UEFI, it's a bit constrained on functionality
05:00:50 <spork_css> the host has UEFI, but never set it up on the FreeBSD side (not that I know how)
05:01:05 <spork_css> https://i.imgur.com/dV1etKc.jpg - sata setup it's the first HGST
05:02:34 <RhodiumToad> no option anywhere to disable that data port entirely?
05:03:15 <spork_css> nope - I've got spinup (which is actually spinup delay enable/disable) and hot swap yes/no
05:03:53 <spork_css> Oh, the kicker? Boot drives are UFS.
05:04:31 <spork_css> Sadly my ssd pool goes across the two built-in controllers, so if I disable my SATA controller with the HDs on it, I then have another pool not working.
05:06:29 <RhodiumToad> I'm digging through the code, but I'm not seeing any good solution yet
05:09:11 <spork_css> I hate The Cloud, but I do like "hardware is someone else's headache".
05:10:05 <RhodiumToad> so zfs_probe probes every partition on every physical disk, and I don't see any way to exclude anything
05:10:42 <RhodiumToad> (and it doesn't print anything until they're all done)
05:11:57 <spork_css> I wish I could know whether it's just probing very slowly or if it's just locked itself up.
05:12:10 <spork_css> The cursor under the spinner blinks and the host does reboot with ctrl-alt-del.
05:13:50 <spork_css> there are no keyboard commands here right? Like you can't cancel out or anything.
05:15:14 <spork_css> Well, I'm going to let it try booting, eat dinner (yes 1 a.m.), pull backups for two things that aren't redundant, and slap them elsewhere and then see about remote hands.
05:16:05 <RhodiumToad> I don't see any keyboard interaction.
05:16:41 <RhodiumToad> the zfs code isn't even calling twiddle() anywhere i can see, which explains why it isn't spinning
05:16:56 <spork_css> ugh
05:17:07 <spork_css> Would I be in this mess with UEFI?
05:17:52 <RhodiumToad> I believe that with UEFI you'd have more chances to disable the drive before getting into the loader. but it would depend on the UEFI implementation
05:18:44 <spork_css> Is the BTX loader still used in UEFI boot or no?
05:18:55 <RhodiumToad> not the BTX version, no
05:19:20 <RhodiumToad> it's the same loader, but using UEFI services to scan and access the hardware rather than the legacy BIOS
05:20:30 <RhodiumToad> the UEFI environment potentially allows executing other programs before booting, but I haven't experimented with it much
05:20:46 <RhodiumToad> (other than under bhyve, which has a very minimal UEFI)
05:23:03 <spork_css> Hmmm, interesting.
05:23:46 <spork_css> I really appreciate you digging through all this stuff, I'm so rusty. I started back at FreeBSD 2.1.6 or so.
05:23:58 <RhodiumToad> me too :-)
05:24:09 <ixmpp> it doesn't even have boot options, does it (bhyve uefi)
05:24:22 <RhodiumToad> but I've been using fbsd as my main desktop and development environment ever since
05:24:58 <RhodiumToad> ixmpp: last I looked it had no support for persisting any variables between boots
05:25:14 <RhodiumToad> ixmpp: also, I think it lacks a shell
05:25:21 <ixmpp> very minimal indeed
05:26:00 <RhodiumToad> it can load and run bootx64.efi and that's about all
07:50:30 <spork_css> RhodiumToad: https://i.imgur.com/ZpvBlpv.jpg it has  printed "ZFS: can't find vdev details" 3x, about once/hour.
07:50:57 <spork_css> and it just booted it seems!
08:49:06 <trev> every time i try building with poudriere my pc freezes lol. i tried to limit the memory in poudriere.conf to a low number..does it not care if the host runs out of memory?
08:49:34 <trev> i.e should i be shutting all my programs and making sure the host doesn't use any memory while the jail builds stuff?
08:53:10 <trev> hehe froze again
09:05:47 <meena> trev: that sucks
09:05:59 <meena> wait.
09:06:13 <meena> just poudriere, or ports in general?
09:18:59 <debdrup> trev: can you throw your poudriere.conf in a pastebin, and tell us a bit about your system (number of threads according to sysctl -n hw.ncpu, amount of memory, et cetera)?
09:19:34 <debdrup> Also, what sort of things are you building? Does the graph include llvm/gdb, and things like Firefox or Chromium?
09:20:45 <debdrup> s/gdb/gcc/
09:22:05 <debdrup> By default poudriere will use one job per builder jail, but if you've overwritten that in order to get compilers or browsers to build faster, it's not impossible that you're ending up with only half a GB of memory per thread (which isn't a lot, when doing multi-threaded compiling). If on top of that you're putting all your artifacts (ie. distfiles, workdir, object files, et cetera) in tmpfs, that's even
09:22:11 <debdrup> more memory contention.
09:42:01 <trev> meena: seems work on regular ports builds
09:42:11 <trev> i am trying to build kitty terminal
09:42:32 <trev> but honestly trying to build it makes me want to not use it cause it is a bloated mess
09:42:56 <trev> i reduced tmpfs to 1GB
09:43:36 <trev> and gave 8GB poudriere under MAX_MEMORY
09:44:50 <trev> debdrup: let me pastebin for you
09:48:28 <trev> debdrup: https://termbin.com/qxo3
09:48:58 <trev> ignore the neofetch on the bottom. i though that would work to show system specs but it's just a mess
09:49:52 <debdrup> just do `head -n30 /var/run/dmesg.boot`
09:52:24 <trev> https://termbin.com/fzfs
09:53:16 <debdrup> MAX_MEMORY and TMPFS_LIMIT are both per-jail, and with 4 threads that means you need 36GB memory.
09:53:45 <trev> -_-
09:53:57 <debdrup> So yes, you're having severe memory contention. ;)
09:54:15 <debdrup> Poudriere is meant to run on build servers with hundreds of GB of memory.
09:54:53 <trev> good to know...i just wanted to keep my system clean and then wipe the jail after the build :\
09:57:38 <trev> let's try again with lower numbers
09:57:43 <trev> if i leave then you know i crashed :')
09:58:24 <debdrup> Does your system have swap? You might be able to get away with halving MAX_MEMORY.
09:58:34 <debdrup> Swap on an NVMe SSD, I mean.
10:00:55 <trev> no not on nvme
10:01:03 <trev> just regular sata ssd
10:05:23 <debdrup> welp
10:07:23 <trev> instant freeze again
10:07:53 <trev> some people aren't just meant to be a beastie
10:08:01 <debdrup> I see that the CPU isn't exactly new; is it possible that you need to reapply the thermal grease, because the CPU is overheating?
10:08:35 <debdrup> Typically FreeBSD won't freeze when it's running out of memory, it'll just start killing processes that take up the most amount of memory.
10:09:36 <beastie> ey.... please... a bit of respect.
10:10:23 <debdrup> https://cgit.freebsd.org/src/tree/sys/vm/vm_pageout.c#n1900 this is the code that handles OOM, and it's pretty good at it.
10:10:25 <VimDiesel> Title: vm_pageout.c « vm « sys - src - FreeBSD source tree
10:11:38 <trev> could be the case, but i am able to build other software
10:11:49 <Ellenor> ugh
10:12:16 <trev> unless freebsd can't control my fans
10:12:18 <Ellenor> so regarding powderkeg, I should use a sacrificial nvme instead of tmpfs?
10:12:24 <debdrup> Well, I've no real answers for you, other than that you're still probably contending on memory.
10:12:43 <debdrup> If FreeBSD can't control your fans, the CPU has its own fan control that takes o ver.
10:13:01 <debdrup> Ellenor: I've no idea how you came to that conclusion.
10:13:44 <debdrup> See my comment about poudriere being built with the assumption of a LOT of memory available.
10:14:47 <Ellenor> ah
10:15:59 <debdrup> Swapping to an NVMe SSD _can_ make it possible to go a little over - ie. trev has 16GB system memory and, I assume, 16GB swap, and 4x(4+1)=20GB as the maximum memory that the builders+tmpfs can take up.
10:16:28 <Ellenor> Hm.
10:16:33 <debdrup> It's not gonna as fast as it could be, but FreeBSD shouldn't be freezing from it.
10:16:37 <Ellenor> aye.
10:52:40 <Remilia> trev: you can blacklist certain packages from putting wrkdirs in tmpfs
10:52:59 <Remilia> I do this for rust because my poudriere VM has 16 GB RAM
10:53:14 <Remilia> sure it slows the process down but at least there is no oomkilling going on
11:26:33 <_xor> Oooooh, this looks pretty cool. Going to have to check this out...
11:26:36 <_xor> https://github.com/ast-grep/ast-grep
11:26:37 <VimDiesel> Title: GitHub - ast-grep/ast-grep: ⚡A fast and easy tool for code searching, linting, rewriting at large scale. Written in Rust
11:36:14 <meena> "You can install it from npm or cargo!"
11:37:06 <meena> why on earth would i want to install anything from npm, if i don't absolutely have to?
11:37:34 <debdrup> devops.
11:39:39 * meena got stuck in Puppet being DevOps, and hasn't made it into JavaScript or Kubernetes being DevOps
11:41:06 <trev> Remilia: i turned tmpfs off
11:41:18 <trev> also, is there just a public repo of ports that i can just use to get bins?
11:41:42 <trev> cause i don't have a good enough build machine i guess
11:42:05 <meena> pkg install
11:42:31 <trev> meena: we went over this before...
11:42:40 <trev> it's not in the pkg repo
11:43:32 <meena> i have very short memory
11:43:45 <trev> am i missing something though?
11:44:10 <meena> unless I'm actually involved, it gets swapped out very quickly
11:44:29 <meena> you were trying to build kitty terminal?
11:44:32 <trev> yeah
11:45:12 <dubiousness> Not sure how anything JS specifically constitutes DevOps
11:45:24 <dubiousness> DevOps is just a means to an end, and is relatively tool agnostic
11:45:33 <dubiousness> You could make an entire devops flow with zfs and Make if you wanted to
11:45:37 <dubiousness> "devops flow"
11:45:58 <dubiousness> s/zfs/zsh/g
11:47:06 <meena> nah, I want the other one. zfs. we store data in zfs props
11:47:55 <meena> i had a setup with GNU make, that provisioned VMs long before discovering Puppet
11:48:13 <dubiousness> I have strong opinions about Puppet, but they're probably several years out of date
11:48:16 <debdrup> trev: poudriere supports fetching binary packages for dependencies using the -B flag, if memory serves.
11:48:32 <debdrup> That way you only use poudriere to build the package that you're looking for.
11:48:37 <dubiousness> I like the idea of storing releases in ZFS snapshots or similar though, and doing a blue/green release gradually over a fleet.
11:48:40 <dubiousness> Feels like a summer project
11:49:37 <debdrup> https://portsfallout.com/fallout?port=x11%2Fkitty%24 seemms like there's fallout for kitty though, so I'm not sure that'll work.
11:49:39 <VimDiesel> Title: Fallout list - FreeBSD pkg-fallout
11:49:43 <meena> (Make is awesome for that kinda thing because it's idempotent, or can be, if you write it correctly)
11:51:01 <Remilia> debdrup: and the error is not in kitty
11:51:04 <debdrup> trev: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270871
11:51:06 <VimDiesel> Title: 270871 – x11/kitty fails to build with invalid UTF-8 in comment using poudriere on stable-13.2 amd64
11:51:20 <trev> i know this bug, but i think it's patched already
11:51:21 <debdrup> Remilia: nonetheless, this is exactly what the bugzilla is for
11:51:34 <trev> my ports have the latest patch
11:51:42 <trev> maybe the ports in my jail don't...
11:52:14 <debdrup> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270703 this is the update, which mentions nothing of the bug as far as I can see
11:52:16 <VimDiesel> Title: 270703 – x11/kitty: Update to 0.27.1
11:54:23 <trev> ah yeah, correct
11:54:28 <debdrup> So this appears to have been an XY problem all along.
11:54:37 <trev> oh well. i've spammed the chat with this crap enouhg
11:54:42 <trev> i will just use st
11:54:51 * debdrup uses alacritty and is very happy.
11:55:09 * trev needs ligatures or will become depressed
11:55:28 <debdrup> Ligatures is a font thing, nothing to do with the terminal emulator.
11:56:44 <trev> heh..try it then
11:57:09 <trev> it was a controversial topic on the alacritty repo
11:57:15 * debdrup shrugs.
12:07:50 <debdrup> trev: Irrespective of that, it's always a good idea to precisely state what you're doing, and to iterate it if the conversation seems to drift off.
12:08:21 <debdrup> XY problems aren't ever going to go away, but that doesn't mean we can't try to reduce them.
12:09:28 <debdrup> I wasn't privy to the prior conversation (or don't remmeber it because of chemobrain), so you trying to build it and running into memory contention issues from less-than-optimal configuration seemed like the problem whereas what you were actually struggling with is a bug that's already been reported.
12:10:07 <trev> debdrup: true. i should have looked harder for current issues with kitty. i am new to freebsd and a bit overwhelmed, while trying to rush to get things set up in my free-time. need to read more
12:10:37 <debdrup> trev: that's fine, we all start somewhere. I have a few hints though, since you're new.
12:11:30 <debdrup> If something in ports/packages is broken, going to https://www.freshports.org/x11/kitty/ (using kitty as an example) will present you with a bunch of icons next to the version and category (under the name and short description)
12:11:31 <VimDiesel> Title: FreshPorts -- x11/kitty: Cross-platform, fast, featureful, GPU-based terminal emulator
12:11:57 <debdrup> these are quick links to find dependencies, find bug reports, and find ports fallout (ie. if something is broken, you can locate the logs)
12:12:24 <debdrup> Hovering over the icons should tell you exactly what they do
12:14:17 <debdrup> That might help you ask better questions :)
12:14:41 <debdrup> If you ever need to file a bug report, https://docs.freebsd.org/en/articles/problem-reports/ is invaluable.
12:14:42 <VimDiesel> Title: Writing FreeBSD Problem Reports | FreeBSD Documentation Portal
13:17:18 <trev> thanks debdrup!
15:54:05 <debdrup> Oh, in case anyone was wondering, in talking about scrypt in crypto(9) to replace PKCS#5, Colin brought up the excellent point that in the loader environment, there isn't a whole lot of memory available (especially not on BIOS+MBR systems, but it's not exactly great in UEFI+GPT+ESP land either).
16:16:58 <debdrup> meka: your blog appears to have 404'd.
18:03:16 <meena> i wonder if you can build vnet transport on top of https://man.freebsd.org/vale(4) for interconnecting local jails
18:03:17 <VimDiesel> Title: vale(4)
18:16:41 <debdrup> meena: I've wished someone would do that for.. at least 10 years.
18:25:57 <meena> how hard can that be??
18:26:23 * meena slaps that on her very short TODO list
18:27:00 <meena> the TODO list starts with tidy my daughter's room, and goes sharply down hill from there
18:42:45 <coreystephanphd> meena: such TODO lists are best kept separate -- things I enjoy (BSD, food, reading), another for things I have to do quickly but do not enjoy (cleaning daughter's room, lawn work) -- good luck
18:56:09 <trev> coreystephanphd: hi dr. corey. big fan here. every time i read/watch your work i wonder how this guy does all that he does!
20:00:40 <RhodiumToad> sooo... for sanity checking purposes, is there any reasonable upper bound for what anyone might set kern.maxfilesperproc to?
20:03:59 <RhodiumToad> gotta love code where the comments totally disagree with the actual logic
20:04:24 <RhodiumToad> "At most it can be 1/6 the number of physical pages."  if (maxfiles > (physpages / 4)) maxfiles = physpages / 4;
20:04:39 <RhodiumToad> hint, 4 and 6 are not the same number :-)
20:07:31 <RhodiumToad> hm, are there systems with >=8TB of RAM around in the wild?
20:09:01 <RhodiumToad> because with 8TB,  maxfiles = imax(MAXFILES, physpages / 8);  isn't going to do the right thing
20:29:52 <michelem> hi folks! Can anyone have a look at this? I think I'm getting stupid. Or huge bug in "ls" –> https://dpaste.org/gavd6
20:29:53 <VimDiesel> Title: dpaste/gavd6 (Plain Text)
20:47:57 <michelem> I suppose ls refers to which filesystem item to stat when talking about "reference". stat can be used to find out the actual referenced file.
20:50:22 <RhodiumToad> use the -l option as well as -L
20:52:02 <RhodiumToad> if you're confused by the name not changing, that's because the name is always what you specified on the command line (or read from readdir)
20:54:15 <yuripv> "ls shall write the name of the link itself and not the file referenced by the link." posix description for -H
20:54:48 <yuripv> (part of, if you are asking why it shows the link and not the file it points to)
20:55:11 <yuripv> same for -L
20:56:43 <RhodiumToad> (if you think about it, the purpose of `ls` is to list what the names are _in that directory_, so it would make no sense to list the target name)
20:57:20 <RhodiumToad> (yes, in this case the target is also in the same directory, but that's a special case - in general, symlinks can point anywhere)
21:01:26 <meena> trying to remember which awful #unix channel i used to hang out in which had an FAQ that started with: I just discovered a huge bug in rm! — no, you didn't.
21:16:56 <meena> hrm… bhyve can work with vale
21:17:59 <coreystephanphd> trev That means a lot -- thanks :)
21:23:24 <debdrup> RhodiumToad: in the wild is a relative term. Yes, vendors do claim they can sell you a system, but if you ask for a price you can't afford it.
21:25:42 <RhodiumToad> yeah, I'm just looking at code in the kernel that goes to UB when memory exceeds some threshold, and wondering if anyone ever hit it
21:26:51 <debdrup> I've seen one system with 2TB memory.
21:26:58 <RhodiumToad> so far, the worst assumption I've found is that physpages / 4 fits into a signed 32-bit int, which would break at 4TB
21:27:32 <RhodiumToad> er, 8TB
21:27:35 <debdrup> I think mjg is likely to run into it first, with his attempts to make things scale.
21:27:55 <RhodiumToad> no wait, 2TB
21:28:27 <RhodiumToad> eurgh, can't calculate today
21:29:23 <RhodiumToad> 8TB in 4k pages makes physpages not fit in signed 32 bits, which is ok because physpages is stored as a long
21:29:45 <RhodiumToad> 16TB would make physpages / 2 overflow a signed int
21:30:31 <RhodiumToad> so 32TB is the point at which the worst assumption I've seen so far would break
21:32:50 <michelem> RhodiumToad: I guess that's just one more sign that `ls` is a CLI tool, not one for scripts.
21:33:33 <RhodiumToad> michelem: why so?
21:34:16 <RhodiumToad> (admittedly in scripts it's often the wrong tool)
21:35:03 <michelem> what is confusing there is that all arguments (-L -H -P) have different symlink-specific semantics but produce the same output. Their description is ambiguous enough to allow thinking otherwise, and that's compounded by the fact that `ls` does list extra-dir information with `-l` . `-l` is not a usable parameter for scripting though. Indeed, `stat` is the tool for that. low-level, but never disappoints.
21:35:37 <RhodiumToad> they only produce the same output in cases where you're not actually asking for any information beyond the filename which you already know
21:37:19 <michelem> thanks for looking into it and for your friendly and competent answer.
21:37:45 <RhodiumToad> though when the link is to a directory you'll see more significant differences
21:41:13 <debdrup> Hmphm. Tried searching dmesgd for 2199023255552 to find the system I thought I remembered, but either that's wrong or I remember wrong.
21:43:12 <V_PauAmma_V> RhodiumToad, "Actually, finding a disagreement between the comment and the code tends to mean both are wrong" - Steve McConnell.
21:43:31 <RhodiumToad> yeah, I know :-)
21:44:23 <paulf> But more often code and comments and consistent, but both wrong
21:50:23 <V_PauAmma_V> That could be. But the adage I quoted saves you from having to decide which is correct when they differ.
21:51:03 <V_PauAmma_V> (I'm no longer a software dev. Haven't been for several years.)
22:09:16 <RoyalYork> I know this isn't a FreeBSD question specifcally, but I'd figure ill throw it outthere to the general public: If i self-sign a certificate for a website, is it normal to get a padlock in the searchbar but still have it say Connection Not Secure?
22:11:28 <parv> Yes
22:11:54 <parv> But depends on the browser really
22:16:29 <RoyalYork> Firefox in this case
22:16:38 <RhodiumToad> the browser will throw up the insecure warning page if it can't trace the certificate to something it trusts
22:17:15 <RhodiumToad> obviously a self-signed cert won't pass that test unless you also tell the browser to trust it
22:17:49 <RhodiumToad> these days, of course, you can just use an LE cert instead
22:19:33 <XeniN> royalyork: google letsencrypt. you may get trusted cert for free... , other solution would be create own ca and install ca certificate on browser storage , then just sign your certs with own ca
22:20:31 <RhodiumToad> letsencrypt is the best way to go by far if you expect anyone who isn't you to visit the website
22:21:54 <RoyalYork> I'll look into that, thanks