gekkofs issueshttps://storage.bsc.es/gitlab/hpc/gekkofs/-/issues2024-03-05T13:44:20+01:00https://storage.bsc.es/gitlab/hpc/gekkofs/-/issues/281Refactor path resolution2024-03-05T13:44:20+01:00Marc VefRefactor path resolutionCurrently, path resolution is using `lstat()` to ensure that each path component exists. This can add unnecessary overhead, especially when the mount point is located under a long path within a parallel file system like Lustre.
The requ...Currently, path resolution is using `lstat()` to ensure that each path component exists. This can add unnecessary overhead, especially when the mount point is located under a long path within a parallel file system like Lustre.
The requirements for path checking:
1. Detect paths within GekkoFS and pass them (without prefix) to GekkoFS
2. No system calls for checking of path component existence.
3. When a path is not within GekkoFS, the *unmodified* path is passed to the kernel, except a GekkoFS path is part of the path which must be removed first.
Therefore, the following features/changes are necessary:
- A prefix is a defined as the absolute path to the GekkoFS mountpoint. E.g., for `/tmp/gkfs_mount/foofile` the prefix is `/tmp/gkfs_mount`.
- No system call like `lstat()` should be called
- Path checking is done by prefix matching. Therefore a non-absolute path first needs to be resolved:
- if the middle of the path uses `..`, the path needs to be resolved for prefix checking (similar to now)
- relative paths (based on the current working directory) also need to be resolved for prefix checking
- If a path is not within GekkoFS, the path should be passed to the kernel unmodified.
- When part of the GekkoFS namespace is in the middle of a path and then undone via `..`, the path needs to be resolved before passing it to the kernel as the kernel is unaware of GekkoFS
- This also applies to relative paths
- If a path is within GekkoFS, the prefix is cut from the path and passed to GekkoFS.
Part of these improvements are included but unfinished in [this branch](https://storage.bsc.es/gitlab/hpc/gekkofs/-/tree/marc/100-client-fails-when-mountdir-does-not-exist-on-underlying-fs)v0.9.3Julius AthenstaedtJulius Athenstaedthttps://storage.bsc.es/gitlab/hpc/gekkofs/-/issues/280Hooks narrow cast types2024-02-19T09:43:00+01:00Marc VefHooks narrow cast typesCurrently, our client hooks return whatever syscall intercept returns. This is usually a cast from `long` to `int`. This is a narrowing operation and therefore we should us `narrow_cast` from gsl to make clear that this is acceptable (we...Currently, our client hooks return whatever syscall intercept returns. This is usually a cast from `long` to `int`. This is a narrowing operation and therefore we should us `narrow_cast` from gsl to make clear that this is acceptable (we do not need an exception in this case). See here https://github.com/microsoft/GSL/blob/main/docs/headers.md#user-content-H-util-narrow_cast
This issue includes adding GSL to GekkoFS and adding `gsl::narrow_cast` to all hooks that narrow.v0.9.3Julius AthenstaedtJulius Athenstaedthttps://storage.bsc.es/gitlab/hpc/gekkofs/-/issues/267Syscall intercept vs dynamic rewriting2023-10-09T12:16:10+02:00Ramon NouSyscall intercept vs dynamic rewritingWhile going through syscall_intercept I realised that the project has been moved to another maintainer (Intel discontinued support).
There are some updates with clone3 (we should incorporate them).
On other hand, Reading this paper (htt...While going through syscall_intercept I realised that the project has been moved to another maintainer (Intel discontinued support).
There are some updates with clone3 (we should incorporate them).
On other hand, Reading this paper (https://d-nb.info/1260458342/34) I was thinking about going to a dynamic rewrite solution.
https://github.com/srg-imperial/sabre
<details><summary>Sycall Intercept vs SaBRE</summary>
syscall_intercept comes with some important limitations.
First, syscall_intercept does not support the clone syscall
and thus multithreaded applications are out of scope. Indeed,
we observed instant crashes in all of our server benchmarks
except Lighttpd. Second, syscall_intercept only rewrites
syscalls inside the libc library and thus other syscalls might
be ignored. Lighttpd depends on libraries that have additional
system calls, for example librt. Syscalls in libraries outside of libc are common: In a quick scan on our Ubuntu
system, we found that 20% of system libraries issue syscalls.
In our Lighttpd benchmark, we avoid triggering system
calls outside of libc in order to compare the two systems
fairly. syscall_intercept showed a +7% overhead compared
to +0.9% of SaBRe. In terms of load time, syscall_intercept
showed a 230.35 ms overhead compared to 64.4 ms for
SaBRe.
Inspection of the syscall_intercept code base revealed
some contributing factors to the observed performance
overhead. The trampolines leading to the user-provided
interception routine perform additional unnecessary work
compared to SaBRe, such as saving and restoring registers
used by SIMD instructions (which we think would be better done as part of the user-provided handler when needed),
as well as doing unavoidable additional checks related to
syscall_intercept’s implementation of logging. Furthermore SaBRe employs a more optimised trampoline system using
only two jumps to get to the user-provided system call handler as opposed to syscall_intercept which uses three or four
jumps to get to the user-provided system call handler.
We also note that syscall_intercept is initialised during
early runtime, while SaBRe is initialised during load time
and thus can intercept a larger set of functionality, e.g. the
loader itself and libraries that come before syscall_intercept
in .init and .preinit.
</details>futurehttps://storage.bsc.es/gitlab/hpc/gekkofs/-/issues/128Add a circular buffer for client logging messages2020-10-19T15:04:03+02:00Alberto MirandaAdd a circular buffer for client logging messagesDue to the peculiarities of the system call interception process, the logging framework in the client can only rely on using direct calls to the `write()` system call using `syscall_no_intercept()` to avoid reentrancy. Unfortunately, thi...Due to the peculiarities of the system call interception process, the logging framework in the client can only rely on using direct calls to the `write()` system call using `syscall_no_intercept()` to avoid reentrancy. Unfortunately, this causes a huge slowdown since `write()` is synchronous in nature. To avoid this, a circular buffer could be introduced to temporarily store formatted messages. Such buffer would be emptied by an additional dedicated thread spawned for such a purpose. The point of the circular buffer would be to overwrite old messages if capacity is exceeded.v1.0.0https://storage.bsc.es/gitlab/hpc/gekkofs/-/issues/96Full interception of bash 4.3.48 crashes2020-03-20T10:03:52+01:00Alberto MirandaFull interception of bash 4.3.48 crashesWhile testing the new harness in !33 in a docker image with Ubuntu Xenial, bash 4.3.48(1)-release (x86_64-pc-linux-gnu) and Python 3.6, I came across the following error with one of the `shell` tests:
```bash
malloc: unknown:0: assertio...While testing the new harness in !33 in a docker image with Ubuntu Xenial, bash 4.3.48(1)-release (x86_64-pc-linux-gnu) and Python 3.6, I came across the following error with one of the `shell` tests:
```bash
malloc: unknown:0: assertion botched
free: called with unallocated block argument
Aborting...
```
I have come across this bug before while doing `LD_PRELOAD=libgkfs_intercept.so /bin/bash` in my old laptop with Ubuntu 14.04, but it disappear once I migrated to my new one with Ubuntu 19.04. Thus, I suspect it is related to interception in older versions of `bash`.