03:28:03 MelMalik: uh, it might be possible to put a bootloader on a different disk, but just make a backup and reinstall 03:34:21 the problem is no longer live; i put the bootloader on the same disk as the pool and all became well 03:54:46 great 08:14:14 veg: just unmount the "top" filesystem in the hierarchy, zfs will do the rest 08:15:05 my general suggestion is to do all fs mounting outside the jail, in exec.created and exec.release steps in jail.conf 08:19:37 Demosthenex: you could consider a zfs dataset and force `sync: disabled` `atime:off` which will allow zfs to bundle even async writes into transaction groups, *by lying about fsync to the applications* 08:20:13 its a signficant change from data loss aspect if you lose power / crash the server 08:32:49 Demosthenex an alternative is to use a ZIL which passes the small sync writes directly to a dedicated SSD, which can then be bundled up later into async writes to the main zpool 08:32:57 https://www.servethehome.com/what-is-the-zfs-zil-slog-and-what-makes-a-good-one/ for example seems a reasonable explanation 08:35:59 Demosthenex: so a dedicated ZIL is the "correct" option, and sync:disabled is the cheap/risky option 09:20:49 dch: sync:disabled sounds similar to what i'm doing today 09:21:40 Demosthenex: the only other thing I can think of, is to have a longer txn time, but IIRC that would impact the whole server 09:22:44 s/txn/txg/ 09:27:32 yeah, i'd prefer it only impact the one filesystem 09:27:58 sounds like sync disabled just ignores the app calling sync, turning sync io into async io. not sure that'd cache more to ram 09:28:14 if zfs is trying to dump to disk frequently. i'm only trying to do it once every 15 min 09:28:33 and i need to coordinate it so i get a good snapshot. i can lose 15 min, but i need a consistent snapshot 09:31:09 Demosthenex: you mentioned that your workload trashes SSDs, this is typically related to write amplification (wrong logical sector size as seen by FS, vs physical size on device) 09:31:40 and/or many many small allocations, which is what sync (or a ZIL) helps more with 09:34:15 but if you need more stuff cached, then either add RAM, or add a nvme read cache device (L2ARC) 09:35:44 zfs will write to disk at least every 5s by default, this is the transaction group (txg) 09:36:10 but delaying that out to 15 *minutes* seems extremely counterproductive 10:18:32 plaese let me report that I have now fully working laptop without INET (legacy IP) support 10:18:56 the wireless connection is working fine 10:19:43 this laptop is immune to all legacy IP attacks 10:38:20 only INET6? funny 10:55:35 dch: so to be fair, it's just minecraft. ;] but it's a known write spammer. i don't know the specific IO characteristics, but i've lost ssds that way in the past. i tend to host the game in a ramdisk, then i use a cron job to rsync down to disk for a consistent copy 10:56:27 the idea of delaying writes and such is the opposite of my professional experience where every write counts, data cannot be lost, databases write with fsync mandatory, etc :P 10:56:35 mvanbaak: we will disable INET at some point, the same way IPX got disabled in the past 10:56:43 mzar: \o/ how do you get to e.g. github? 10:56:57 do you have some nat64 or something similar on a gateway? 10:57:19 the current game is now over 20GB ramdisk, and so i'm looking at alternatives. that's why i was thinking a COW buffer. but maybe zfs sync=disabled, and a longer txg delay may work 10:57:45 btw I get ~ 200Mb/s on the new if_iwx driver now, which is awesome 10:58:10 nice 10:58:16 Demosthenex: there's a zfs histogram thing somewhere, shows you size of writes 10:58:24 * dch rummages around in history 11:02:33 Demosthenex: https://gist.skunkwerks.at/dch/62d6c56f40cf4338a2d3027c5d3301ff 11:03:13 aah bonus, its not even zfs specific, so you can see what sort of i/o pattern is used from minecraft (change the process name from firefox ofc) 11:19:31 dch: Is there a way you can limit that to local files? If I understand correctly network read/write will also show up there. 11:24:22 hm, the vfs layer should have probes for write to, that should only be writes to filesystems then, but no idea how it is named 11:25:50 erk: my dtrace skills are pretty limited, but this would be a nice addition. I don't yet know how we'd filter on that, syscall:: is the wrong layer, we'd need vfs or similar 11:31:39 maybe fbt::VOP_WRITE_AP: ? 11:36:01 oh, and you can inspect fds[arg0].fi_fs in the syscall probe maybe, not sure how portable that is https://www.brendangregg.com/DTrace/DTrace_Chapter_5_File_Systems.pdf 11:44:48 I really need to sit down and learn dtrace one of these days. not knowing it is holding me back 12:05:59 dch: unfortunately iostat and other tools don't work on tmpfs 12:06:40 dch: I have nat64 to connect to github 12:07:56 will iwm(4) get 802.11ac support ? 12:28:01 mzar: with clat? 12:30:18 nimaje: yes 13:01:49 mzar: I would assume all the new stuff goes into if_iwx(4) and if_iwlwifi(4) 13:02:12 but check the manpage for the latter at least, it reports which devices are supported and it goes quite a way back already 13:02:22 iwx manpage is still wip I think 13:05:20 dch: thans for the clue, I had to switch from iwm to iwlwifi 13:20:01 dch: that gist, what's a .d? what's making your graph? 13:20:27 hmm is there a IRC channel for pf/networking for freebsd, my messages just get lost to the backlog :/ 13:24:37 Demosthenex: a dtrace script as you can see from the shbang and dtrace has many nice features like quantize() 13:25:25 nimaje: sorry must have missed the shebang. awesome 13:25:57 polarian: you can check the channel list, but that's the nature of irc. people who care scroll back a reasonable amount and read ;] 13:27:15 or you keep bumping your messages and annoy the absolute fuck out of people 13:27:35 I could use the ML but asking stupid firewalling questions on there will be cemented into history 13:27:42 anyone with a search engine can read your fuck ups :p 13:27:52 I guess thats not the worse thing, unless you make a complete show of yourself 13:29:04 issue is claws-mail is broken since the Q2 port snapshot, so I was going to try alpine like I have wanted to for ages, but I cant seem to set the user-id for the email and therefore cant use ML right now :/ 13:30:15 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285900 possibly due to this :/ 13:33:47 polarian: there is #pf on this network 13:33:59 tykling: that is mainly focused at openbsd no? 13:34:35 oo 8 people! 13:34:38 it doesn't say :) I use it on freebsd 13:34:49 how many people do you need to answer a question 13:34:55 <[tj]> polarian: you could also ask in discord 13:37:39 tykling: 1 other, provided they aren't a zombie account :P 13:37:47 I was surprised there was even 8 people in the channel 13:37:57 [tj]: I rather not fix the problem than install Discord :P 13:38:22 <[tj]> it is nice that some people have a choice about the tools they get to use 13:41:03 polarian: so... you want free support, you want to dictate the medium where it happens, and 8 people is not enough for you to even try to ask your question. Do you think maybe your expectations need some adjustment here? 13:42:15 tykling: If that medium involves compromising security, freedom and privacy then yes, I rather not solve the problem :) 13:43:22 and I was going to ask my question in #pf it takes a bit to type and I was on a different workspace not using my IRC client, do I need to instantly post to #pf? please do not make assumptions that I do not deem 8 people good enough 13:43:39 alright, well good luck with it 19:51:33 I have cursed ideas in my skull 23:07:20 Question! I am ssh'ing to do Dev on a device that is frequently rebooting (kernel crashes) 23:07:38 I'm wondering if there is an alternative to vs code that has similar functionality that I could use/ 23:07:53 by "similar functionality", I just mean text editing and a terminal. 23:09:29 why are you trying to dev on a crashy machine? 23:09:41 I'm doing kernel work for FreeBSD. 23:12:19 farhan: do work locally and rsync it over 23:12:37 rsync -zvah local-dir user@remote:/path/to/dir 23:12:58 omit the -v if you don't want verbose 23:14:15 farhan: ssh+vi? vs code can be quite belligerent 23:14:45 I currently am doing that but vim breaks upon every reboot 23:36:36 vim problems? 23:37:43 if your system is crashing while just editing text, it is likely time to start inspecting hardware 23:39:29 so to be clear, its crashing due to my kernel driver that I'm working on. 23:40:59 No vim problems, I just dislike having to re-open my terminal and vim location every time. 23:41:12 Would be nice to just hit "reconnect" and its in the same location. 23:41:47 your options are either using something like vscode and installing the vscode remote under a linuxulator since ms doesn't ship one for freebsd, or using an editor on your local machine and then rsyncing/sshfs/whatever 23:42:04 otherwise you'll just have to deal with the fact that the box running your editor is in fact crashing 23:46:32 I use the anvil editor and it has ssh interface built in so it just connect when you load or save something, works for me. 23:54:02 farhan: I have a FreeBSD vm setting idle right now that you could make use of. If that would actually help any 23:54:20 Idle setting? I do not follow? 23:55:43 sitting idle, not doing anything 23:56:03 "sitting" yeah -- sorry 23:56:08 Meaning, I do not understand how that would be of assistance. 23:56:19 It may not 23:56:32 I just thought it might :P