#zfs guy had good point why should always partition drives for zfs: "it reduces the chance you accidentally partition or overwrite them later because you didn't realize there was something on the drive"

makes sense to me

There's a bit of padding too which in edge cases when using a differently sectored disk can be short sectors even by 1 sector that the partitioned setup may not have ran into

however I feel the urge to use the whole disk given that I know the setup of hardware and use the same model disks and also I'm the only user

i usually manually partition disks for zfs but i'm not sure "you might not realise there's anything on the drive" is a good argument - zfs itself will create a gpt label on the disk so there's going to be something there

so that argument is referring to extraneous partitioners as well - gpt is a partitioned based setup even if it's one partition on disk

right, that's what i mean: there's always going to be a partition there regardless of whether you partition it manually, it's not like the old BSD labels where other OSs' partitioning tools would see an empty disk

like if you bring the disk up in say windoes disk manager - before gpt it may not have known based on what mechanism you use like a last sector schema or nothing at all

ivy: it does now? I remember that not being the case (on FreeBSD)

one of the main reason for using partitions for ZFS is that you can trim the space a bit, and thus, inserting replacement HDD from another vendor, after partitioning you should be fine (the size of devise used for replacement will be the same)

of course, one can always use larger device as replecement

cyric: i don't remember it ever not doing this, although i didn't use it on freebsd in the early days

(it has definitely always done this on Solaris)

another thing is booting, if you want to boot from that zpool, you need ZFS to seat on partitions, not raw devices

and probably last one is geom(8) and its enhancements, IIRC not available without partitioning

but zpools created on unparttioned drives are fine, I have had a couple of them for backups and they are 100% fine

oh.. I was using screen in bright sunlight, I am sorry for such many typos

they work ok until you need to replace a failed one and the replacement is 10KB smaller in size :D

yes, this is the main drawback

don't do that in either case

it's not forbidden the_oz

geom concat with usb stick?

"they'll never know"J

FreeBSD is still flexible OS, that's one of its strengths

geom concat with usb stick is not best approach, indeed ;-)

is there any downside to manually gpt partition with 1 part before putting zfs on it? there's negligible upside i see, but any downside?

if you go the sysinstall route and you boot off any afs disk it will partition every disk as if you boot off them -- Furthermore some sizing of the partitions is bigger than necessary as well -- but as for downsides of doing it manually is errors at each stage on boot because you got it wrong

zfs*

demido: Strong upside - you can refer to your partitions via their GPT labels.

mason instead of the /dev/id right?

yeah

ok i'll do that. and gpart create -s GPT <devid>, gpart add -l mylabel -t freebsd-zfs -a 1M <devid> = the right way to do it to be sure?

gpart create -s gpt ada0

gpart add -t freebsd-boot -s 512k -l boot0 ada0

etc

I tend to refer to my cheatsheet: wiki.freebsd.org/MasonLoringBliss/ZFSandGELIbyHAND

why -s 512k? jc. and why no -a 1M?

demido because the content of freebsd-boot is stage2 bootloader code stored directly in disk blocks and previous stage does read *the entire* freebsd-boot partition into low memory (before video ram) of BIOS system. So it has to be large enough to be able to store the stage and small enough not to blow up the system during the read.

ah

so that's important for bootable disk then i guess

how about the -a 1M part?

what's the proper way to downgrade a package, `pkg install /var/cache/pkg/packagename.pkg` or is there a better way of managing package versions?

veg: you can try: pkg delete -f "pkgname_to_downgrade" && pkg add /var/cache/pkg/packagename.pkg

mason mind if i ask why you don't do -a 1M?

veg: but it's not official guidance, so other people could give you pretty different advice

-a 1M for which partition?

the first and only? eg i setup using "it reduces the chance you accidentally partition or overwrite them later because you didn't realize there was something on the drive"

demido because tank0 and tank1 in that example are created with -a 1m..

ahh. i didn't catch that it was building up multiple parts on each drive, and why/how, because i haven't manually set up disks for zfs booting before. got it now tyvm

thanks mzar

actually the freebsd-zfs partitions are only ones for which the alignment is good for; you want it aligned to make sure the 4k blocks get max performance (geli is operating by 4k blocks and even if you do not use geli, but disk directly, you still want to make sure your 4k blocks are happy.

there is one thing, however; not only the partition start should be aligned, but end as well.

you do not want to have partition to end from the middle of 4k block.

how do you align part ends?

by aligning the size:)

so i'd pick some kinda base 2 SI value for that, like 1024G and use that with -s and -a 1M?

in principle yes. depending a bit on the disk size - you probably do not want to lose too much space there;)

ya true. what's a rule of thumb for how to pick a proper size? like if it would fall halfway between 1024G and 1025G, would you switch to M so you could fit max number of whole megabytes?

well, the rule of thumb there is simple -- if you do lay pool on bare disk, you do not really care, because zfs does align the end for you. For cases where you must use the full size blocks, then you need to verify the layout and adjust the end result accordingly.

full size blocks are usually required with encryption, either geli or disk based encryption.

i'll use single part not bare

how about rule of thumb is just ##rust of whole MB for size?

wtf

number of*

for zfs vdev size, the only value what matters is minimum size (64MB) - you can not use disk with less than 64MB. max size is your choice.

but you said i should align end too

in case of geli, sure. you want parition size % 4096 == 0.

that is, you want N full 4k blocks.

but you said even if no geli, for max speed

ahh "if you do not use geli, but disk directly"

the end alignment is not for speed really, the beginning is.

well, what happens is, when you add disk to pool, zfs will store 2 copies of pool labels in front of the pool and 2 copies after the end, so your partition is laid down as | label0, label1 | data | label2, label3 | -- to be able to find the label 2 and 3, the data size is aligned (internally). If your partition is larger, then you get wasted space after label3. Which probably is not a big deal from pool point of view.

any downside to always setting a -s % 4096 == 0 for zfs part?

if its last partition on disk, you may end up having amount of unpartitioned space at the end.

so a lil waste is all

yep.

i kinda like the idea of always setting a size. any reason other than losing a MB or two, and an extra calculation to figure out what the value should be, i shouldn't?

FreeBSD-kmods repository update completed. 53 packages processed.

14.3 will have it

what does it do?

is it like pkg repo but specifically for kmods?

yes, it will show up after upgrade to 14.3, so there will be reduced impact of the upgrade to 14.3 for desktop users

it also covers main and 14-stable: lists.freebsd.org/archives/freebsd-stable/2025-May/002830.html

although __FreeBSD_version changes so often in main that it's probably not very useful

yes, the above message is from freshly upgraded STABLE

why separate kmods into separate repo from regular pkgs?

main repo will switch builders to 14.3 one month later

demido: because normally packages are only built for the oldest support version of a major release. so when 14.3 is released, it wouldn't have any kmods packages because they're built for 14.2 until 14.2 goes EOF

s/EOF/EOL

oh

cool

im really excited about things like the firmware loader, pkgbase, now kmod repo

good modernization. hope kernel db lands soon too

kernel db?

now we should only keep fingers crossed for pkg(8), that it will be smart enough to pick kmod packages from kmod repos

mzar you know the kernel db thing right? maybe you can explain better, but it's like structured access to kernel/system state

demido: I haven't heard of kernel db, I am sorry

there was a talk on it at a bsdcon in the past year not sure which

perhaps you are asking about kexec ?

maybe?

no

anyway, adding kmods repo makes FreeBSD more desktop friendly, that's appreciated, thanks !

it almost didn't make it into 14.3, but when colin asked, everyone was in favour (obviously)

better later than never

freebsd on non-server is very important, as important as freebsd on server. sounds crazy? well we all have seen how much it hurts the OS to not have devs running it ALL DAY EVERY DAY like linux has

ppl woke up to that reality now and it's great news for fbsd future

that's not a bad argument but... if you look through commit logs, most significant work is sponsored by large corporations (netflix, klara, amazon, google, intel...) who probably aren't running freebsd on desktop either way

i would love to have more individual contributors, though

hmm, for a system with 128GB RAM and 960GB disk space, how large of a swap/dump partition would you create? i'm thinking 16GB is probably enough...

i like 0 swap tbh

since most of the memory will hopefully be used by arc and/or userland processes, which aren't dumped

demido: i need a dump partition since this will be running 15.0

ah

speaking of 14.3 and kmod. Did it get the drm-66-kmod?

so i'm on a thinkpad t480 and 13.4, keeps getting really hot with little fan speed. i'm looking at the acpi and i'm hitting 3500rpm, but changing the fan value from 0-8 where 8 should lock it at max speed nothing happens. is there a bios lockout preventing this from working?

Could be. Could also be that your computer is in need of a cleaning.

sure, but even if it needs cleaning i should be able to set fan to 8 and it max out the rpm

i didn't say i am overheating. i feel like it's hot, and the fan could be running stronger

it ought to be able to hit 5000rpm, not just 3500

bearing going?

i see it vary between 2800 and 3500

i think the bios is controlling it and ignoring the acpi setting

ivy: I have 128GB of ECC ram and ~130GB of swap space :)

Not sure if that's remotely helpful any more

Demosthenex: Make sure bios/efi isn't doing something dumb, but also a T480 would've been manufactured in... 2018? Has it been cleaned ?

(I had a PentiumII-233 Dell that was only a year or two old back when I was given it -- had to use our full-size vacuum to remove all the accumulated dust so it would boot.)