OMG, the quarterly update remove my installed vscode and don't provide it anymore

I'm new to freebsd but this seems wrong to me. I really need that vscode !

doug713705[m]: There should be a changelog that says why.

didn't saw that changelog before applying the upgrade.

I knew that new version of vscode were unavailable for some reason related to blacklisted electron version in the build environement.

But i did not expect to have vscode uninstalled !

(electron): bugs.freebsd.org/bugzilla/show_bug.cgi?id=270565

Title: 270565 – electron* ports are blacklisted from the build

the signal-desktop app also has been uninstalled, I guess for the same reason. Those 2 apps, vscode and signal-desktop, are electron based

I thought someone noted Chromium also going but I haven't verified that myself.

but for now, I need to learn neovim from scratch so I can do my work :(

vim is pleasant

doug713705[m]: IMHO, it'll be time well spend and a skill you'll use for a lifetime.

I only looked at 'pkg upgrade -n' but I didn't see chromium being uninstalled.

I use vim but it's not as complete and featur rich as vscode

I just use vi (as in nvi)

but I should probably learn other things too

so neovim will be a life saver but I would have prefered to plan this learning !

nvi doesn't let you do things like four-space tabs.

What's neovim as compared with vim?

s/neovim/& offer/

neovim as some "modern look and feel" + plugins and modern features like one can find in vscode (or so)

mason: :set ts=4 ?

xtile: That's still hard tabs though, and then anyone without that setting will see a very funny version of my files.

sort of vim on steroids: github.com/LazyVim/LazyVim

Title: GitHub - LazyVim/LazyVim: Neovim config for the lazy

ohhhh

I see what you mean.

xtile: Of course, I turn that off depending on the precedent set by a file I'm editing if it differs.

Hmm. I just tried...

:set expandtab alongside :set ts=4

I get 4-space indenting with this

xtile: Is this -current? I heard something was going to happen in -current with both /bin/sh and nvi that'd be interesting, unless I'm making things up.

Nope, it's in 13.1-RELEASE-p7

(I think it was some sort of tab completion thing with sh)

hm hm

Sure enough.

Popped those in my .exrc and it did as you say.

\o/

Hm, backspace doesn't delete a full tabsworth of autoindent, but ^d is probably enough.

Hm, I think I've found my second-ever bug in nvi. set expandtab, set ts=4, set ai and then tab in and ^d back out. If you tab in three times, the first ^d moves you back four, but the second one erases everything.

interesting

The first bug I found, decades ago now, was similar. Delete (dd) an empty line and if it's next to the last line in a file it'd delete that too.

That one's long since fixed.

xtile: Thank you, though. This is interesting and might break my "dependence" on vim.

\o/

I'm fine with people using whatever works best for them.

I use Emacs sometimes too.

And sometimes I use viper-mode inside Emacs.

Though I do get mildly salty when people say "Don't you mean vim?" when I say I use vi :^)

Yes.

very mildly so

At least vim isn't objectionable.

is there any good solution for zfs high-availability on multiple nodes ?

commercial or open source

last1: ZFS, I'm not sure. That's what OneFS does, and that's FreeBSD based but not, I think, ZFS.

It's for Isilons: en.wikipedia.org/wiki/OneFS_distributed_file_system

Title: OneFS distributed file system - Wikipedia

yeah, I know what it is

costs like a million $

It's cheap compared to, say, NetApp.

there are some other options, like drbd, rfs-1

for zfs HA

but I want to know what people here thought the best way was

Yeah, compose your pool out of iscsi from multiple hosts or something. Unsure if there's anything packaged that does it.

Rolling your own wouldn't be terrible.

Oh yeah, good point. Forgot about FIPS certification in terms of BoringSSL vs. OpenSSL, although...

Title: FIPS 140-2

Title: OpenSSL FIPS 140-2 Validation Certificate Issued - OpenSSL Blog

Not sure how current the one for BoringSSL is, but only the "core" is FIPS certified, whereas it appears OpenSSL as a whole is fully certified.

meena: Normally I would agree with the sentiment of forking vs. contributing upstream, except when it comes to crypto, I personally defer to concensus "domain experts".

I remember reading that the OpenBSD guys forked LibreSSL because the codebase as a whole for OpenSSL was so terrible and because it would require breaking changes to fix anyway, so forking apparently made more sense in that specific case.

Hmm, LibreSSL supported was initially added and then dropped on Alpine Linux, Gentoo Linux, & Python 3.10+. I wonder if it broke too much stuff & OpenSSL was considered (audit?) to be "ok" now or if there was some kind of licensing/culture issue clash.

libressl broke API a few times, and many found it not worth the effort to follow that

Apparently, according to this at least, OpenSSL broke back-compat and LibreSSL had back-compat as a critical goal, and so OpenSSL 1.1.x changes broke on LibreSSL...

Title: williewillus comments on What do you think about the recent drop in LibreSSL in many Linux distros?

Which is kind of lame, I guess, but I don't know enough to have any real opinion. I also remember LibreSSL having an issue with OpenSSL bugs not being announced in advance to them (but it was announced to others?), not sure if they wouldn't sign the disclosure embargo, though apparently Google decided early on to play nice with LibreSSL.

Ah, 1.1.1k fixed the issue linked by /u/joshhatesusernames (CVE-2021-3450).

any recommandation for a pci sata expansion card? (running 13.1)

morning! is PkgBase still a viable option? i've heard rumors of its demise now and then. i currently have some non-tier-1 boxes on 12 that i use PkgBase for. should i keep doing that for (the upgrade to) 13 as well, or are there other recommendations?

dk: 13 worked very well for me on PkgBase

that's great to hear, ty

dk: i used to run a repo: freebsd/freebsd-doc #143/files

Title: PkgBase.live: add an un-update by igalic · Pull Request #143 · freebsd/freebsd-doc · GitHub

meena: What kind of hardware is required for it?

_xor: codeberg.org/pkgbase/website/src/br…h/main/howto/howdo.md#prerequisites that's the last it ran on

Title: website/howdo.md at main - website - Codeberg.org

but, I've had more CPU and less, CPU and I've had more storage and less than that, it's all workable. but right now, i think, it needs to be amd64, because freebsd/poudriere #1048

Title: PkgBase: why does poudriere require qemu to cross build FreeBSD? · Issue #1048 · freebsd/poudriere · GitHub

1048 – ep driver fails to detect card when told specific values bugs.freebsd.org/bugzilla/show_bug.cgi?id=1048

is anyone working on remaking the www.freebsd.org website to look more modern?

ugh

any idea why with a DEFAULT_VERSIONS+= python2=2.7 python3=3.11 python=3.11 in my make.conf I'm getting tons of: "Ignored: Unknown flavor 'py39', possible flavors: py311" when building with Poudriere ?

I don't understand: 1) why it tries to build @py39 flavors when default python version is 3.11 ? 2) why @py39 flavors fail when it is the default Python version?

should I set PYTHON{2,3}_DEFAULT too in make.conf?

maybe you need to purge @py39 flavors, firstly

what do you mean by purge ..?

pkg delete

my server is still frozen

trying to delete zfs datasets

it's been over 24 hours

should i give it another night

would i risk anything forcefully powercycling it?

how could i fix it assuming i can regain a shell

angry_vincent: it's with poudriere

do you have some example port for which that happens?

Little unofficial news item: 13.2-RELEASE images are already available for most architectures, e.g. at download.freebsd.org/releases/amd64/amd64/ISO-IMAGES/13.2 for amd64

Title: Index of /releases/amd64/amd64/ISO-IMAGES/13.2/

nimaje: gist.github.com/silenius/ea5f202ae151e063952da8cae8b423f6

Title: gist:ea5f202ae151e063952da8cae8b423f6 · GitHub

ok, no idea where that should come from for devel/py-pycparser except for explicitly listing devel/py-pycparser@py39 hm and except for a bulk -a the better question would be which port pulled them in

meena: as qemu not being build for aarch64 is a problem with the ports tree, is there a report on bugs.f.o? and shouldn't there be a ONLY_FOR_ARCHS_REASON for every ONLY_FOR_ARCHS (or something like that)?

nimaje: it's been there since the beginning

but is there a problem report for the missing ONLY_FOR_ARCHS_REASON? the port eihter unnessesarry restricts archs or is missing _REASON, maybe both and that upstream problem report reads like it should be supported

nimaje: i haven't had time to test it

I'll check

bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=qemu-user-static doesn't look like it

Title: Bug List

nimaje: bugs.freebsd.org/bugzilla/show_bug.cgi?id=270685

Title: 270685 – emulators/qemu-user-static: missing ONLY_FOR_ARCHS_REASON

seems to be quite some ports that are missing _REASON if I did my check correct for f in */*/Makefile; do awk '$1 == "ONLY_FOR_ARCHS_REASON=" { has_reason=1; } $1 == "ONLY_FOR_ARCHS=" { has_archs=1; } END { if (has_archs && !has_reason) { print(FILENAME " is missing ONLY_FOR_ARCHS_REASON=") } }' $f; done

nimaje: you wanna open hugs for all of them?

you said the forbidden word!

Oh right, I was reading a blog post about generative algorithms and copyright.

any consensus on that topic yet?

meena: this is just the opinion of one person, of course - but I think she's got it right, that at present nobody can risk using it for commercial purposes, since it's an entirely open question and the worst outcome is that you get sued for more money than you can reasonably expect to make of it

debdrup: are you aware of any viable zfs ha solutions for FreeBSD ?

I was considering drbd or rsf-1 but I think there might be more

last1: please don't ask me.

If I know, or think I know, the answer to a question posted, I'll answer - but don't expect me to know the answer.

fosstodon.org/@RL_Dane/110156008726592753 this is kinda impressive.

Title: R. L. Dane: "Oh #FreeBSD, you just took the negative space del…" - Fosstodon

if you uninstall chromium in that process, you'd free up double that

I wonder how badly ZFS performs on Ceph…

Also: don't use drbd if you only got two nodes

why not ?

because of split-network issues ?

last1: what we do here is: we have two "big" machines, on each of them we create a zvol and we export them through iscsi to $servers, and on the $servers we create a zpool mirror over the two iscsi blocks

the advantage is that you have only one two LUNs (although there are many disks) and you don't have to resync the whole volume where one of the two zvol dissapear (reboot, upgrade os, etc)

so when the disconnected zvol rejoins, it doesn't have to resync ? how come ?

last1: yeah, you're pretty much guaranteed lose data in a split brain situation. you need a majority quorum, which requires at least three nodes

meena: I guess this is why that rsf-1 solution requires a serial cable between the two nods

*nodes

but I haven't had a server with serial port in quite a while lol

last1: because zfs knows exactly which blocks have been modified so it only writes the delta

last1: mage's solution sounds pretty cool. so perhaps the question should actually be: what kind of hardware, network and price restrictions do you have?

mage: that's not a bad solution, however we'd rather export the data via NFS

so then the problems lies in creating yet another HA floating-ip NFS server-cluster

otherwise there is also minio, but your need 3 nodes

last1: yeah, I must admit that the NFS server here is the only SPOF and I haven't found a good replacement

maybe Minio, but I haven't tested it yet

I think you'd have to pay for minio for more than one node to be usable

maybe: export serverA blocks to serverB , serverB to serverA, have NFS on each with pacemaker, floating IP, etc

right now my hardware is dual intel sp2 cpus, hbas and 6 x 7.68Tb Intel S4520 ssds per node

each node is connected via lacp to vpc-linked switches

@10gbps

another solution is to use something like zrepl, snapshot every minute, and use CARP with devd scripts

but.. beware of split-brain

mage: how about that idea to export the drives to each other ?

and run nfs locally on each node directly

we used something similar in the past (a pool over x local disks and x iscsi luns

you've to test it carefully

but you stopped using it because of issues ?

also, how do you export the iscsi luns ? drbd ?

I have also seen some references to HAST on some older mailing lists

is anyone using that ?

last1: again, if this compares to drbd, you need three boxes

these solutions sound like potential pitfalls everywhere, I might just do what everyone does on the forums. sending snapshots and manual failover

basically, with almost any clustering solution you need three or five or seven etc nodes.

and the ones that work with two nodes are probably selling snake oil, or are lying about one or more parts or CAP

*of CAP

I was actually considering linbit, they do sell a 2-node solution but I had lots of questions that didn't sit right

hence, here I am

last1: they also sell Desaster Recovery, so maybe that's related

I've installed FreeBSD 1.0 on an emulated 486 with 12MB of RAM

Just got X11 working yesterday

Hoping I'll be able to get networking working too, today

FreeFull: exciting

I'm a bit surprised that the tar command included with FreeBSD 1.0 is GNU tar

meena: that's funny :)

Ooh, good sign, got an IP address from DHCP

Just gotta figure out how to configure routed

Seems like the answer is not to use routed, and instead just set a route manually

It's working

mason, I figured out why I couldn't get internet access from my jail last night

I was testing jails on my virtual machine (which is on my lan) and on my jail I assigned a new IP address from my lan (which worked)

last night i as trying to configre the jail on a VPS and I assigned the jail its own local ip number (which didnt work)

so today I assigned the jail on the vps its external ip number and voila, it worked

I ended up buying FreeBSD Jail Mastery and will get to Chapter 9 on networking to figure out the rest

Thanks for your assistance

interesting, unplugged my keyboard, replugged, layout is set to standard xorg

FreeFull: libarchive didn't exist until the mid-2000s

I see, so up until then GNU tar was the only real option?

Well, as the HISTORY subheader for tar(1) mentions, GNU tar wasn't invented whole-sale.

Before it was called GNU tar it was called pdtar and was developed on SunOS.

Oh, my apologies. Apparently it originated on 4.2BSD.

have you used it with tapes?

At least according to archive.org/details/PDTAR-1.21-src which is probably about as authorative as it gets, considering John wrote pdtar and uploaded that.

Title: Public Domain (PD)TAR 1.21 Source Code : John Gilmore : Free Download, Borrow, and Streaming : Internet Archive

Interesting

la_mettrie: pdtar? No, before my time.

Kinda surprising, I can X forward mpv into the FreeBSD 1.0 guest and it works

Very slowly though, but that's to be expected

It's not that surprising; X hasn't really changed for... a VERY long time.

This reminds me, I wanted to see how Wayland would work for me on FreeBSD.

X11 it self dates back to the 1980s.

msiism: when I occationally use it for things that aren't alacritty and Firefox, it seems to work fine.

Good to know.

X11 from 1993 lacks a lot of the extensions that newer programs depend on

That's not exactly surprising.

Backwards compatibility is a fair bit easier than forwards compatibility.

it's pretty cool tho, that you can just send a video thirty years into the past

no notes about FreeBSD 13.2 RELEASE just yet, anyone?

FreeFull: can you xforward anything and it not be slow?

xterm performance is ok

When xforwarded, that is

xlinks runs ok too

RoyalYork: Glad to hear it! As a general role of thumb, anything you can do on the host, the jail can do too. Likewise, if something isn't valid for the host, it won't work for a jail either.

rule of thumb*

is an ashift of 12 a good value for intel enterprise ssds on zfs ?

or can I find the optimal value

*how

last1: There's some useful discussion here: forum.proxmox.com/threads/samsung-s…ight-ashift-size-for-zfs-pool.71627

Title: Samsung SSDs a right ashift size for ZFS pool? | Proxmox Support Forum

TL;DR you want to accomodate your device's actual block size, which may or may not be visible.

yep, it's not visible :|

last1: is it nvme?

nvmecontrol identify <namespace> should list the optimal lba format, which includes the blocksize

no, intel ssd dc s45XX series

by default I see the installed sets an ashift of 0

the question was is it nvme or sata

*installer

s45xx are all sata drives

ok.

kraptv: it'll happen when it does.

so 0 means auto-detect, how can I know what it auto-detected ?

last1: It likely can't, and I'd expect 12.

last1: I'd tend to look online for specs if anyone's published them.

alright, but in the meantime, if it just shows 0, is there a way to see what it's working with ?

There's a couple of sysctls that control the minimum and maximum values for the automatic ashift adjustments.

last1: You can probably explicate 13. Not sure there's a way to say "tell me what you're going to guess" without actually doing it, which might be suboptimal in this case.

But I'd research first.

yep, min max shows 12 - 16

vfs.zfs.min_auto_ashift=12

There's never really a downside to having an ashift that's a bigger exponent than the equivalent number of bytes in a sector.

I was just worried it would pick something like 4

just file.physical_ashift is 9 , as well as file.logical_ashift also 9

It's only a problem if your ashifts exponent results in something smaller than the sector size of the disks you're running on (which can't really happen, because the default is 12 which works out to be 4096, ie. even drives that pretend they're 512 while being 4k in reality don't get cheated).

Where are those values from?

I just did: sysctl -a | grep -i ashift

I don't see those sysctls on my system. *shrug*

vfs.zfs.vdev.file.physical_ashift

that's for file based vdevs

Oh, you stripped part of the OID. ;)

not something you use in real life :)

yes :)

That only matters if you're creating files via truncate(1) to use ZFS on, ie. when you're testing ZFS for the very first time.

That's also what sysctl -d would've told you.

Not all sysctls are documented, but a reasonable number of them are - and it's quite useful ;)

mason, RoyalYork: NFS only works as of last week ;)

meena: In which context? I'm kind of interested in getting into NFS with built in TLS, although it's probably useless until we're all geared up for post-quantum crypto.

4096/12==341.33333333333

mason: you can now run an NFS server in a vnet jail

anyone else type bc when looking for a calculator on android?

meena: 2^12

Why're we dividing 4k with 12?

Oh, hm, I guess I hadn't tried it before. Interesting.

meena: I'm pretty sure I've been using NFS since before last week. :P

do you guys use autotrim on your pools ?

last1: I do on my T480s.

Before enabling it on anything, I'd recommend doing a cursory look into whether your SSD is one of the ones that has quirky behaviour regarding TRIM (it's more common than it has any right to being).

FreeBSD has a list of devices with that known quirk, but that's best-effort since manufacturers don't exactly go out of their way of informing anyone (least of all any FreeBSD folks) of when they send out something that can end up making life miserable for people.

ok, so if it's unknown status it's safe to run trim every x days or not at all ?

If you're a hyper-scaler or a direct purchaser from the manufacturer, they may send out a PCN - but that requires a considerable amount of volume to get to that point, and even then they're more likely to just say "hey here's an update, maybe it's a good idea to update" (which, I might add, we've known about since the SSD reliability study that was published at FAST '20).

Well, one way to check would presumably be to use trim(8) on a disk that you're intending to use, and see if ZFS reports any errors - because ZFS is designed to report errors, even if the disk won't admit to them.

and if it doesn't report any errors, could that still lead to premature wear out ? I keep on reading this behavior on various pages/forums

TRIM is meant to negate premature wear-out, and badly implementing it usually leads to dataloss (silent or otherwise).

I'm not sure I see the workload where TRIM leads to premature wear-out.

If a SSD can wear out by enabling TRIM, it's probably QLC and therefore not meant to be used more than once anyhow.

reading the Intel docs, they have this phrase: TRIM is only supported on RAID 0. Beginning with the Intel® 7 Series chipset. the driver supports TRIM on SSDs in a RAID 0 configuration.

I thought it was an individual drive setting

I've no clue what that means.

I think it's referring to the softraid implemented by graid(8), so I don't think it's relevant in either case.

It's also talking about a decade-old chipset.

Title: SSD D3-S4510 series with RAID1 and trim function - Intel Communities

it's from last year...

It's still got nothing to do with ZFS.

It's entirely relating to Intels softraid implementation.

It doesn't even have anything to do with gmirror(8).

hmm, ok, I guess it got me confused because I can't find other specs where they say whether they support trim or not

in any case, my 6 drive raid 10 ssd setup does about 2GB/second. versus 500Mb in Debian's lvm

can't believe I even considered using that

Like I said, they're not likely to publish that kind of information.

Hi, I am new to freebsd andI wonder If I am required to use `pkg` as well as `freebsd-update` on a regular basis to make sure my system is up to date?

Yes, that's advisable.

Does `freebsd-update` manage/update some parts of my system that are not part of any package?

yes, kernel and userland

Oh ok, makes sense now. Thanks

And libraries and documentation (manual pages, examples, et cetera)

I'm coming from debian linux where there is no such distinction. Everything is managed by one package manager. So this separation confused me initially. But now I see for myself that e.g. `pkg info` does not list any kernel related packages.

there's PkgBase WIP

oo_miguel, In FreeBSD there is a division between "core" (base system) and "ports" (also binary packages).

Good to know. I personally have no problem using `freebsd-update` for now on my 13.1, once I learned this is required. No idea if it becomes more problematic on cutting-edge versions. i.e. If binary patches are provided.

These are managed separately and each is updated using a different update process.

I think I used only `core` so far, unless the ports are used automagically as well

oh

Assuming you are using binary updates using freebsd-update and pkg installing binary packages (the alternative is a source compiled install, also good) then

or I did like: pkg install vim # does it mean I used ports?

need to read more of the documentation I guess

"freebsd-update fetch" will fetch the new core files and "freebsd-update install" will install the new core system files. Without touching ports in /usr/local.

"pkg upgrade" will upgrade the binary installed ports in /usr/local.

By default the 13.1-RELEASE (for example) install will set up a system with the "quarterly" release upgrades. That's fairly conservative and stable.

I believe I heard/read that using the source-versions will let me finetune compiling options to my preferences

There is also a daily and weekly.

sounds worth a try as well.. at some point

Yes. You can compile everything from source.

Also, "freebsd-version" shows your current core versions, plural. I suggest always using "freebsd-version -kru" to show all three of the versions in the pipeline.

I have to confess that for now I run it on my raspberryPI only ... so guess I will wait with the from-source-compilation until I put it on my desk or lap

I probably would not want to run a source compilation on a Raspberry Pi. But for those are about to try I salute you! /o

I'll mention that one of the advantages of core being a fully cohesive unit installed all together is that it always works. There is never any problem with having the wrong initramfs tools or other mixed out of tree problems as sometimes hit by accident on other systems.

And the ports are separated off into the /usr/local tree and so if the core is updated including shared libraries then ports might/possibly/likely need an upgrade to get new shared library linkages. But the core always boots allowing one to upgrade the ports on the new core. Very reliable separation of powers.

I appriciate that.

Lastly I am one of the zfs proponents (it's truly awesome) and at times (such as from FreeBSD 12 to 13) new versions of ZFS become available.

rwp: That part is pernicious. /usr/local is for the local admin.

That's a separate upgrade to be done separately. Because holding off on that upgrade allows one to use the Boot Environments to boot the old kernel in the event of a problem.

zfs - also something I plan for the future. but again not on a raspberry ;)

This allows problems to be worked out before deciding to upgrade the ZFS file system under it.

oo_miguel: People run it on RPis.

mason, re /usr/local, Yes. That was a hard thing for me to accept, that FreeBSD takes over /usr/local when it is my dog given right to own it myself as the local admin!

But life is a compromise. And the overall result is very good. So we keep on keeping on! :-)

Last (for today) quastion. Tried the `freebsd-version -kru` and seems my userland is 13.1-p7 while installed&running kernel is 13.1-p6

Is this expected?

Yes. Expected. At that patch release there was no need for a new kernel.

That difference in versions caught me the first time too. Which is why I now suggest -kru all of the time. The differences can be important. But it is good to know regardless.

If the other two are different then it means a new kernel and core were installed but the system has not yet been rebooted to it yet. Needs a reboot.

So really it is -kr is kernel and core and _should_ be in sync, unless pending a reboot, and -u is userland.

Right, checked before the reboot and this was the case indeed

Ok thanks a lot. Learned enough for today!

And most importantly updated my FreeBSD :)

Come back any time! We are here all week. Remember to tip the wait staff! :-)

Allright, Just added tha channel to my auto-join list.

mason, "pernicious"? /usr/local? I am still contemplating what you said there...

I would certainly agree with "contentious". The real problem is that there exists no absolutely correct solution. So it is always going to be pragmatic compromise.

why would manufacturers hide the trim settings ? Is it possible they have firmware that manages that automatically behind the scenes ?

rwp: Yeah, it's a compromise, and hardly the worst one in the world. I prefer what pkgsrc does, using /usr/pkg. I guess FreeBSD ports are moving towards the flexibility to do that kind of thing in, say, Poudriere.

So here is my current problem. ZFS: "errors: Permanent errors have been detected in the following files: <0x4c>:<0x8e328>..." bsd.to/2ztq/raw

Title: 2ztq

I had TWO hard crashes in the last few hours. Which left things in this state.

I think my workstation hardware is failing. I swapped the drives into a different workstation and booted it.

We will see if the problem follows the hardware or follows the OS. Meanwhile... Is it possible to clean up the above pasted problem?

I note that everything is running okay and with the exception of losing two rather large files that I had just created (grr...) everything is otherwise working okay.

I have also performed two scrubs already. A scrub runs in about 1h15m start to finish.

I am guessing that I should "zpool clear zroot" and then "zpool scrub zroot" again to see what results.

Running "zpool clear zroot" did not change anything.

is there a software that manages zfs snapshots and send/receive for backup purposes ?

I'd like to backup pool1 every 5 minutes for example

and send it to another host

last1: I don't know if there is a tool, but it sounds like a job for a script run with cron.

I also have no idea if there is a tool but agree that a script from cron seems reasonable.

Meanwhile... I followed the suggestion from 4oo4 here serverfault.com/questions/576898/cl…rmanent-zfs-error-in-a-healthy-pool

Title: zfsonlinux - Clear a permanent ZFS error in a healthy pool - Server Fault

The suggestion was to start a scrub and then to scrub -s stop the scrub after a moment of it running.

And that worked!

last1: It looks like there are some: forums.freebsd.org/threads/looking-…-zfs-snapshot-management-tool.85848

Title: ZFS - Looking for a ZFS snapshot management tool | The FreeBSD Forums

However now I am going to start a full scrub again and let it run to completion. Hoping the errors are not re-discovered.

If errors are discovered again then I am going to grab a couple of spare disks and pour data off and on again.

rwp: gz :)

souji: thanks for using Google for me, weird enough that Google didn't point out the FreeBSD forum result first

on a side note, I do believe that Google is getting suckier

let me check these out, there is one big feature I'm looking for that I haven't seen any package have so far

souji, I feel that I am going to need the luck. But backups are current and I haven't lost anything. So, good! I just need to get things solid so I can go back to using it heavily again.

I want to initiate the send|recv from the backup server

not the live data server

rwp: yeah, backups are always good to have!

last1: I would be surprised if any tool is able to do that...

I'm trying to do that now

bkp server issues: ssh root@live zfs send | ssh root@bkp zfs recv

hope it doesn't create some sort of loop :)

looks good to me

I shuld just execute the command on the remote host

However, you would need an SSH key on the live server for the backup server if you do not already have one.

yeah, that worked

just had to use quotes

nice :)

ssh root⊙112 'zfs send -i zfs/testindex@now4 zfs/testindex@now5 | ssh root⊙112 zfs recv zfs/testindex'

I don't want the live server to hold keys to the backup server, only the other way around

this way if live gets compromised, hackers can't jump to backup and erase my backups or encrypt them

I'm surprised most backup tools don't use this method of thinking as default

With out the key, how do you connect back to your backup server?

son of a

lol

I can probably program around it wit perl/expect and actually use a password

but that's not ideal either, because a hacker could compromise sshd and read all that I enter

I guess the backup system could rotate passwords at every interaction, this way each password is valid just for that session

Maybe you can use sshpass on the server machine, so you could use a password

yeah, was just reading about that

but then the password would show in the process tree, which however would not be as big of a problem if you limit the visible process to only the own user

true, but the password would also be changed as soon as the transfer finishes

so bkp system: generates new pass, ssh using new pass, generates new pass

it would be vulnerable for the duration of the transfer

ugh, not ideal

there has to be another way

In my opinion, an SSH-key would be better for that.

but how would that prevent a hacker from ssh-ing into my backup server ?

they would only be able to, if they have root acces on your server machine

well yeah, that's what I'm assuming, the worst

they gain full priviledge on production and want to encrypt everything. live & backup

And if they have root acces, they can just wait for the next connect from the backup server, so yeah...

Is it possible to get the backups with an unprivileged account?

it wouldn't matter

if that account has snapshot access, then they can just use that to connect over and destroy the snapshots

commercial system have something called immutable storage

where no matter what, snapshots can't be removed except through time policies