I certainly agree with your statement. But let's be realistic: a new 240GB SSD costs around 25 US dollars. A 480GB one, around $40. Anyone who could afford a computer in the first place can afford this, and even though these aren't large disks by today's standards, it's more than enough to not have to care about a few gigabytes more or less.
OPTIONS_UNSET+=PLATFORM_WAYLAND
OPTIONS_UNSET+=WAYLAND
OPTIONS_UNSET+=QTWEBKIT
OPTIONS_UNSET+=HARFBUZZ
OPTIONS_UNSET+=AVAHI
OPTIONS_UNSET+=BDB
OPTIONS_UNSET+=DBUS
OPTIONS_UNSET+=DC1394
OPTIONS_UNSET+=DEBUG
OPTIONS_UNSET+=DTRACE
OPTIONS_UNSET+=ESPEAK
OPTIONS_UNSET+=FLANG
OPTIONS_UNSET+=GCRYPT
OPTIONS_UNSET+=GLSLANG
OPTIONS_UNSET+=GOLD
OPTIONS_UNSET+=GSSAPI_BASE
OPTIONS_UNSET+=GSSAPI_HEIMDAL
OPTIONS_UNSET+=GSSAPI_MIT
OPTIONS_UNSET+=GVFS
OPTIONS_UNSET+=GVFS_METADATA
OPTIONS_UNSET+=HEIF
OPTIONS_UNSET+=IMAGEMAGICK6
OPTIONS_UNSET+=JACK
OPTIONS_UNSET+=LCMS2
OPTIONS_UNSET+=LDAP
OPTIONS_UNSET+=LDAPS
OPTIONS_UNSET+=LENSFUN
OPTIONS_UNSET+=LETTER
OPTIONS_UNSET+=LIGHTDM
OPTIONS_UNSET+=LIRC
OPTIONS_UNSET+=LTO
OPTIONS_UNSET+=LTO_BOOTSTRAP
OPTIONS_UNSET+=LUAJIT
OPTIONS_UNSET+=MBEDTLS
OPTIONS_UNSET+=MDNSRESPONDER
OPTIONS_UNSET+=MFX
OPTIONS_UNSET+=MUJS
OPTIONS_UNSET+=MULTILIB
OPTIONS_UNSET+=NAS
OPTIONS_UNSET+=NFS
OPTIONS_UNSET+=NLS
OPTIONS_UNSET+=NTLM
OPTIONS_UNSET+=OGGSPOTS
OPTIONS_UNSET+=OPENMP
OPTIONS_UNSET+=OPENMPT
OPTIONS_UNSET+=PIPEWIRE
OPTIONS_UNSET+=POCKETSPHINX
OPTIONS_UNSET+=PULSE
OPTIONS_UNSET+=PULSEAUDIO
OPTIONS_UNSET+=RUBBERBAND
OPTIONS_UNSET+=RUNROOT
OPTIONS_UNSET+=SAGE
OPTIONS_UNSET+=SMB
OPTIONS_UNSET+=SOUNDTOUCH
OPTIONS_UNSET+=SPEECH
OPTIONS_UNSET+=SPEECH_RECOGNITION
OPTIONS_UNSET+=SPEECHD
OPTIONS_UNSET+=SUDO
OPTIONS_UNSET+=SVTHEVC
OPTIONS_UNSET+=SVTVP9
OPTIONS_UNSET+=TEXT2SPEECH
OPTIONS_UNSET+=VAAPI
OPTIONS_UNSET+=VAPOURSYNTH
OPTIONS_UNSET+=VDPAU
OPTIONS_UNSET+=VULKAN
OPTIONS_UNSET+=YTDL
OPTIONS_UNSET+=ZBAR
OPTIONS_UNSET+=ZEITGEISTcd /usr/local
du | sort -n
cd /usr
du -s */.Which is a good start for a long term relationship
and I am happy for you taking this route.Yes, so do I. Thank you for the nudge.
Are you in America? I could never buy those in my country for that price. The Raspberry Pi isn't cheap here either. It costs almost as much as my rent, and paying rent has been even more difficult than usual since 2020. Either way, it's not good enough for my needs.
I bought this computer in 2015. My life was very different then. It wasn't easy, but it wasn't the cliffhanger struggle it is today. I actually starved a little just a few months ago, eating nothing but rice and ramen for four months. I may very well go back to that situation in two months if I can't find new work by then. You sound like you don't realize how lucky you are. Speculating about the financial situation or purchasing power of someone you don't even know by name is quite the fool's errand.
The opposite. I never had compression on XFS or BTRFS. I have it on ZFS, in the /usr/ports dataset only.
The only difference that matters is that one works and the other not so well. I thought the new relationship could be better, but it looks like no, it's not going to be as good as I had hoped. I am not ready to take this step right now. It's not you. It's me.
default and 230218-154642. Boot Environments are a ZFS feature, a clone is created (see zfsconcepts(7) for a description) and marked as bootable, you have effectively branched your file system (I've been doing some Git rebasing this morning so my head is in Git mode) and now can boot off of the HEAD of either branch...If that analogy makes sense?default has two flags NR, N means it's active Now, R means it'll be active on the next Reboot (meanings are documented in bectl(8) under the list subcommand). The Boot Environment called 230218-154642 is taking up 768M of your disk space, but you're likely not using it. Unless you want to go back to to life on 2023-02-18, you can reclaim this space by deleting the Boot Environment using bectl destroy 230218-154642 /usr/local) - for a comparison my server, installed and upgraded since 2016, only uses 4.62G for the root dataset. df or du and they don't report what you expect because they aren't aware of things like snapshots.pkg upgrade
pkg autoremove
pkg clean -aThis is a technical forum, with users from all over the planet Earth. Topic of the conversation is to point out what works, and what kind of specs make sense for a given scenario. Forum users can also point out code and design hacks to make FreeBSD work on your specs, but it's also not out of question to point out that the specs are inadequate for a given scenario. The Forums are also a good place to start learning about technical reasons why some specs are a poor match for some scenarios.
Beautiful, just beautiful!OK, let's try and see what some of this means
You have two Boot Environments,defaultand230218-154642. Boot Environments are a ZFS feature, a clone is created (see zfsconcepts(7) for a description) and marked as bootable, you have effectively branched your file system (I've been doing some Git rebasing this morning so my head is in Git mode) and now can boot off of the HEAD of either branch...If that analogy makes sense?
The whole disk isn't part of the Boot Environment, typically only directories in the dataset mounted on /, any directories in other datasets are not part of this, and so effectively live on both branches.
It's worth noting now that /usr and /var are, by default, a dataset that is not mounted, so because /usr/local is just a directory and not a dataset the contents live in the root dataset.
For you we can see that the Boot Environment calleddefaulthas two flagsNR, N means it's active Now, R means it'll be active on the next Reboot (meanings are documented in bectl(8) under the list subcommand). The Boot Environment called230218-154642is taking up 768M of your disk space, but you're likely not using it. Unless you want to go back to to life on 2023-02-18, you can reclaim this space by deleting the Boot Environment usingbectl destroy 230218-154642
We can see from your zpool(8) output that your disk is around 14.5G, 9.26G has been allocated, and there is 5.24G free.
- AVAIL means space available to that dataset - since all of your datasets are part of the same pool, they all have the same amount of space available to them
- USEDSNAP is space allocated to storing snapshots of this dataset - these snapshots are only the differences between it and it's parent
- USEDDS is how much space the dataset is using (not including snapshots)
- USEDREFRESERV is any space reserved for this dataset (not used by yourself)
- USEDCHILD is how much space is being used by child datasets (i.e. datasets under this one)
- USED is the total of (USEDSNAP + USEDDS + USEDREFRESERV + USEDCHILD)
So what is using all the space?
Looking back at the thread, it looks like the main culprit was distfiles and working files in your Ports tree, rather than ZFS "magic". Most Linux distros I've used recently use binary packages, so you don't have such things hanging around, on my Arch desktop there are some packages built from source but all of the relevant files are stored under my home directory.
- 768M is taken by the Boot Environment as we've already discussed
- 4.77G is taken by the root dataset - this will be the base FreeBSD installation PLUS the binaries + config of any Ports/Packages you've installed (i.e. everything under
/usr/local) - for a comparison my server, installed and upgraded since 2016, only uses 4.62G for the root dataset.- 52.2M in /tmp
- 900M is taken up by /usr/ports
- <1M is taken by the datasets under /var
- 2.79G is used by user home directories
It's worth noting that if you're not familiar with ZFS things can appear magic, because you rundforduand they don't report what you expect because they aren't aware of things like snapshots.
I've personally not found a good reason to build my own Ports unless there are options to be changed (and even in that case I've asked maintainers if they would be happy to enable it by default to binaries provided by FreeBSD had that option included, it's been agreed once or twice too). I use binary packages everywhere, and do regular maintenance with:
Bash:pkg upgrade pkg autoremove pkg clean -a
This upgrades all my packages, automatically removes anything that was a dependency that is no longer required, and then delete all cached packages (including latest versions that are still in use). I've never personally needed to rollback a package and have always had an internet connection to reinstall a package if I've accidental removed it, so the cache is not so useful to me.
The only other place that I see regular growth is under /var/db/freebsd-update/files, and there's a thread here talking about what it is and how to clear it.
I've generally found FreeBSD to be fairly lean with disk space, there's been a couple of gotchas with caches filling up (had the same with Linux over the years too), and also when I was getting used to ZFS snapshots (that's down to tuning for my use cases).
Hopefully with a bit more visibility about the system it becomes easier to compare with your other experiences.
I will share some thoughts on what you said. I just like the topic and I feel chatty. I fear annoying some people with my opinions, maybe because they are off-topic or even because they are deemed unwelcome. I don't mean any harm. If my posts are inappropriate in any way, just let me know and I will refrain in the future. I am a good netizen.
[vm-user1@fbsd-vm1 ~]$ duf /
╭────────────────────────────────────────────────────────────────────────────────────────╮
│ 1 local device │
├────────────┬───────┬──────┬───────┬───────────────────────────────┬──────┬─────────────┤
│ MOUNTED ON │ SIZE │ USED │ AVAIL │ USE% │ TYPE │ FILESYSTEM │
├────────────┼───────┼──────┼───────┼───────────────────────────────┼──────┼─────────────┤
│ / │ 36.8G │ 6.9G │ 27.0G │ [###.................] 18.6% │ ufs │ /dev/ada0p2 │
╰────────────┴───────┴──────┴───────┴───────────────────────────────┴──────┴─────────────╯
[vm-user1@fbsd-vm1 ~]$ gpart show
=> 40 83886000 ada0 GPT (40G)
40 1024 1 freebsd-boot (512K)
1064 79690752 2 freebsd-ufs (38G)
79691816 4194224 3 freebsd-swap (2.0G)
[vm-user1@fbsd-vm1 ~]$ pkg prime-list
atril-lite
bash
classiclooks
duf
emacs
firefox
fvwm
iftop
keepassxc
mc
mutt
nmap
numlockx
pkg
qt5-l10n
qt5ct
screen
slim
slim-themes
sudo
terminus-font
thunderbird
virtualbox-ose-additions
webfonts
xfce
xfe
xorg
youtube_dl[vm-user1@fbsd-vm1 ~]$ duf /
╭────────────────────────────────────────────────────────────────────────────────────────╮
│ 1 local device │
├────────────┬───────┬──────┬───────┬───────────────────────────────┬──────┬─────────────┤
│ MOUNTED ON │ SIZE │ USED │ AVAIL │ USE% │ TYPE │ FILESYSTEM │
├────────────┼───────┼──────┼───────┼───────────────────────────────┼──────┼─────────────┤
│ / │ 36.8G │ 6.7G │ 27.1G │ [###.................] 18.3% │ ufs │ /dev/ada0p2 │
╰────────────┴───────┴──────┴───────┴───────────────────────────────┴──────┴─────────────╯
JFTR, poudriere has a similar feature (fetching binary packages where applicable), but it still isn't in the "stable" version yet, so you have to install ports-mgmt/poudriere-devel to use it. In my experience, the -devel version works without issues
I’ve used both (including the -devel poudriere). I’d say poudriere is a little more robust, but synth is much easier to set up.
I believe you, as I said, nothing against the tool (I certainly can't judge things I don't even know).
.Could you elaborate on how did you checked that piece of information so us newbies can learn from it?synth already almost got removed because of some issue with this not-very-well-maintained Ada compiler it needs. Someone managed to avoid it just in time
github.com
If I were interested, I'd probably start by looking at git logs for synth and Ada...
