fstrim: FITRIM ioctl failed: Bad file descriptor

English Install/Boot/Login
1 

# fstrim -v /win
fstrim: /win: FITRIM ioctl failed: Bad file descriptor

The mount options for this ntfs-3g partition are:


ro,noatime,permissions,uid=myusername,gid=users,fmask=177,dmask=077,locale=en_US.UTF-8,windows_names        0 0

What is the reason for trimming not to work? Other (ext4) partitions on this SSD drive trim fine.

2

1 was it mounted? I note you have nofail

  1. if NTFS is associated Windows set not to have fast boot?
3

Yes.

  1. if NTFS is associated Windows set not to have fast boot?

I don’t understand this sentence. Could you please clarify?

4

Couldn’t it be that fstrim has no idea what to do with a non-Linux file system like NTFS?

People seem to think that non-Linux file systems are supported by all tools as if they were Linux file systems.

While there is mount (including attaching fake ownership/permissions) and read/write support, I think you should be glad with that. Use those file systems only for exchanging data with non-Linux operating systems. All the rest, like creating and managing them should be done on the operating system they are native to.

5

Removed ‘ro’ option and now trim works.

I guess the question remains then: considering I noticed this message in journalctl first - why is Linux attempting to trim a ‘ro’ mount at all. Is that a bug?

6

Since trim is a low level block command I’d expect it to be file system agnostic.

Don’t know if ro fail is a bug but it could use a better error message.

I suspect if you set something ro you really expect it to be read only and fstrim definitely is a write operation

7

I agree. I have filed a bug report.

I also don’t know why there is an attempt to trim that partition at all. I have:


# cat /etc/cron.daily/trim
#!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG

but I have never set any trimming for that /win mount. Why does the system do it at all? As noted in the bug report I have noticed these attempts are with dates after updating to Leap 15.

8

Maybe it just follows the directory tree

9

If that was so it would show every day in the journal but that is not the case.

I have just received a reply in the bug report:

“There is fstrim.timer to be executed once a week.”

which I suppose may be something new to Leap 15. I checked:


grep -i "execstart" /usr/lib/systemd/system/fstrim.service
ExecStart=/usr/sbin/fstrim -av

‘-a’ means all. So this is what is calling it.

10

Hi
Been around for awhile (I see on Leap 42.3), just use to be a weekly cron job (well on btrfs because that’s what I use)…

11

Then how come it shows in my logs just after upgrading to Leap 15? This system was initially running 13.2 and upgraded when next versions were released.

12

Hi
Have no idea, never upgrade my openSUSE systems (Well, I do for SLES/SLED/Tumbleweed), it is the default now, maybe that’s why.