fstrim

Is it using a file system that doesn't support fstrim?

No. It is a plain download of the Raspbian image. It uses ext4 as always.

This is a Debian bug. Turns out the Debian kernel package managers are idiots and didn't build the ext4 module with FITRIM support. It's not fixed in Sid either, I'm running it on my laptop and just tested fstrim. I wouldn't worry about it either way, sheer unreliability will kill most SD cards long before fstrim would start extending the life of the media.

It must be recently introduced then? I have several Raspberries running and none of them show this problem. However, this is the first one that I installed myself from a Raspbian image I downloaded.

I?m skeptical about that explanation, since: (i) the ext4 FITRIM implementation is not conditional (ii) the error code corresponds to the underlying block device lacking discard support (unimplemented ioctls yield EINVAL) (iii) it works perfectly well when I try it on a device that does support ATA TRIM (iv) Ben?s really not an idiot

Perhaps you?d care to quote the bug number.

I wonder if that's it. Were all SD cards accessed through the native Pi SD slot? The SD card protocol does support explicit erase operations and it appears the Linux MMC driver does use that for TRIM.

Questions: are we talking the same card here? Some cards handle erase in nonstandard ways which might not be supported. And were any used in a USB reader? Many USB readers don't support erases (I'm not sure if the USB Mass Storage standard implements them - SCSI does, but I think it's a recent addition).

Theo

The card is in the standard slot of a Pi. It is a Transcend SDHC 16GB class-10 card.

I have another one of those cards, I will see if that has the same problem. Did others see this problem with that card?

I'm certain that the similarly labeled 4GB card does not have this problem.

So it turns out I'm an idiot and I was attempting to run fstrim on rotational storage. Never mind.