Greetings!

I recently noticed that FreeBSD no longer creates /dev/ada0p0 and similar device nodes

when did this change? What can I do to reenable them?

(instead it now only creates /dev/diskid/... nodes which sucks)

it creates both by default

not on this system (13.2-RELEASE

)

what's the output of geom -t ?

RhodiumToad: fuz.su/~fuz/text/geom-t.txt

and ls -l /dev/*da* ?

# ls -l /dev/*da*

crw-r----- 1 root operator 0x7d 8 Sep. 00:26 /dev/ada0

crw-r----- 1 root operator 0x81 8 Sep. 00:26 /dev/ada1

so. what's happening here is that zfs thinks it owns the whole of /dev/ada0,

this is correct, it does

I am asking about ada1

and zfs also ended up tasting the p3 partition on ada1 via the diskid label before finding the direct ada1p3 entry, so it opened the disk that way, which disables the partition entries for ada1

(I said ada0p0 before as to not open questions about device numbers)

oh for fucks sake

why does it do this shit

why does opening the partition one way disable the other entries?

Shouldn't they be symlinks or something?

this is why the installer turns off diskid and gptid if you install as zfs

well this explains why I have no swap at least

it's to do with the "exclusive open" flag in geom

zfs opens the partition exclusively, so glabel (providing the diskid/* entry) passes that down to its open of ada1,

which prevents gpart from opening ada1 itself

this is a shit design

not at all

geom is a very good design, the problem is that zfs thinks it knows better

then ZFS must be patched

(though to be fair, some geom classes have a similar issue)

anyway, diskid and gptid can be disabled via sysctl

I want both

I want the issue fixed, not a workaround

as far as I know, zfs doesn't have a way to tell it which provider to use by name (rather than by content)

I see the problem in that geom has to propagate the exclusiveness down to the root

when it should suffice to have this one partition be exclusive

(and if zfs did open /dev/ada1p3, that would make the /dev/diskid/* entry for the disk go away, because again, exclusive open)

shit design

the problem with your idea is this:

if /dev/ada1p3 is open exclusively but gpart didn't propagate the exclusive open to /dev/ada1, then /dev/diskid/xxp3 could be opened as well, violating the exclusion

the problem is

that diskid appears to be implemented as an interposer

diskid is part of the glabel class

instead there should be some sort of aliasing system

and diskid/whatever should be implemented by creating aliases for other geoms

so this issue does not appear

(normal glabel nodes cannot be aliases because they are shorter than the underlying provider as they eat a sector for the label iirc)

this could even be reflected by having /dev/diskid/foo be a symlink in devfs

that's just one of the cases glabel implements

so?

what sort of reasoning is that?

that's like saying "oh we couldn't be arsed to do that right because this is one instance of a bunch of things we couldn't be arsed to do right"

what I meant was that "normal" is not the wrong term

*not the right term

RhodiumToad: I suppose sure they are all implemented the same way

shows that they maybe should not be

glabel implements labels based on disk id, partition id, filesystem id, filesystem volume label, etc. and the explicit labels are just one additional option

you don't need to explain that to me

what point are you trying to make?

also you'll note that DEV (which creates /dev/blah for geoms) is just another geom class

the whole thing is highly modular

once again, you don't seem to be making a point

the point is that there are reasons for the design

doesn't change that the design apparently has an idiotic flaw

just because a design is complex doesn't mean that it is unchangable

I see no technical reason why this cannot be fixed

the design is not at all complex, it's very simple in fact

that once again does not change my point

just because a design is simple doesn't mean that it is unchangable

adding the kind of aliases you're talking about would actually make it substantially more complex, because it's a major layering violation

you just need to find the right place to implement these

or rethink how the mapping of geoms to device nodes work

hardlinks are also a layering violation

yet they work

and I'm not even asking for hardlinks...

right now a device node exists for each provider (that's not exclusively open by another class). for a provider to have multiple aliases in /dev would require some mechanism for getting all aliases suggested by classes further down the tree, and dealing with the resulting combinatorial explosion

so what

then such a change may have to be done

just because the design doesn't account for a solution to the problem right now doesn't mean it cannot be changed to do so

I'm sure nobody is going to DOS your system by creating too many nested aliases

plus you can resolve the combinatorial explosion by e.g. linking to paths in subdirectories that can in turn by symlinks

such that each alias is represented by a single symlink in the end

that would require for example changing the way *pN and other suffixes work

e.g. (ignoring compatibility for now), one could have the canonical device node be /dev/ada1/p4

right

and then have /dev/diskid/foo be a symlink to ../ada1

which prevents you having /dev/ada1

I specifically said to ignore compatibility for now, but I guess you don't care

Now the design can be made compatible by having the system generate symlinks from the old names to the new path-like names when they are accessed

just like /dev/dsp is only generated when you access it

(of course you need to chose file names for the new stuff that do not clash with the old stuff)

e.g. if you access /dev/ada1p2 the OS parses the name and tells you "it's a symlink to dsk/ada1/p2"

and then the usual path resolution rules apply

by all means implement it and see whether anyone likes it enough to allow it in

too much other stuff to do

and I am not familiar with the subsystem

nice

specifically, the allow_nesting options in gpart

and quite useful

hm. it looks like about half the infrastructure needed for what you want is already in place

there's support for this case: a disk device driver (e.g. nda) can create an alias (e.g. nvd0 -> nda0)

and geom classes will respect that by creating their own aliases (e.g. nvd0p1 -> nda0p1)

Hey all

RhodiumToad: sounds like it could work

so glabel would have to be modified to inject aliases into other geoms?

something along those lines. but the trick will be to make it work more dynamically, I think currently it only checks for aliases when initially attaching the device

basically it looks like enough work was done to allow the specific case of nvd -> nda

(which is why I said its only about half the infrastructure, that's not counting the actual work of choosing aliases)

hm hm I see

maybe exposing the aliases as a named attribute, and posting an attrchanged event when aliases are changed, and having providers react to that

could work

hi all

hi

I hope the cybersecurity job I get will let me use FreeBSD

(in the future)

I wouldn't want to use Ubuntu or Parrot.

it depends

Although to make the boss happy, I could convince them that I can run them in Linux jails.

If the jails get compromised, easier to recover from

and use ZFS snapshots of the jail(s) for the forensics of them.

not if the kernel gets compromised

though this is the same situation as with Docker on Linux

Then I have to suck it up.

Hm anyone else use synth? It's getting hung up on a port that has no pkg alternative.

namely textproc/obsidian

what do you mean by "no pkg alternative"?

there is nothing for it in pkg. So in synths case (and maybe poudriers?) it seems to be skipping it because pkg complains about it.

don't think it's a bug. feels like i'm missing something obvious here

oh you mean no package+

oh yes sorry

let me check

it has a restrictive license

what do you mean by "hung up"? it may need you to accept a license or somesuch

(that's why there's no pkg for it, because packages are only built for ports whose licenses permit distribution of packages...)

I'm checking on that

on the accepting the license being a potential issue

Yeah it isn't even producing a package for it. Which makes sense. Is there no way around it then you think?

Mostly asking out of curiousity. I can install it by just using make just fine. If there's a step that would enable me to let synth handle it in the future all the better.

xulfer: fix the license so FreeBSD can redistribute a binar

y

yeah thought as much

would /dev/dsp4 be the one for dev.pcm.4? ( in my case )

pcm4: <Conexant CX20590 (Analog 2.0+HP/2.0)> (play/rec) default

xulfer: LICENSES_ACCEPTED+= whatever in make.conf

where "whatever" is the license name used in the port

that satisfies poudriere, I dunno about synth

angry_vincent: yes, though /dev/dsp* nodes are created on the fly

angry_vincent: and /dev/dsp without suffix refers to the default unit

great

i am fiddling with sndio and hence the questions

ohh thanks

don't suppose anyone might be familiar with why i3 hjkl bindings don't seem to be working?

seems to be a common problem i guess? worked for me before. just checking to see if mayhaps anyone in here might know exactly what i'm talking about.

S3 option added to bacula11 and bacula13 FreeBSD ports.

anyone use syncthing on their freebsd box(es) and get the kqueue warning (notice)? forum.syncthing.net/t/warning-of-hi…despite-small-amount-of-files/19994 . I'm curious if the knowledgeable folks here do any tuning/etc

Title: Warning of high usage / system slow down despite small amount of files? - Support - Syncthing Community Forum

hrm…

RhodiumToad might know something, but, RhodiumToad has been looking for some alternatives to kqueue for specific tasks

scoobybejesus: ^

I'll keep an eye out! Thanks!

scoobybejesus: depending on what kqueue is watching, it can use a lot of file descriptors. the only thing a kqueue can tell you about a directory is that a file was created/deleted/etc on it, but it cannot tell you what file was modified and how. if you want to monitor all files within a specific directory recursively, and that happens to be many files, kqueue will use up a file descriptor for every

single file because you will need to open it in order to listen for changes on those files. kqueue is really not a great way to monitor directories sadly.

by contrast, inotify on linux can handle that fine, but because it treats the filesystem as a tree rather than a DAG, inotify breaks with hardlinks

a couple of years ago i've extended kqueue to insert additional per-event data but the locking required was extremely messy (and probably racy) and the performance was likely unacceptable so i scrapped the whole idea of making it more generic to support filesystems

i've got about 40k files in there now. it grows fairly slowly, and the box is a little oversized for its load, but still. i'd like to think 115G of data wouldn't cause the system to run out of file descriptors and come to a halt .. or whatever would happen

I'm surprised there's no tunable to raise any potential kqueue limites

hi, i wonder if there still is an upstream for ee. i tried to build it on linux out of curiosity and ran into some bugs…

or should i submit the patches to freebsd?

what kind of bugs? Or just system incompatibilities?

pstef_: it has an unguarded __FBSDID() macro in ee.c and when building with new_curse.c a struct gets declared twice

the latter might be a bug

pstef_: bsd.to/prvZ would be the patch to the 2nd issue

Title: dpaste/prvZ (Diff)

from our point of view, ee is supposed to have an upstream, but I can see that we've applied numerous fixes over the years

and the upstream page i found ( mahon.cwx.net ) seems to be down

last upstream version also was imported in 2010

I wonder how much has happened upstream since then

CueXXIII: what is the warning/error that you get without this patch?

pstef_: bsd.to/0vBq - since new_curse.h gets included in both new_curse.c and ee.c

Title: dpaste/0vBq (Plain Text)

pstef_: given that upstream is defunct, i don't think much has happened upstream

new_curse.c doesn't seem to get compiled under FreeBSD

pstef_: yeah, freebsd configures ee to build against ncurses

Also, we probably need to get rid of github.com/freebsd/freebsd-src/blob/main/contrib/ee/ee.c#L58 like we got rid of the others. but this is in contrib, which is the reason it wasn't axed

Title: freebsd-src/contrib/ee/ee.c at main · freebsd/freebsd-src · GitHub

So with upstream defunct, we'd move it to usr.bin/ee and remove new_curse.(c/h)

patches welcome :) Best sent via phab

meena: ah, so you are removing new_curse for good?

CueXXIII: i don't have commit, but that's what i would do

I am busy doing other things, for which i (luckily) also don't have commit (because I have no idea what I'm doing)

but! there's always reviews!

why remove new_curse?

if we're moving it usr.bin/ee and not using, that seems sensible, but maybe I'm shooting too fast from the hip here and not looking at the bigger picture

Title: PKGBUILD - aur.git - AUR Package Repositories

So far I've found my original Walnut Creek FreeBSD CD sets (2.1.7, 2.1.8, etc). Red Hat Linux 5.0, some ZIP disks, a few JAZ disks. I also have my original Sun SPARC workstation.

_xor, which sparc?

haha, i had a sparcstation10 5? maybe one of each