* Francisco Ares <fra...@gmail.com> [150730 15:53]:
[..SNIP..}
> Flash memory devices are tricky when you try do defrag, as there is extra
> logic inside them to do the opposite: spread as much data as possible, as
> to equalize the number of write operations - the main limit for flash
> memory - for all sectors.
> 
> Most defrag tools do this by reading files to RAM, reordering them, erasing
> the originals from the media, then writing them again, using no direct
> sector access, leaving that to the operating system. And it works on
> magnetic media, as it creates empty spaces suitable for continuous files.
> 
> So that extra logic may fool you, making you believe it worked, when it
> didn't.
> 
> Considering this, as already said, I would copy everything to another
> media, set up a new partition layout, format the new partitions as desired,
> then get all data back to the new layout.
> 
> Just my 2 cents, of course.
> 
> Good luck
> Francisco

I don't believe this is right (though I've been wrong before.)

Both partitions and filesystems (including defragging filesystems)
operate at the block level.

Wear leveling and bad block handling happen "below" the block level.

If you gave flash memory data for block n and later tried to read block
n and got back something different it would be very broken.

Of course physically logical block n might actually be stored in
physical block y, but the flash controller (or whatever is responsible
for wear leveling and bad block mapping) still needs to know to give
back the data from physical block y when it's asked for logical block n.

Todd

Reply via email to