1 |
On Sun, Apr 26, 2020 at 9:43 PM <tuxic@××××××.de> wrote: |
2 |
> |
3 |
> To implement a dry run with a printf() is new to me... ;) |
4 |
> |
5 |
|
6 |
That is all they fstrim authors could do, since there is no dry-run |
7 |
option for the actual ioctl, and fstrim itself has no idea how the |
8 |
filesystem will implement it (short of re-implementing numerous |
9 |
filesystems in the program and running it on unmounted devices). It |
10 |
seems like an fstrim dry-run is only minimally functional, though I |
11 |
guess it will test if you made any gross errors in syntax and so on. |
12 |
I don't see any reason why they couldn't have a dry-run option for the |
13 |
ioctl, but it would have to be implemented in the various filesystems. |
14 |
Really it seems like ioctl in general in the kernel isn't |
15 |
super-well-documented. It isn't like the system call interface. That |
16 |
is, unless I just missed some ioctl document floating around. The |
17 |
actual list of ioctls is in the kernel includes, but this does not |
18 |
define the syntax of the 3rd parameter of the ioctl system call which |
19 |
is function-specific. The structure used by the FITRIM ioctl is in the |
20 |
includes, but not with any kind of documentation or even a |
21 |
cross-reference to associate the structure with the ioctl itself. |
22 |
|
23 |
-- |
24 |
Rich |