Defragmenting Memory card

[stiffler]

Lolz i thought this an year before... n i ended up loosing all my information
I got all my games deleted I don't knw y but this is what happened to my card
Defragmenting only helps in pc not much in cellphones

[Viper89]

& do u know how to make a corrupted mmc working?
i hve 2 gb mmc for rokr but it gets corrupted in 3-4 months.
i really wanna use that.

How corrupt is ur memory card ?

Have you really measured a performance gain after "defragmenting"???

I really dont see how this could increase performance, TF/SD cards are SSDs, and dont have access delays for random reads like Hard Drives do. There are no moving parts, you dont need to have a "head" to seek for the start of the block like on Hard _Disks_.

Also, by defragmenting your TF/SD card you will cause a lot of block erases (needed before write), and all erases will wear out your card, so defragmenting will in fact make your card die earlier.

I totally agree Deragmenting has no use in the E6, maybe with phone that carry 8gb, 16b memory card but not in 2gb,

[swifty]

I totally agree Deragmenting has no use in the E6, maybe with phone that carry 8gb, 16b memory card but not in 2gb,

It has nothing todo with the size of the card. Defragmentation is only for hard disks.
It is for NO use on flash memory cards.
wyrm is right!

/me in the process to replace the harddisk from my laptop with flash cards

[wyrm]

/me in the process to replace the harddisk from my laptop with flash cards

Nice! This greatly improves performance and battery life
Now, you have to pick the right SSDs, random small write(< 1 erase block) speed is the slowest operation and major factor when deciding for a branch, take a look at this blog post, it may help you to decide.. The author is very respected.

Linus' blog: .. so I got one of the new Intel SSD's

[Viper89]

It has nothing todo with the size of the card. Defragmentation is only for hard disks.
It is for NO use on flash memory cards.
wyrm is right!

/me in the process to replace the harddisk from my laptop with flash cards

I never said he wasn't right? Yes u are right, I was thinking of something different and it came out wrong

[xetaman]

It's debatable that there is not performance gain at all. Moving parts are not there; given.

But the access time should theoritically change if say
1. 1gig of data is all in a continuous stream
2. 1gig of data is strewn across the whole card in 200kb pieces. There still needs to be a resolution of the address of the next 200kb part, over 5000 times. All that logic takes time.

Hope i'm making sense.

[Shafii]

yes its not gonna increase d speed but its just help in optimizing...

[wyrm]

It's debatable that there is not performance gain at all. Moving parts are not there; given.

But the access time should theoritically change if say
1. 1gig of data is all in a continuous stream
2. 1gig of data is strewn across the whole card in 200kb pieces. There still needs to be a resolution of the address of the next 200kb part, over 5000 times. All that logic takes time.

Hope i'm making sense.

no, you are not

Specifically in the case of TF/SD cards, where the card does wear levelling on hardware, "continuous" is not continuous at all.

Also, with FAT filesystem, access is per block, not per stream, makes no difference if the data is contiguous, you will still read (file_size/block_size) blocks.

Anyway, you can test this yourself, mount a FAT filesystem with syncronous access (to disable fs cache), and:

#change /tmp to your card mount point
#create a contiguous file
dd if=/dev/zero bs=1k count=1048572 of=/tmp/foo
#measure reading time
time dd=/tmp/foo of=/dev/null
rm -f /tmp/foo
#create a _very_ fragmented file
dd if=/dev/zero bs=1k count=1048572 of=/tmp/foo &
dd if=/dev/zero bs=1k count=1048572 of=/tmp/bar
#measure reading time
time dd=/tmp/foo of=/dev/null
rm -f /tmp/foo /tmp/bar

[xetaman]

no, you are not

Specifically in the case of TF/SD cards, where the card does wear levelling on hardware, "continuous" is not continuous at all.

Also, with FAT filesystem, access is per block, not per stream, makes no difference if the data is contiguous, you will still read (file_size/block_size) blocks.

Anyway, you can test this yourself, mount a FAT filesystem with syncronous access (to disable fs cache), and:

#change /tmp to your card mount point
#create a contiguous file
dd if=/dev/zero bs=1k count=1048572 of=/tmp/foo
#measure reading time
time dd=/tmp/foo of=/dev/null
rm -f /tmp/foo
#create a _very_ fragmented file
dd if=/dev/zero bs=1k count=1048572 of=/tmp/foo &
dd if=/dev/zero bs=1k count=1048572 of=/tmp/bar
#measure reading time
time dd=/tmp/foo of=/dev/null
rm -f /tmp/foo /tmp/bar

I get what your are saying and it makes sense. But you are not considering the logic calculation bit. That the same number of blocks have to be read is given. It is the calculation of the address of those respective blocks that i'm talking about.

In the case of a stream, it's always the next block. In the case of fragmented data, there is a pointer somewhere (either at the end of that block, or in a address table, fat, i guess), which needs to be referred and the destination calculated. This is what i think takes more time.

[motomaster]

This should help.

Should I defrag my memory cards? - MobileRead Forums

How do I defragment my Pocket PC memory cards? Do I need this at all? | Smartphone & Pocket PC magazine