Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Defrag
- Thread starter skinnyk42
- Start date
- Sort by reaction score
The performance benefit of defragmenting a hard drive comes mostly from minimizing the time it takes to reposition the read heads as file(s) are accessed from several different physical portions of the disc platter. That's not really an issue with an iPhone's Flash storage since it has no moving parts.
There is a small performance boost when reading from consecutive cells in a NAND Flash chip because generally the controller doesn't have to set up a new address for each byte being read within a single burst. However, the total performance difference you'd get from that is probably negligible with the typical usage you'd see on an iPhone.
Full OS X usually runs on the Journaled file system which is self-defragging, as mentioned above SSDs don't need defragging, hence why you don't use Journaled if you've got an SSD in your laptop - the iPhone will be exactly the same; defragging would do no good at all.
If we were really talking about a storage medium that was addressed for reading through a similar mechanism as conventional RAM, that would be totally correct. But in general, NAND Flash is not actually addressed in a random-access manner.
If you're in the middle of a bulk transfer from NAND Flash and you're just about to read byte N, it will be marginally faster to read byte N+1 next, than it would be to read any other byte in the chip, due to the way in which NAND Flash is addressed. But the effect is so small it's usually negligible.
Is that because it reads in 64-bit chunks? But then these things are block, not byte, addressed right? So assuming the blocks are 64-bit aligned, there would be no difference what order you read them in.
NAND Flash always performs all read operations in chunks of a whole page (typically at least 512 bytes) at a time. The whole page has to be read at once because it is fairly common for a small but usually correctable amount of corruption to be present in any data that is read, and the ECC signature (or similar) of the entire page is computed to identify any corruption and correct the data before any of it can be used.
We might be getting a little too technical here, but essentially it boils down to the fact that inside the chip, NAND Flash arrays are addressed serially rather than in parallel.
To start reading from NAND Flash, the memory controller is essentially provided a starting address, and then it starts clocking out data. As long as you keep on feeding the memory a sustained clock, subsequent sequential data will continue to be read out. While one page of data is being fed out of the chip sequentially, the next page of data typically can be simultaneously fetched from Flash for ECC computations.
If you ever want to stop reading from one sequential set of data and move on to a different location, you have to stop feeding clocks in and send the controller a new starting address.
All in all, to the outside world, a NAND Flash array looks much more like a hard drive than it does conventional RAM or ROM.
1. It's using HFS+ like your Macintosh, not FAT32 or NTFS like Windows, so it doesn't defragment as badly.
2. It uses Flash memory. Flash memory doesn't work like a hard drive. It doesn't matter much whether it is defragmented or not.
