Search results

I'm not exactly up to date with OpenZFS development, but last time I've looked the NFSv4 ACLs in ZFS were not stored as extended attributes, but rather as "their own thing" assigned to the inode, and IIRC they didn't incur a performance penalty. I think this whole issue is deeply Linux-specific...

The easiest way might be to use debootstrap, as described at https://wiki.freebsd.org/LinuxJails. This will take care of all the dependencies for you. I can't find the Obsidian package in Ubuntu repos, though.

FWIW, I've just tested the official Spotify client (https://www.spotify.com/uk/download/linux/, the non-Snap one) in Ubuntu 18 chroot under 13-CURRENT, and it seems to work just fine.

Since 12.2-RELEASE, there's an easier way, described at https://wiki.freebsd.org/LinuxJails; it boils down to using debootstrap installed from the package.

Yes.

Already done: https://wiki.freebsd.org/LinuxJails

Folks, it would be very useful if you give 12.2-BETA2 a try. There's been some fixes to Linuxulator, and while most of it was focused on functionality unrelated to Steam (yet!), it would be useful to see if I didn't break anything by mistake. Any feedback is welcome. Thanks!

From what I can see, at least with Ubuntu Bionic the `service` command works just fine without systemd, so if you want things to get started automatically it should be a matter of a trivial shell script to run as init for the Linux jail.

The CentOS ports are mostly fine, I agree - from the end user point of view. The problem is, when you need something they don't provide, you're kind of stuck. Working deboostrap makes it trivially easy to install stuff that isn't available in ports, which is handy if you're a developer. (Also...

FWIW, thanks to FreeBSD Foundation I'm now working on it - the plan is to get the existing sysutils/debootstrap port to work correctly with up to date Ubuntu versions, so you could easily create an Ubuntu jail, as an alternative to the existing CentOS based ports.

Apart from using a separate microcontroller, I think the most feasible way would be to just dedicate one of CPU cores to run realtime code and tell the kernel to keep away from it. Might already be possible by using cpuset(1). I never got so far, tbh - it was just much easier to use GRBL.

Just for the record, autofs wasn’t ported - it was written from scratch, but in a way to make it similar from the user point of view to the OSX one.

Well, the ICL is common, but there is still some code there that’s only used by the initiator, and some specific to the target. The target-specific bits are missing for iSER. Which basically means the ISER is only supported at the initiator side, not target.

With NFSv4 ACLs - which means ACLs on ZFS - the ACL entries are evaluated in order, so when you match a deny@ entry before you match an allow@ - you’re denied access.

I have no idea; looks like it should be. Could you file a PR? Also - could you test it on the server side? I mean, verify whether the user that should have local read-only access to that file cannot write to it?

No, it means there is no way to prevent the file owner from changing the permissions. Marking the file read-only - ie preventing the owner from changing the contents - should still work as expected. The files in question, do they have ACLs? What does "getfacl" say?

I believe the "--timeout=600" is Linux-specific. Please remove it; you can set timeouts by passing options to autounmountd(8), but it defaults to 600 seconds anyway.

Not sure, I'm afraid; other stuff in life took precedence. Yeah, I think it should work on ARM.

I'm working on it. It's running fine, although in simulation-only mode for now. I'm slowly pushing my changes to the upstream, and will follow up with a proper port soon.

That's true, and that's why I said "kind of". I have on idea what ESX actually reports as "queue depth", to be honest. Still, it's something that is kind of related and might be useful.