mkfs.btrfs vs fstrim on an SD Card (not SSD)

mkfs.btrfs vs fstrim on an SD Card (not SSD)

[Chris Murphy]

Short version:
When I mkfs.btrfs either an SD Card or an SSD, I get a response back to the effect the whole device specified is trimmed. However, when I use fstrim on an SD Card, I get an error that trim isn't supported. So I'm wondering if anyone knows the difference between how fstrim is trimming, and how mkfs.btrfs is trimming. 

Long version:
It does seem like the mkfs.btrfs one has worked because using dd to read an LBA with known information returns zeros after mkfs.

And then I found the SD Card association has their own formatting tool for Windows and OS X, with the warning "Using generic formatting utilities may result in less than optimal performance for your memory cards."
https://www.sdcard.org/downloads/formatter_4/

So I downloaded the Physical Layer Simplified Specification Version 4.10 spec, and on page 38 it describes an erase command.

4.3.5 Erase
It is desirable to erase many write blocks simultaneously in order to enhance the data throughput. Identification of these write blocks is accomplished with the ERASE_WR_BLK_START (CMD32), ERASE_WR_BLK_END (CMD33) commands.
The host should adhere to the following command sequence: ERASE_WR_BLK_START, ERASE_WR_BLK_END and ERASE (CMD38).

So I'm going to guess that mkfs.btrfs is leveraging something that ends up using these SD Card specific commands on SD Cards, but mkfs.btfs itself isn't aware of this distinction. Whereas fstrim is maybe using something else?

Chris Murphy

Re: mkfs.btrfs vs fstrim on an SD Card (not SSD)

[Chris Murphy]

I may have answered my own question using strace. And for whatever reason this time fstrim worked.

fstrim
ioctl(3, FITRIM, 0x7fffbf6b87e0) 
…
write(1, "/mnt/: 13.9 MiB (14598144 bytes)"…, 41/mnt/: 13.9 MiB (14598144 bytes) trimmed

Clearly this is only erasing what the file system is aware of having been recently deleted, even though it's a bit off as I'd just deleted a 6.1MB file.



mkfs.btrs:

ioctl(3, BLKGETSIZE64, 14729330176)     = 0
ioctl(3, BLKDISCARD, {0, 7fff920ee4a0}) = 0
write(2, "Performing full device TRIM (13."..., 43Performing full device TRIM (13.72GiB) ...
) = 43
ioctl(3, BLKDISCARD, {0, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {40000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {80000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {c0000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {100000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {140000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {180000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {1c0000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {200000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {240000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {280000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {2c0000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {300000000, 7fff920ee4a0}) = 0
ioctl(3, BLKDISCARD, {340000000, 7fff920ee4a0}) = 0

And this blew away everything on that partition.

Since the SD Card spec references a completely different command than the ATA spec (TRIM), I don't think either one of these are TRIM, even if functionally equivalent. Instead the SD Card ERASE_* commands are probably being used, but I can't confirm this because writes to /dev/mmcblk0 aren't showing up with:

echo scsi:scsi_dispatch_cmd_start > /sys/kernel/debug/tracing/set_event 
echo 1 > /sys/kernel/debug/tracing/tracing_on
cat /sys/kernel/debug/tracing/trace_pipe


Chris Murphy

Re: mkfs.btrfs vs fstrim on an SD Card (not SSD)

[Martin K. Petersen]

>>>>> "Chris" == Chris Murphy <lists@colorremedies.com> writes:

Chris> Since the SD Card spec references a completely different command
Chris> than the ATA spec (TRIM), I don't think either one of these are
Chris> TRIM, even if functionally equivalent. Instead the SD Card
Chris> ERASE_* commands are probably being used,

Indeed. Discard is our generic block layer abstraction that gets
translated into whichever command is appropriate for the device in
question (ACS DSM TRIM, SBC WRITE SAME/UNMAP, etc.).

Chris> but I can't confirm this because writes to /dev/mmcblk0 aren't
Chris> showing up with:

Chris> echo scsi:scsi_dispatch_cmd_start >
Chris> /sys/kernel/debug/tracing/set_event echo 1 >
Chris> /sys/kernel/debug/tracing/tracing_on cat
Chris> /sys/kernel/debug/tracing/trace_pipe

MMC doesn't go through SCSI like ATA does. 

-- 
Martin K. Petersen	Oracle Linux Engineering