#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):
So I dug a bit further into this...
I looked at the bfs code and confirmed that it uses read_pos and write_pos
to access the partition expecting that the partition device will do the
translation. For example, reading at offset 0 gets the superblock.
I then checked where this translation is done. It appears to be in
src/kernel/device_manager/devfs.cpp using the translate_partition_access.
However, this translation is currently not done for the B_TRIM_DEVICE
ioctl. As a result, the trim is executed using the start of the disk as a
reference point, instead of the start of the partition. And, quite
possibly, one ends up erasing the partition table, or in general, things
that should not have been erased.
This also explains why I had no problems when testing with the ramdisk: I
had not created a partition table there, and the offset between the
filesystem and the disk did, in fact, match. I suspect when Axel tested on
virtualbox, he used a similar setup?
--
Ticket URL: <https://dev.haiku-os.org/ticket/10336#comment:59>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
