[haiku-bugs] Re: [Haiku] #10336: TRIM / fstrim can destroy data on SSD's when executed

  • From: "pulkomandy" <trac@xxxxxxxxxxxx>
  • Date: Sat, 07 Jan 2017 17:29:02 -0000

#10336: TRIM / fstrim can destroy data on SSD's when executed
----------------------------+----------------------------
   Reporter:  kallisti5     |      Owner:  axeld
       Type:  bug           |     Status:  in-progress
   Priority:  blocker       |  Milestone:  R1/beta1
  Component:  Drivers/Disk  |    Version:  R1/Development
 Resolution:                |   Keywords:  TRIM fstrim
 Blocked By:                |   Blocking:
Has a Patch:  0             |   Platform:  All
----------------------------+----------------------------

Comment (by pulkomandy):

 I tried various things:
 - Always send only 1 range: same timeout
 - Reduce all ranges to only 1 sector: same timeout

 I noticed that the command expects a number of "range blocks" to trim (a
 block is 512 byte, or 64 entries of 8 byte each). For the last command we
 send, there are less than 64 entries, and we send a shorter command block.
 Does that work? Or should we round the buffer to the next multiple of 512
 bytes and fill it with zero? the spec says that unused entries in a block
 should have their "range" field set to 0. I'm wondering if this could
 cause the disk to interpret random data at the end of the buffer as trim
 commands, which would lead to erasing random areas of the disk.

 But first, I need to understand why the command timeouts, even with small
 ranges. I do saw some disk sectors turning into 0xFF, so it is at least
 partially working.

--
Ticket URL: <https://dev.haiku-os.org/ticket/10336#comment:25>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: