bugs.freebsd.org/bugzilla/show_bug.cgi?id=255271 is bug of polyex

Title: 255271 – Cosmetic: service -e lists sendmail if sendmail_enable="NONE"

Hey... quick and stupid question:

Let's say I create a zfs vdev with a single disk. Can I later grow this vdev into mirror, adding the second disk?

and even further:, Can I then grow the vdev mirror (with 2 disks) into a vdev with 3 disks raidz?

you can turn a non-redundant vdev into a mirror with zpool-attach(8)

you can't do the latter

llua: thanks for the prompt response.

llua: Can I turn a non-redundant vdev into a raidz (without the mirror step)

no

I see. lets say O do the firt step. (non-redundant into mirror vdev -> into a pool. Can I add a new vdev mirror (2 mirror vdev using 2 disks each) to that same pool and expand capacity?

with zpool-add(8) you can do that, only newly written data would be striped between the two vdevs tho

there is a #zfs channel too btw

good stuff, thanks.

install_from_index() in freebsd-update has be so slow, looping over install(1) for hours.

has been*

There is a way, using the geom_zero loadable module, to set up a raidz using only two disks - but I don't believe it's possible to do with only one.

yay, i'm on 14.1, and discovered my hosting provider changed plans, and I now have double the CPUs at less cost :)

any idea why CPU and memory use of processes running in the linuxlator layer are not visible in htop?

I can seeh the process, and see its CPU load

but not in the bars at the top

all the CPUs there are at like 1%, while the process says 40% cpu load

yourfate: see if they appear in `top(1)` first, I'm guessing that htop is missing some logic to read the linux flavoured processes

htop shows the process

but doesn't add it to the totals att he top

or maybe I don't fully understand it

aaaah I think WCPU mans "this process uses 40% of the cpu time being used rn"

not 40% of avaiable CPU time

yourfate: WCPU is cumulative usage of all cpu cores

IIRC but man.freebsd.org/top will give a proper answer

soo, in theory, if there was only 1 task, which used, say 20% of one CPU core, but b/c its the only task running, WCPU would be 100%?

no

if you have 1 process running at 100% on 2 cores then:

top will show CPU0 100% user, CPU1 100% user

and CPU2-7 will be 0% user

and WCPU should show 200% for gameserver

yourfate: theres a more accurate description in the manpage above, but my explanation is useful enough

WCPU = Weighted CPU

right, I just read that

ok, it seems the gameserver is just a lot more threaded than I had assumed, using all the cores roghtly equally

roughly

the OS will try to spread the load across all cpus unless a program binds itself to specific cores intentionally

** not entirely accurate, again, but reasonably useful

another thing, it says size ~7.8GB in there

which I assume is memory usage

size is the total size of the virtual memory mapped for the process

that also counts mmap() ed files, shared libaries ect

oooh that would explain it, I think this process uses mono :x

is raidz expansion something that is supposed to work with 14.1?

ridcully: no, i think this is only in 15.0

lw: thanks

so, looking at the output of `zfs list`: gitlab.com/-/snippets/3717175 I don't understand it. why are there ro many different datasets mounted on `/`?

Title: zfs filesystem list ($3717175) · Snippets · GitLab

there are also a bunch of old snapshots I'm trying to get rid of

yourfate: they're not actually mounted - if you check the 'canmount' property it will be (i believe) 'noauto'. those are your different root filesystems created by bectl

but thye say they are referenced by those

if you don't want them, use bectl to delete your old BEs, that should also delete the zfs filesystem

so, I guess those are snapshots created when system upgrades happened?

(if you use freebsd-update, i believe it creates a new BE each time you run it, so you can easily roll back if something goes wrong)

yes

nice feature

so 'bectl list' and 'bectl delete <name>' for the ones that aren't active, if you don't want them anymore

er, destroy, not delete

ye, i'll keep the one befor now

and destory the others I guess

actually to be pedantic, those aren't snapshots, they're complete filesystems (cloned from a snapshot) which is why they show in 'zfs list' by default

the BSD tools seem to like destory

in this case i assume it's bectl destroy to match the zfs destroy command

I get really annoyed when I guess the wrong verb for commands. I haven't had a problem with bectl because I've worked on it, but I do wonder if others trip over it

yeah

bectl doesn't seem to provice autocomplete info :/

kevans: i think in this case i'm probably confused because it was "ludelete" on Solaris...

woah, deleting those freed up around 40 GB

quite a bit on a 160 gb server

that's a surprisingly large amount, do you store application data on / rather than on zfs datasets?

I guess /compat is the biggest thing

with the compatibility layer stuff / linuxlator

home is in its own dataset

i'd probably put compat in its own dataset too so that doesn't happen again, usually these BE filesystems are pretty small

I want to set up a whole-machine backup. if I create a snapsho of the zroot pool, and then back that up using restic backup, then destory the snapshot, that seems decent?

like upgrading from pX to pY is going to be a few MB at most

here ist the output of `bectl list`: gitlab.com/-/snippets/3717180

Title: bectl ist ($3717180) · Snippets · GitLab

that doesn't accumulate to 40GB I think

(output from before I deleted them)

i usually just do zfs destroy -R blah, where blah is the snapshot taken during upgrades (and -R being needed because it has a clone)

yourfate: it might do if you had includede the snapshots in the list

hm?

'zfs list' only shows proper datasets by default - 'zfs list -t all' will also include snapshots, which can consume space

.oO(have we really been doing auto-BE since 13.1?)

time flies

kevans: 13.1 wasn't that long ago! lots of releases nowadays... feels like 14.0 only just came out and now there's 14.1

lw: I thought the bectl list would include the snapshot sizes.

I added the output of `zfs list -t snapshots` before the deletion to the last snippet.

those sizes match what bectl reports

back to what I originally planned: is doing a ZFS snapshot, then backing that up to a remote maching using restic backup a valid strategy?

oh damn, the snapshot contains nothing, I need to snapshot all the datasets individually? :/

yourfate: Or recursively.

wait, I can't find the snapshot I created

ah b/c the dataset is not mounted anywhere?

but those I then have to find in all the differnt `.zfs` directories

I can't just back them up as one

I think?

you can recursively create snapshots, and you can use zfs send to stream them either to another zfs system or dump them to a file vs trying to rsync a bunch of .zfs/snapshot directories.

isley: but i'd still have to call the zfs send on each one of the recursive snapshots

I can't just do a recursive zfs send for all the snapshots, can I?

yourfate: i have found tools like synoid and sanoid to be quite helpful for zfs backups.. as it uses zfs send and zfs recv

Title: GitHub - jimsalterjrs/sanoid: These are policy-driven snapshot management and replication tools which use OpenZFS for underlying next-gen storage. (Btrfs support plans are shelved unless and until btrfs becomes reliable.)

I can zfs-send right into restic, it can backup from stdin

yes it can

I generally like it and use it for all my other machines, so I thought I'd use it on the bsd server too

the backup target is a hetzner storage box, which I can ssh/sftp to.

yes

you can even tunnel through the ssh and have compression on the fly ahnd encrypted

good things to learn, zfs send | zfs recv is the foundation.. after learning that, i went to sanoid/syncoid as i could have it scheduled and ssh tunnel to remote locations, that is all

I have zfs send/recv'd before

when I moved a zpool to a new drive

but I still have to zfs send every dataset snapshot manually

also, if I had the snapshot as an FS, I can then use the restic mount to browse the old snapshots, if I use zfs send I cannot browse the data of old snapshots

yourfate: you can use -R

not sure if it's exactly what you look for though

that sounds nice

still can't browse the files then tho

I'd have to zfs receive it fully, can't just browse the mounted remote backup repo

you can browse the remote one just as you browse the local one

I wouldn't do zfs receive on the other end

I'd just `zfs send -R zroot@snap | restic backup` basically

so your snapshot ultimately is backed up as a file?

ye

but restic dedupes the file

as in, the content of the file

i think it's discouraged to back up zfs send streams as files over the long term because of possible changes in zfs that could render your file backup unusable or difficult to use, though these days i guess that's not as likely

if that dedup just deduplicates on a fixed block boundary, then it may not actually succeed in deduplicating at the logical level (since identical content across snapshots is not necessarily aligned that way)

but, backing up like this for a disaster recovery scenario, where you do it regularly and don't expect to ever use the data (and if you do it's not too many months after you created it), is a good idea

i think the consensus is that you want to do regular backups into an actual zpool

but that does make it more difficult, so it's just a judgement to make. backing up to a file is not unacceptable

(also, in the case of incremental snapshots, if you backup to file, any corruption or failure in just one incremental snapshot could make it impossible to use any of the ones which came after)

ye, that's why what I initially wanted to do was to backup the `.zfs/snapshot/...` directory

but those are strewn all over the FS when I do a recursive snapshot

I can't coveniently get those from one location

hmm, i haven't used .zfs much, but i don't think it changes the issue, which is what you are doing on the receiving side

it does, in there I just see the data as regular files

and can back them up like regular data, not some zfs send file

ah, you mean to backup the files on the filesystem themselves

ye

well i haven't used .zfs much, but another option would be to clone the snapshots in question, not sure if that is preferred for you

clone?

could surely be automated

clone so that you essentially mount the snapshot

ye, which is what the .zfs does

they are basically all mounted in there

but not recursively

looking at my system, it seems like you would need to go into the .zfs for each child dataset

that's the issue right?

yes!

b/c for example if I backup the root dataset, it won't include the homes

then I'd have to backup each individual home dataeset

yeah, but you could automate this by getting the mountpoint property of each child

yes

that seems like it would make the backup script complex

i don't think it'd be too bad. in the case of a child dataset snapshot, just add the name to the name of the file you send to your backup service. the parent and childs are all treated the same and you iterate based on the output of zfs list -o name,mountpoint -r -H or similar

you'd just need to figure out how to systematically identify your dataset name in the backup file. maybe replace / with something else depending on what your service accepts

right. if there was a simple way to recursiveyl mount a snapshot I'd just not have to parse anything

I found a tool call `zfsnapr` that does that

idk how good it is

yourfate: This discussion has gone on for long enough that I'd be grateful if you'd restate your goal.

mason: the plan is to backup a recursvie snapshot of an entire zpool using a non-zfs-aware backup tool, in my case restic backup. For this it would be cool if I could recursively mount the snapshot as one filesystem, so I don't have to collect the data from the individual child-snapshots from their respective `.zfs` directories

use sanoid/syncoid, and it'll take care of determining the most recently common snapshot and incrementally handle all the rest

ah.. non zfs-aware...

ye, I'm backing up to a storage service that is not zfs

otherwise it would be easy

to be exact, the target is a hetzner storage box, which I access over ssh/sftp

yourfate: I'm not sure I'm going to recommend this, but what about trying as a POC at least something like a file on the remote side, accessed via sshfs or something similar, used as backing storage for a pool to which you back things up with native ZFS tools?

The ZFS operations are all local then.

There are other ways you might make the file available, but sshfs comes to mind as arguably the simplest.

I already mount part of that box using sshfs, so this is an intersting idea. but idk how well that would handle connection issues etc

Well. ZFS should at least keep things sane if the connection breaks.

iscsi would be another option, albeit with somewhat more complexity.

Anyway, it's what I'd try first.

agreed

yourfate: Oh, forgot to mention, mdconfig is probably your friend here, in case it wasn't clear.

y'll look into it, but probalby not now :D

I

Hey guys, can I use NULLFS to share poudriere data directory with an apache jail ?

devnull: I think so