Faster filesystem access with Directfs • Hacker News Board

Re: Faster filesystem access with Directfs

#21

Post by nine_k » Fri, Jul 28, 2023, 6:47 AM UTC

Patrickmi wrote: post #9

Am new to these kernel space but isn’t writes operation more security at risk than Reads if it is why not break gofer into 2 categories one writes, one reads embed the one with reads with sentry user space, this may not show any significant performance in real world use but it gets both benefits

One would only need to read your password via some unsecured hole, once.

The rest of the identity theft and pillaging your accounts would require no security weaknesses, just things working correctly in presence of legitimate credentials.

Re: Faster filesystem access with Directfs

#22

Post by topspin » Fri, Jul 28, 2023, 6:51 AM UTC

nine_k wrote: post #20

topspin wrote: post #19

Accessing local file systems from a container? What heresy is this? Containers must all be stateless webscale single-"process" microservices with no need of local file systems and other obsolescent concepts. Next thing you know someone will run as many as two whole "processes" in a container! Having dispensed with that bit of bitter sarcasm; solving their local filesystem performance/security problems is great and al…

A container, being basically a chroot, consumes a rather small amount of resources, mostly as space in namespace and ipfilter tables. If your containers use many of the same base layers (e.g. the same Node or Python image), the code pages will be shared, as they would be shared with plain OS processes. Running several processes in a container is the norm. First, you run with --init anyway, so there is a `tini` parent…

> Running several processes in a container is the norm.

I'm highly aware. The reason the word "process" is quoted in my highly down-voteable comment is the misuse of the term "process" by Docker et al. to mean "application." Google the "one process per container" mantra to see what I mean. Somehow the Docker crowd were oblivious to the 60+ year old concept of and terminology related to OS processes when they promulgated their guidance on how containers should be used.

I try not to indulge too many hang-ups in life, but that particular bit of damage is insufferable.

Re: Faster filesystem access with Directfs

#23

Post by dilyevsky » Fri, Jul 28, 2023, 7:05 AM UTC

topspin wrote: post #19

Accessing local file systems from a container? What heresy is this? Containers must all be stateless webscale single-"process" microservices with no need of local file systems and other obsolescent concepts. Next thing you know someone will run as many as two whole "processes" in a container! Having dispensed with that bit of bitter sarcasm; solving their local filesystem performance/security problems is great and al…

In k8s that already exists via CSI[0] but kubelet is handling the setup/teardown signaling and it requires 3rd party provisioner daemon so higher level than container runtime (runsc in this case).

[0] - https://kubernetes-csi.github.io/docs/

Re: Faster filesystem access with Directfs

#24

Post by dilyevsky » Fri, Jul 28, 2023, 7:08 AM UTC

Patrickmi wrote: post #9

Am new to these kernel space but isn’t writes operation more security at risk than Reads if it is why not break gofer into 2 categories one writes, one reads embed the one with reads with sentry user space, this may not show any significant performance in real world use but it gets both benefits

The risk here is that there's a bug in kernel that can enable dos / local code execution by the caller. Also like others pointed out - reads can be equally harmful if you read ssh private keys and whatnot.

Re: Faster filesystem access with Directfs

#25

Post by dontlaugh » Fri, Jul 28, 2023, 7:35 AM UTC

Dalewyn wrote: post #18

ninepoints wrote: post #14

Earlier quoted context omitted.

"Direct" here is more analogous to the Direct as in DirectX and Direct3D.

directfs has nothing to do with DirectX. I find it deeply ironic this needs to be said here.

DirectStorage does, thought.

Re: Faster filesystem access with Directfs

#26

Post by Dalewyn » Fri, Jul 28, 2023, 7:44 AM UTC

dontlaugh wrote: post #25

Dalewyn wrote: post #18

Earlier quoted context omitted.

directfs has nothing to do with DirectX. I find it deeply ironic this needs to be said here.

DirectStorage does, thought.

Ah... Okay, I think I see how the comment should have been read now...?

I will blame whoever named directfs for using a confounding name one way or the other. :V

Re: Faster filesystem access with Directfs

#27

Post by londons_explore » Fri, Jul 28, 2023, 7:46 AM UTC

These designs always seem so complex... And one overlooked feature of any API could totally break the sandbox.

Whereas a simple 'we run everything in a VM' seems much simpler and less fragile.

'We run this process in a VM-like mode where Linux syscalls aren't allowed but instead we define a new syscall-like interface which goes to privileged host code' seems like a good compromise. But in this case, that host code should have special abilities to mmap files into the address space of the 'VM' to make IO fast and efficient.

One way to do this would be to use undefined instruction traps to enter a debugger, which could then implement a syscall-like API. That would make it portable to any OS, yet ultra fast.

Re: Faster filesystem access with Directfs

#28

Post by ithkuil » Fri, Jul 28, 2023, 8:34 AM UTC

ec109685 wrote: post #12

I still don’t know why Google has gvisor and AWS has firecracker. Isn’t the firecracker approach strictly better than Google’s approach?

Firecracker may be better but it's irrelevant if I cannot use it in my environment.

In particular firecracker runs on bare metal or VMs that support nested virtualization, which unfortunately is not widely available in the clouds (and bare metal is expensive)

Re: Faster filesystem access with Directfs

#29

Post by Patrickmi » Fri, Jul 28, 2023, 8:36 AM UTC

nomel wrote: post #10

Patrickmi wrote: post #9

Am new to these kernel space but isn’t writes operation more security at risk than Reads if it is why not break gofer into 2 categories one writes, one reads embed the one with reads with sentry user space, this may not show any significant performance in real world use but it gets both benefits

> writes operation more security at risk than reads I think, in the context of security, this is like asking if it's worse to die by a car or die by a bus.

Lol at least one is recoverable

Re: Faster filesystem access with Directfs

#30

Post by topspin » Fri, Jul 28, 2023, 8:45 AM UTC

dilyevsky wrote: post #23

topspin wrote: post #19

Accessing local file systems from a container? What heresy is this? Containers must all be stateless webscale single-"process" microservices with no need of local file systems and other obsolescent concepts. Next thing you know someone will run as many as two whole "processes" in a container! Having dispensed with that bit of bitter sarcasm; solving their local filesystem performance/security problems is great and al…

In k8s that already exists via CSI[0] but kubelet is handling the setup/teardown signaling and it requires 3rd party provisioner daemon so higher level than container runtime (runsc in this case). [0] - https://kubernetes-csi.github.io/docs/

Yes. I know. K8s has delivered the moral equivalent of what we've had built-in to our OS kernels[1] since before some of the people reading this were born, and they've only had to add two layers of complexity, fragility and inscrutability on top of k8s itself, one of which is a third party dependency.

This is my excited face. :|

[1] 2005: https://lwn.net/Articles/131747/