00:04:33 Uh how true is this statement? - "Modern ZFS is smart. When you give it a 512e drive, ZFS queries the drive, sees that the physical sector size is 4K, and automatically defaults to ashift=12. Therefore, ZFS treats 512e drives exactly like 4Kn drives anyway." 02:54:48 how granular should pf rule and translation configs be? 02:55:00 granular includes 03:12:36 uyhhh how granular do you think they need to be 03:13:01 frankly, doesn't matter if its PF or any other firewall, the default should be deny/block/drop 03:13:23 the only granularity is on what you deem should be passed through 05:08:10 dkeav no for example if i make port forwards for ssh into jails through the jail host ip since the jails don't have a public ip, do i give each set of forward rules for a jail its own file, or put them all in 1 jail forwards file? 05:08:32 doesn't seem like there's a binary correct answer, but wanna know best practice 11:15:45 spork_css: I've used both znc and soju, currently using soju 12:12:57 hm. not really sure if this is smb/zfs/freebsd related but using samba as a backup datastore for proxmox gives me this weirdness: 12:13:02 INFO: zstd: error 70 : Write error : cannot write block : Bad address 12:33:36 hm, it seems to me that pkg 2.8.0 became significantly slower than versions before, on upgrade operations 12:34:44 a single `pkg install -y pkg vim xxd fish` will churn the cpu for ~15 seconds when executing as an update 12:35:40 reaching 1.2GB RES 12:37:31 I would love to be a fly on the wall in that pkg implementation's address space. 12:44:24 you'd probably see things previously unimaginable 13:06:55 sounds like a tab of lsd, im down for it 13:09:12 when this baby hits 88Gflops... you're gonna see some serious sh!t 13:16:46 polarian: Are you sure those are all defaults? According to geli(8) I see nothing about `-a HMAC/SHA512` being the default. Just HMAC/SHA256 being recommended. Also, seems like `-l` is dependent on `AES-XTS: 128, 256` and `AES-CBC, Camellia-CBC: 128, 192, 256` - None of which seem to document a default? 13:17:10 Something I found a bit underdocumented is `geli backup`: "Backup metadata from the given provider to the given file." - Cool but uh... where can I find those? :D 13:17:16 They don't appear at the $PWD, that I can tell you for sure. Adding a -v flag furthermore presented me with an ever descriptive "Done." - Wonderful! :P 13:17:44 Zooming out a bit though, I wonder what the added benefit of GELI-level data integrity verification is if I'm going to use it in a ZFS mirror with weekly scrubs anyway. 14:42:21 Hi 14:42:22 I want to ask a question, I noticed any drive (hd, cd, usb, etc) plugged into my pc.. automount corrupts it after three or four times 14:42:25 or just writing big thing on it (+1GB) 14:42:34 my pc is hp compaq pro 6305 sff 14:44:11 uname -a ? 14:44:28 and how did you install automount 14:49:43 FreeBSD 13.5-RELEASE FreeBSD 13.5-RELEASE releng/13.5-n259162-882b9f3f2218 GENERIC amd64 14:49:44 installed it 4 years ago when I was using 13.2 using pkg install automount 14:55:03 and upgraded it when I freebsd-update to 13.5 last year 14:56:57 but this problem is so old, since I begin to use freebsd.. maybe it's a bug? if anyone uses compaq 6305 or any similar one please tell me.. Ethernet had a problem with my pc, and It was just uncompatible with specific feature in my pc (went to bios and disabled it.. then worked!) 14:57:03 so maybe it's the same here? 15:02:05 If your disk is getting corrupted, that's not normal. 15:03:05 I would advise running memtest to check if your RAM is okay, just to rule it out. 15:03:41 I've had bad/failing RAM cause all sorts of weird corruption over the years. 15:04:41 yeah. Memtest86+ several times over. 15:04:45 Seems like `geli init -B ` is only painless if you specify a disk without its path. 15:45:08 memtest? I will see 15:46:22 first time to know this, maybe my ram is bad .. I didn't change it since I installed freebsd 4 years ago 18:23:22 ForeverNoob[m]: the geli backups should be in /var/backups. the geli integrity is intended to be for cryptograpic integrity, to defend against malicious alteration of the on-disk encrypted data. also, the default key length has always been 128 (at least for AES-XTS), not sure if that's still true, but probably. 18:25:38 so the added benefit would be that you would be authenticating the disk contents even against malicious alterations of data at the zfs level (but i think this is not worth it in most cases unless you have a reason). also, i don't know what happens to reads when geli detects an integrity issue, i think reading might just fail in that area, which might be a problem for zfs (not sure) 18:35:42 jmnbtslsQE: Thanks. So if I'm understanding correctly, if for some reason the GELI checksums don't match (after tampering for example), `geli attach` will warn about this and subsequently fail to decrypt drives? 18:41:18 i think it will report the errors in the console for geli blocks where the failures happen (and not until they happen), but i'm not sure what happens when you actually try to read data in those blocks - probably a failure, but i haven't tried. geli attach will only report this if it encounters these inconsistencies during its attach. if the errors are elsewhere, they will be encountered when you try 18:41:24 to read there 18:41:45 (read or write actually) 18:42:19 well, hmm, i'm not sure if it happens on a write 18:48:42 Hmm I see, so I guess it can happen during attach but most likely during runtime. 19:01:48 yeah i think so, because attaching only touches part of the disk. honestly, i think the only time it ever happened to me was when i thought a drive had geli auth but it didn't, so geli reported errors on everything and couldn't attach. but today, i also don't use geli auth for anything 19:03:45 if you feel adventurous, you could create a small, 128MB empty file with `truncate`, attach it as a memory disk (mdconfig -f), set up geli encryption/auth on the md device, then `dd` a small amount of random data somewhere on the disk and see what happens, either trying to attach or after it's attached. 19:08:02 bottom line though, i feel like it will be safer to not use geli auth with zfs. i would be concerned about how they might interact if zfs doesn't have a chance to look at the on disk data upon authentication error. i think it's unlikely to ever happen, but if it does, maybe the interaction will make the problem worse (right when you don't need that). maybe someone who knows more about it can advise 19:08:08 you on it or better yet, ask one of the mailing list 19:10:47 Interesting idea to test it out using (empty) files. I might try that later on in my VM. 19:12:00 Apparently the ashift value is also not hardcoded at pool creation time? https://man.freebsd.org/cgi/man.cgi?query=zpoolprops - "The following properties can be set at creation time and import time, and later changed with the zpool set command" 19:13:34 Seems like I've been reading old docs? Wasn't this always an unmodifiable property after pool creation? 19:15:24 oh, interesting, didn't know that. it looks like it "is" unmodifiable but it allows it to be set for new vdevs 19:15:50 hen set, this property is used as the default hint value in subsequent vdev operations (add, attach and replace). Changing this value will not modify any existing vdev, not even on disk replacement; however it can be used, for instance, to replace a dying 512B sectors disk with a newer 4KiB sectors device: this will probably result in bad performance but at the same time could prevent loss of data. 19:16:00 (from the man) 19:17:07 Huh. 19:17:11 i guess there are some restrictions sometimes regarding sector size when trying to add/remove disks on a pool, so maybe this helps to workaround those..can't really remember though. 19:17:35 s/disks/vdevs/ (maybe) 19:27:16 Toshiba N300 (4TB) apparently only support 512n while my WDs (16TB) support both 512e as well as 4Kn. The bigger one will be used for stuff like my music collection and movies, while the smaller ones will be used for more "serious" stuff. 19:27:31 If I should believe some of the FreeBSD forum posts, then if the stack is set to 4Kn (on physical disk, GELI sector size and ZFS pool ashift), it would result in significant performance benefit compared to 512. Since resilvering a 16TB drive can take a bit longer than a 4TB one, I'm thinking ashift=9 for the smaller pool and ashift=12 for the larger one. 20:04:49 https://man.freebsd.org/cgi/man.cgi?query=zpool-features - "The native 64-bit arithmetic of SHA-512 provides an approximate 50% per- formance boost over SHA-256 on 64-bit hardware..." 20:05:16 First time ever reading that sha512sum is faster than sha256sum. 20:07:50 ya me too 20:28:10 Ugh, apparently zpool create can't target devices in /dev/label/ ? 21:12:22 yeah it can 21:22:08 llua: Then what on earth am I doing wrong? 21:22:10 $ zpool create mirpool mirror /dev/label/zfs_ddisk_*.eli 21:22:15 cannot use '/dev/label/zfs_ddisk_1.eli': must be a block device or regular file 21:41:39 ForeverNoob[m]: https://paste.rs/KmWUd 21:41:48 ForeverNoob[m]: chek which is the device related to that label and use the device instead 21:42:20 use gpart show -l to see labels and devices 21:44:52 So i have this laptop with 1 disk using geli. Looks like 2 partitions are mounted using geli. 21:44:55 nda1% nda1p1% nda1p2% nda1p3% nda1p3.eli% nda1p4% nda1p4.eli% 21:44:58 To define a new geli passphrase, the passphrase must be set for both partitions in this case? nda1p3 and nda1p4 ? 21:59:13 hernan604: I mean... if I'd wanted to use raw devices I'd just do that, but that obviously comes with its downsides. 21:59:44 If you enter 1 passphrase for that disk, then I'd assume you also have to only set 1 passphrase. But as always, backup backup backup etc. 21:59:52 llua: https://paste.debian.net/plainh/de4ad9b9 22:02:55 Funnily enough: https://paste.debian.net/plainh/326f16fa 22:03:21 > must be a full path or shorthand device name 22:03:23 lolnope 22:20:33 Thing is, I could have sworn this just worked not even a few years ago. 22:21:03 (Even have it documented to do it in such a way) 22:59:31 the second example definitely didn't work before 23:01:01 i showed the shorthand device name, geoms in freebsd. 23:02:13 disks in freebsd are character files, you can see that via ls's -l option, which isn't new. 23:51:07 ForeverNoob[m]: geli init -l 256 -s 4096 /dev/gpt/${HDD_1_LABEL} /dev/gpt/${HDD_2_LABEL} 23:51:36 geli configure -b /dev/gpt/${HDD_1_LABEL} 23:51:36 geli configure -b /dev/gpt/${HDD_2_LABEL} 23:51:40 geli attach /dev/gpt/${HDD_1_LABEL} /dev/gpt/${HDD_2_LABEL} 23:51:46 zpool create $ZPOOL_NAME mirror /dev/gpt/${HDD_1_LABEL}.eli /dev/gpt/${HDD_2_LABEL}.eli 23:51:55 zfs set mountpoint=/mnt/$ZPOOL_NAME $ZPOOL_NAME 23:52:01 zfs list 23:55:10 hernan604: GPT labels need at least 1 GPT partition present on the drive. I am intending to used entire drive instead. The glabel labels don't have this requirement. 23:57:07 btw you can set mountpoint during creation time. 23:57:38 llua: Apparently zpool needed elevated privileges. Whatever the case, "cannot use '/dev/label/bar0': must be a block device or regular file" as an error message for such a situation is dumb as hell.