On Sun, Jul 05, 2020 at 04:46:04AM +0200, Jan Ziak wrote:
On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox willy@infradead.org wrote:
On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
Hello
At first, I thought that the proposed system call is capable of reading *multiple* small files using a single system call - which would help increase HDD/SSD queue utilization and increase IOPS (I/O operations per second) - but that isn't the case and the proposed system call can read just a single file.
Without the ability to read multiple small files using a single system call, it is impossible to increase IOPS (unless an application is using multiple reader threads or somehow instructs the kernel to prefetch multiple files into memory).
What API would you use for this?
ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens);
I pretty much hate this interface, so I hope you have something better in mind.
I am proposing the following:
struct readfile_t { int dirfd; const char *pathname; void *buf; size_t count; int flags; ssize_t retval; // set by kernel int reserved; // not used by kernel };
int readfiles(struct readfile_t *requests, size_t count);
Returns zero if all requests succeeded, otherwise the returned value is non-zero (glibc wrapper: -1) and user-space is expected to check which requests have succeeded and which have failed. retval in readfile_t is set to what the single-file readfile syscall would return if it was called with the contents of the corresponding readfile_t struct.
You should probably take a look at io_uring. That has the level of complexity of this proposal and supports open/read/close along with many other opcodes.