On 04/26 09:58, Rich Freeman wrote: > On Sun, Apr 26, 2020 at 9:43 PM <tu...@posteo.de> wrote: > > > > To implement a dry run with a printf() is new to me... ;) > > > > That is all they fstrim authors could do, since there is no dry-run > option for the actual ioctl, and fstrim itself has no idea how the > filesystem will implement it (short of re-implementing numerous > filesystems in the program and running it on unmounted devices). It > seems like an fstrim dry-run is only minimally functional, though I > guess it will test if you made any gross errors in syntax and so on. > I don't see any reason why they couldn't have a dry-run option for the > ioctl, but it would have to be implemented in the various filesystems. > Really it seems like ioctl in general in the kernel isn't > super-well-documented. It isn't like the system call interface. That > is, unless I just missed some ioctl document floating around. The > actual list of ioctls is in the kernel includes, but this does not > define the syntax of the 3rd parameter of the ioctl system call which > is function-specific. The structure used by the FITRIM ioctl is in the > includes, but not with any kind of documentation or even a > cross-reference to associate the structure with the ioctl itself. > > -- > Rich >
Hi Rich, thanks for the explanations again. But I think it is better not to implement a feature at all as via printf. For a dry run I had expected, that some checks had been implemented, whether a non-dry run would be successfull. For example: When submitting fstrim -n / as normal user I get: /: 0 B (dry run) trimmed Doing the same without dry run set I get: fstrim: /: FITRIM ioctl failed: Operation not permitted When doing a fstrim -n /home/user as normal user, I get the same behaviour as above -- despite that /home/user is on a harddisk with no fstrim functionality at all. If fstrim cannot implement the above correctlu, it would be better not to implement it all...I think. Cheers! Meino
