04:35:57 #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" 04:36:12 makes sense to me 05:25:21 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 05:26:55 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 05:26:59 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 05:28:24 so that argument is referring to extraneous partitioners as well - gpt is a partitioned based setup even if it's one partition on disk 05:29:51 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 05:29:53 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 06:08:40 ivy: it does now? I remember that not being the case (on FreeBSD) 06:15:44 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) 06:16:01 of course, one can always use larger device as replecement 06:16:50 cyric: i don't remember it ever not doing this, although i didn't use it on freebsd in the early days 06:17:01 (it has definitely always done this on Solaris) 06:18:21 another thing is booting, if you want to boot from that zpool, you need ZFS to seat on partitions, not raw devices 06:19:16 and probably last one is geom(8) and its enhancements, IIRC not available without partitioning 06:23:07 but zpools created on unparttioned drives are fine, I have had a couple of them for backups and they are 100% fine 06:31:59 oh.. I was using screen in bright sunlight, I am sorry for such many typos 06:37:26 they work ok until you need to replace a failed one and the replacement is 10KB smaller in size :D 06:41:57 yes, this is the main drawback 06:42:22 don't do that in either case 06:42:39 it's not forbidden the_oz 06:43:53 geom concat with usb stick? 06:44:09 "they'll never know"J 06:44:13 FreeBSD is still flexible OS, that's one of its strengths 06:44:40 geom concat with usb stick is not best approach, indeed ;-) 07:11:56 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? 07:15:10 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 07:15:27 zfs* 07:15:57 demido: Strong upside - you can refer to your partitions via their GPT labels. 07:16:23 mason instead of the /dev/id right? 07:16:45 yeah 07:18:39 ok i'll do that. and gpart create -s GPT , gpart add -l mylabel -t freebsd-zfs -a 1M = the right way to do it to be sure? 07:22:39 gpart create -s gpt ada0 07:22:52 gpart add -t freebsd-boot -s 512k -l boot0 ada0 07:23:04 etc 07:23:23 I tend to refer to my cheatsheet: https://wiki.freebsd.org/MasonLoringBliss/ZFSandGELIbyHAND 07:24:26 why -s 512k? jc. and why no -a 1M? 07:28:29 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. 07:38:19 ah 07:38:31 so that's important for bootable disk then i guess 07:38:36 how about the -a 1M part? 08:09:03 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? 08:13:11 veg: you can try: pkg delete -f "pkgname_to_downgrade" && pkg add /var/cache/pkg/packagename.pkg 08:14:11 mason mind if i ask why you don't do -a 1M? 08:14:27 veg: but it's not official guidance, so other people could give you pretty different advice 08:19:54 -a 1M for which partition? 08:21:20 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" 08:22:26 demido because tank0 and tank1 in that example are created with -a 1m.. 08:24:44 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 08:25:01 thanks mzar 08:27:18 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. 08:28:12 there is one thing, however; not only the partition start should be aligned, but end as well. 08:28:39 you do not want to have partition to end from the middle of 4k block. 08:32:40 how do you align part ends? 08:34:20 by aligning the size:) 08:35:26 so i'd pick some kinda base 2 SI value for that, like 1024G and use that with -s and -a 1M? 08:37:21 in principle yes. depending a bit on the disk size - you probably do not want to lose too much space there;) 08:39:47 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? 08:48:35 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. 08:49:25 full size blocks are usually required with encryption, either geli or disk based encryption. 08:49:29 i'll use single part not bare 08:50:07 how about rule of thumb is just ##rust of whole MB for size? 08:50:13 wtf 08:50:26 number of* 08:51:59 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. 08:52:27 but you said i should align end too 08:53:02 in case of geli, sure. you want parition size % 4096 == 0. 08:53:27 that is, you want N full 4k blocks. 08:53:34 but you said even if no geli, for max speed 08:54:13 ahh "if you do not use geli, but disk directly" 08:54:36 the end alignment is not for speed really, the beginning is. 08:59:12 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. 09:00:57 any downside to always setting a -s % 4096 == 0 for zfs part? 09:02:04 if its last partition on disk, you may end up having amount of unpartitioned space at the end. 09:03:11 so a lil waste is all 09:03:36 yep. 09:12:16 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? 09:38:37 FreeBSD-kmods repository update completed. 53 packages processed. 09:38:47 14.3 will have it 09:44:23 what does it do? 09:44:36 is it like pkg repo but specifically for kmods? 09:46:13 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 09:46:47 it also covers main and 14-stable: https://lists.freebsd.org/archives/freebsd-stable/2025-May/002830.html 09:47:02 although __FreeBSD_version changes so often in main that it's probably not very useful 09:47:13 yes, the above message is from freshly upgraded STABLE 09:47:47 why separate kmods into separate repo from regular pkgs? 09:48:13 main repo will switch builders to 14.3 one month later 09:48:21 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 09:48:31 s/EOF/EOL 09:49:05 oh 09:49:07 cool 09:49:33 im really excited about things like the firmware loader, pkgbase, now kmod repo 09:49:48 good modernization. hope kernel db lands soon too 09:49:57 kernel db? 09:49:59 now we should only keep fingers crossed for pkg(8), that it will be smart enough to pick kmod packages from kmod repos 09:50:35 mzar you know the kernel db thing right? maybe you can explain better, but it's like structured access to kernel/system state 09:51:13 demido: I haven't heard of kernel db, I am sorry 09:51:53 there was a talk on it at a bsdcon in the past year not sure which 09:52:25 perhaps you are asking about kexec ? 09:54:23 maybe? 09:55:25 no 09:56:56 anyway, adding kmods repo makes FreeBSD more desktop friendly, that's appreciated, thanks ! 09:57:41 it almost didn't make it into 14.3, but when colin asked, everyone was in favour (obviously) 09:58:58 better later than never 10:04:10 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 10:04:26 ppl woke up to that reality now and it's great news for fbsd future 10:10:57 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 10:11:23 i would love to have more individual contributors, though 10:27:40 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... 10:28:03 i like 0 swap tbh 10:28:06 since most of the memory will hopefully be used by arc and/or userland processes, which aren't dumped 10:28:13 demido: i need a dump partition since this will be running 15.0 10:28:19 ah 10:35:02 speaking of 14.3 and kmod. Did it get the drm-66-kmod? 14:51:49 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? 14:54:19 Could be. Could also be that your computer is in need of a cleaning. 14:57:39 sure, but even if it needs cleaning i should be able to set fan to 8 and it max out the rpm 14:57:54 i didn't say i am overheating. i feel like it's hot, and the fan could be running stronger 14:58:16 it ought to be able to hit 5000rpm, not just 3500 15:02:39 bearing going? 15:04:31 i see it vary between 2800 and 3500 15:04:39 i think the bios is controlling it and ignoring the acpi setting 22:49:59 ivy: I have 128GB of ECC ram and ~130GB of swap space :) 22:50:47 Not sure if that's remotely helpful any more 22:52:31 Demosthenex: Make sure bios/efi isn't doing something dumb, but also a T480 would've been manufactured in... 2018? Has it been cleaned ? 22:56:06 (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.)