long time no see ... what's the status of PKGBASE?

every time I have to upgrade dozen of freebsd jails with freebsd-update I'm wondering this :)

freebsd-update is painfully slow

mage: pkgbase is progressing, IIRC GhostBSD fully switched to pkgbase

mage: i've been using pkgbase on 15.0 for months and had no problems at all. the initial switch is still a bit of a faff, but if you're installing a jail from scratch with pkgbase that's not a problem

mage: at this point i'd *never* go back to any other method and i highly recommend pkgbase

huh, seems after installing FreeBSD onto a new, third hard drive, it automatically pulled in my old 2 HDDs with their zpool

jemius: i would expect it to be in the `zpool import` list, but not automatically imported

I reinstalled with a new zpool name and now it seems fine

Anyways. Now I'd like to repartition the unused two drives, but gpart tells me they're "busy". Hmm.

the ones with the zpool on them?

is it active and mounted?

`zpool list`

Fortunately I only had that happen when I tried to "install" a new build and it just warned me before I overwrote my old pool and I was able to rename it then

It left them alone for me... but I was on different controllers though (if that matters)

ah, got it – you have to delete all partitions on a device, first

how would I put a users home directory into another zpool?

zfs create otherpool/home

zfs unmount zroot/usr/home (or whatever it is

zfs set mountpoint=/home otherpool/home

Hm. Thx

so is the `mount` command line tool ever used for anything on freebsd?

if it's zfs, no, not really

So if I create a new zpool, that already contains a ZFS file system – what happens now if I do zfs create within that? Is it a filesystem within a filesystem? Seems more like a new mountpoint / directory to me

it won't let you create a zpool if it's already in use by another pool

oh, but if you have your old pool, and zfs create oldpool/blah yes, you'll get /oldpool/blah _probably_

* you can 'regraft' the tree and you can choose to unmount branches also

that's why i set the mountpoint otherwise it would have been /oldpool/home rather than /home above

rtprio, I was asking because your command from above basically is zfs create within a zpool, right?

yeah, that's right

jemius: it's called dataset what was created by zfs create

it's worth playing with zpool/zfs before it's your OS drive(s)

how can you make such a new mountpoint on a different pool permanent? A reboot resets everything…

it shouldn't

Seems I've meesed up then and have two /home

oh, that was my bad, i just unmounted hauptsystem/home, but didn't tell it not to boot next time

zfs set mounted=no hauptsystem/home

alternately boot into single user, move the files around if you need to and `zfs destroy -r hauptsystem/home`

"mounted is readonly"

er, shit

should be canmount or something similar, alternatively unset the mountpoint property

thanks nimaje i was drawing a blank

alright, that did the trick. Thx guys

if you ever migrate a pool to a new / different system you have to mount everything manually again, right?

you have to zpool import the pool, what gets mounted is decided by the properties of the datasets

"properties of the datasets" – what does that mean?

stuff you can read via zfs get and sometimes write via zfs set from the dataset, like mounted, mountpoint, … zfsprops(7) should list them all I think (except that you can create arbitiarly user-definded properties, that just get saved for you, but zfs won't use itself)

OK, thx

I'm writing large amounts of data on a pool, and zfs get sometimes reports that the amount of data on the FS is actually decreasing

can that make sense?

are you writing it to the correct pool?

yup

Also, several calls show that it is increasing, overall

just sometimes, sometimes it decreases for a minute

There are simultaneous writes ongoing. Maybe it sometimes defragments or re-compresses stuff?

there is some buffering or caching

it seems FreeBSD calculates file sizes in Gibibyte, and Linux in Gigabyte?

At least `du` gives different sizes

What does `du` return on a compressed file system?

you can choose what output you get

in both zfs/zpool and du/df

sth here is very awkward, my folder of movies has an apparent size of 102GB (as on Linux), but the (compressed?) size is 92GB – that's 10GB less. `zfs` however shows that only 7GB are saved by compression

Oò

are you familar about how 'blocks' work on a file system?

obvously if you have a file 1 byte long, it takes more than 1 byte to store, up to 4096 bytes because that's the block on the file system

i'm sure you can fine a more eloquent stack overflow answer about it

hm

Movies tend to be a lot larger though, so there aren't that many of them in 102GB. Certainly not enough to explain the "missing" 3GB.

But one possible explanation, or part of one, can be that the reported savings here do not include savings in metadata compression (I think..?)

Still much much more than I would have expected, though.

me too. The video data itself is imcompressible

many contain subtitles… but still…

du -h <dir|file> gives actual on-disk use. Add -A to get "apparent" use.

ZFS is pretty good at not wasting cycles on data that can't be compressed anyway. So there's that, at least.

(I add -h out of habit since I don't deal well with 512b blocks)