FSTRIM fails

[gstreeter]

Issue after updating to 3.10.18+ #590
FSTRIM -v / fails with "FITRIM ioctl failed: Operation not supported"

Worked ok in previous 3.10.18 updates.

SDCard is SanDisk Ultra 8GB class 10

[popcornmix]

I don't see how that will have changed with last update. Can you let me know the most recent kernel that worked?
You can get older firmware with:

sudo rpi-update <git hash>

and you can get the hashes from here:
https://github.com/Hexxeh/rpi-firmware/commits/master

[ghollingworth]

FSTRIM is not supported by SD cards therefore it failing is a good thing...

Previous updates were clearly incorrect and someone has fixed it more like

[gstreeter]

Interest... I've been using it every day since I got my Pis over a year ago :-) It reports to be doing something with "-v" as it prints out a figure for the bytes trimmed and then zero if it's run again immediately.

[ghollingworth]

Yes it pretends to do something but can't sd cards do not support trim.

That is why I guess it's been fixed...

On 12 Nov 2013, at 22:44, "Gary Streeter" <notifications@git.luolix.topmailto:notifications@github.com> wrote:

Interest... I've been using it every day since I got my Pis over a year ago :-) It reports to be doing something with "-v" as it prints out a figure for the bytes trimmed and then zero if it's run again immediately.

Reply to this email directly or view it on GitHubhttps://github.com//issues/431#issuecomment-28341529.

[fedeaf]

I'm finding the same issue with Linux raspberrypi 3.10.22+ #606.

@ghollingworth on sdcards TRIM is not supported, so fstrim should use the ERASE command instead. Then is up to the wearleveling to realize that an erased block is actually free.

[ghollingworth]

Although that's a complete waste of time on all SD cards because they already handle this by keeping 10% of the card available for wear levelling. The only possible advantage to doing this is reduction in erasing time, but since you've normally got something like 400MByte of erased blocks just waiting around the be used you'd think this doesn't really make any difference either

Unfortunately I still don't have an SD card that supports erasing but complains when you do fstrim on it to debug the problem

Gordon

From: fedef <notifications@git.luolix.topmailto:notifications@github.com>
Reply-To: raspberrypi/linux <reply@reply.git.luolix.topmailto:reply@reply.github.com>
Date: Sunday, 8 December 2013 13:39
To: raspberrypi/linux <linux@noreply.git.luolix.topmailto:linux@noreply.github.com>
Cc: Gordon Hollingworth <gordon@raspberrypi.orgmailto:gordon@raspberrypi.org>
Subject: Re: [linux] FSTRIM fails (#431)

I'm finding the same issue with Linux raspberrypi 3.10.22+ #606.

@ghollingworthhttps://github.com/ghollingworth on sdcards TRIM is not supported, so fstrim should use the ERASE command instead. Then is up to the wearleveling to realize that an erased block is actually free.

Reply to this email directly or view it on GitHubhttps://github.com//issues/431#issuecomment-30081724.

[ghost]

Yes it pretends to do something but can't sd cards do not support trim.

SD cards support "TRIM", which is actually called ERASE in the mmc/sd world.
The driver has a capability flag named "MMC_CAP_ERASE" where it can specify whether it supports the EREASE command or not.

Although that's a complete waste of time on all SD cards because
they already handle this by keeping 10% of the card available for wear levelling.

SD cards might have a tiny bit of over-provisioning (although I doubt it's 10% when even many SSDs only have 7%), but their controllers are a lot worse.
Most SD cards only do dynamic wear leveling, which means only wear leveling to blocks which are currently written to. This is one of the reason why SD cards in the PI tend to die so quickly / develop bad blocks exactly where ext4 places its journal.

[ghollingworth]

I'll remember to tell the SD card manufacturer's that they do not know what they're talking about the next time they're in the office

Buy the official Raspberry Pi SD card, it's not only the cheapest on the market but also pretty much the fastest card for the Raspberry Pi. If you succeed in trashing one of those then I'd be interested in seeing it.

Raspbian has journalling turned off to avoid trashing the card

[ghost]

As the raspberry pi sd cards are re-labeled samsung cards, I'll probably buy a samsung one as I don't want to cause warranty replacement costs for the foundation ^^

The question why fstrim worked previously and now fails still remains ....

[ghollingworth]

If you buy standard Samsung one's you'll end up with something made to work in a camera which is not then optimised for the Raspberry Pi. The point of the Raspberry Pi SD card is that it was specifically developed and tuned to work with the Raspberry Pi!

[ghost]

Raspbian has journalling turned off to avoid trashing the card

At least not on my installation, which is based on the official 12.2013 image:

Filesystem features: has_journal
ext_attr resize_inode dir_index filetype extent flex_bg
sparse_super large_file uninit_bg dir_nlink extra_isize

It also matches the location of bad blocks I saw on that 32gb microSD, a few megabytes aftre the partition start.

[fedeaf]

@popcornmix You might want to close this issue as it is now resolved on the new versions of Raspbian + firmware.
(I'm really not sure at what point it was fixed.)

[popcornmix]

Okay, thanks for update.