#10336: TRIM / fstrim can destroy data on SSD's when executed
---------------------------+----------------------------
Reporter: kallisti5 | Owner: axeld
Type: bug | Status: in-progress
Priority: high | Milestone: Unscheduled
Component: Drivers/Disk | Version: R1/Development
Resolution: | Keywords: TRIM fstrim
Blocked By: | Blocking:
Platform: All |
---------------------------+----------------------------
Comment (by pulkomandy):
Hi,
Today I added support to the SD/MMC driver. I did a test on a mostly empty
BFS filesystem on my SD card (which explains the rather large areas being
trimmed, and there are few of them).
Here is the log of trimming:
{{{
KERN: TRIM FS:
KERN: [ 0] 8884224 : 1064857600
KERN: [ 1] 1073745920 : 1073737728
KERN: [ 2] 2147487744 : 1623191552
KERN: mmc_disk: trim_device()
KERN: mmc_disk: trim 1064857600 bytes from 8884224
KERN: sdhci_pci: ExecuteCommand(32, 43c8)
KERN: sdhci_pci: ExecuteCommand(33, 200000)
KERN: sdhci_pci: ExecuteCommand(38, 1)
KERN: mmc_disk: trim 1073737728 bytes from 1073745920
KERN: sdhci_pci: ExecuteCommand(32, 200008)
KERN: sdhci_pci: ExecuteCommand(33, 400000)
KERN: sdhci_pci: ExecuteCommand(38, 1)
KERN: mmc_disk: trim 1623191552 bytes from 2147487744
KERN: sdhci_pci: ExecuteCommand(32, 400008)
KERN: sdhci_pci: ExecuteCommand(33, 706000)
KERN: sdhci_pci: ExecuteCommand(38, 1)
}}}
And here is the log of trying to unmount then remount the partition:
{{{
KERN: sdhci_pci: Read 1024 bytes at 4194304
KERN: sdhci_pci: ExecuteCommand(18, 2000)
KERN: sdhci_pci: Read 4096 bytes at 4196352
KERN: sdhci_pci: ExecuteCommand(18, 2004)
KERN: sdhci_pci: Read 4096 bytes at 4200448
KERN: sdhci_pci: ExecuteCommand(18, 200c)
KERN: sdhci_pci: Read 2048 bytes at 1077936128 ***
KERN: sdhci_pci: ExecuteCommand(18, 202000)
bfs: KERN: inode at block 524288 corrupt!
sdhci_pci: Read 4096 bytes at 4204544
sdhci_pci: ExecuteCommand(18, 2014)
bfs: KERN: could not create root node!
}}}
I have annotated a line with {{{***}}}. As you can see, BFS tries to read
at an offset that was erased by the trimming. So it looks like there
indeed is a problem in the BFS code or in the partitionning system manager
(which I understand should translate BFS requests into offsets on the raw
disk). The trimming seems to have worked: the data is no longer there, and
BFS fails to mount the partition.
I will make tests with smaller partitions to see if I can more easily
analyze what's going on.
--
Ticket URL: <https://dev.haiku-os.org/ticket/10336#comment:58>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
