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."

how granular should pf rule and translation configs be?

granular includes

uyhhh how granular do you think they need to be

frankly, doesn't matter if its PF or any other firewall, the default should be deny/block/drop

the only granularity is on what you deem should be passed through

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?

doesn't seem like there's a binary correct answer, but wanna know best practice

spork_css: I've used both znc and soju, currently using soju

hm. not really sure if this is smb/zfs/freebsd related but using samba as a backup datastore for proxmox gives me this weirdness:

INFO: zstd: error 70 : Write error : cannot write block : Bad address

hm, it seems to me that pkg 2.8.0 became significantly slower than versions before, on upgrade operations

a single `pkg install -y pkg vim xxd fish` will churn the cpu for ~15 seconds when executing as an update

reaching 1.2GB RES

I would love to be a fly on the wall in that pkg implementation's address space.

you'd probably see things previously unimaginable

sounds like a tab of lsd, im down for it

when this baby hits 88Gflops... you're gonna see some serious sh!t

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?

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

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

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.

Hi

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

or just writing big thing on it (+1GB)

my pc is hp compaq pro 6305 sff

uname -a ?

and how did you install automount

FreeBSD 13.5-RELEASE FreeBSD 13.5-RELEASE releng/13.5-n259162-882b9f3f2218 GENERIC amd64

installed it 4 years ago when I was using 13.2 using pkg install automount

and upgraded it when I freebsd-update to 13.5 last year

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!)

so maybe it's the same here?

If your disk is getting corrupted, that's not normal.

I would advise running memtest to check if your RAM is okay, just to rule it out.

I've had bad/failing RAM cause all sorts of weird corruption over the years.

yeah. Memtest86+ several times over.

Seems like `geli init -B <file>` is only painless if you specify a disk without its path.

memtest? I will see

first time to know this, maybe my ram is bad .. I didn't change it since I installed freebsd 4 years ago

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.

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)

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?

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

to read there

(read or write actually)

well, hmm, i'm not sure if it happens on a write

Hmm I see, so I guess it can happen during attach but most likely during runtime.

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

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.

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

you on it or better yet, ask one of the mailing list

Interesting idea to test it out using (empty) files. I might try that later on in my VM.

Apparently the ashift value is also not hardcoded at pool creation time? 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"

Seems like I've been reading old docs? Wasn't this always an unmodifiable property after pool creation?

oh, interesting, didn't know that. it looks like it "is" unmodifiable but it allows it to be set for new vdevs

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.

(from the man)

Huh.

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.

s/disks/vdevs/ (maybe)

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.

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.

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..."

First time ever reading that sha512sum is faster than sha256sum.

ya me too

Ugh, apparently zpool create can't target devices in /dev/label/ ?

yeah it can

llua: Then what on earth am I doing wrong?

$ zpool create mirpool mirror /dev/label/zfs_ddisk_*.eli

cannot use '/dev/label/zfs_ddisk_1.eli': must be a block device or regular file

ForeverNoob[m]: paste.rs/KmWUd

ForeverNoob[m]: chek which is the device related to that label and use the device instead

use gpart show -l to see labels and devices

So i have this laptop with 1 disk using geli. Looks like 2 partitions are mounted using geli.

nda1% nda1p1% nda1p2% nda1p3% nda1p3.eli% nda1p4% nda1p4.eli%

To define a new geli passphrase, the passphrase must be set for both partitions in this case? nda1p3 and nda1p4 ?

hernan604: I mean... if I'd wanted to use raw devices I'd just do that, but that obviously comes with its downsides.

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.

llua: paste.debian.net/plainh/de4ad9b9

Funnily enough: paste.debian.net/plainh/326f16fa

> must be a full path or shorthand device name

lolnope

Thing is, I could have sworn this just worked not even a few years ago.

(Even have it documented to do it in such a way)

the second example definitely didn't work before

i showed the shorthand device name, geoms in freebsd.

disks in freebsd are character files, you can see that via ls's -l option, which isn't new.

ForeverNoob[m]: geli init -l 256 -s 4096 /dev/gpt/${HDD_1_LABEL} /dev/gpt/${HDD_2_LABEL}

geli configure -b /dev/gpt/${HDD_1_LABEL}

geli configure -b /dev/gpt/${HDD_2_LABEL}

geli attach /dev/gpt/${HDD_1_LABEL} /dev/gpt/${HDD_2_LABEL}

zpool create $ZPOOL_NAME mirror /dev/gpt/${HDD_1_LABEL}.eli /dev/gpt/${HDD_2_LABEL}.eli

zfs set mountpoint=/mnt/$ZPOOL_NAME $ZPOOL_NAME

zfs list

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.

btw you can set mountpoint during creation time.

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.