o.k bud,
maybe sequential writing the entire free area would make the drive perform better.
have you tried it?
slow write might be caused due to the controller trying to write into an already occupied area,
can't entirely figure why random write slow down the drive operation but apparently it happen,
try writing sequential to the entire free space available on the drive,
set IOMeter without any specified number of sectors and the test file should fill the entire free space, then you can run 1MB sequential write test with 100 percent access specification and 100 percent write and it should clear out all the mixed blocks,
run the test for 20-30 minutes.
your case is still a bit dazzling though.
E:
o.k, this explains it:
http://www.anandtech.com/show/2738/9
the spare space coming or being partitioned at the drive, fills up at some point,
so read modify write happens inevitably and so would slow down the drive,
this is only a temporary solution.
not sure how sequential write might change this scenario, maybe writing only 00 to it so the controller sees the NAND as empty (or maybe not, 00 still counts as data).
E2:
so what should/might happen with sequentially filling the entire free area is simply the controller would over-write it.
a used drive should have many blocks filled with random data, some of the pages are full while the other are empty.
when the controller would like to write a certain amount of data to the NAND, it has to read a portion, modify it and rewrite it, which takes time.
the OS sees deleted files as an unoccupied area, while the data is still actually there at the drive.
the controller have to write over this data, sending the file to different portions of the drive which takes time,
and lower the drive throughput.
now when the drive is filled with sequential pattern which is marked as delete, the controller can over-write this data at an instant and continuously, without searching for free pages or rather cut the file into to many small pieces and so - sending it all over the drive, a procedure which can take away some of the READ bandwidth as well.
so sequentially filling an already full drive
should make the controller work faster.
TRIM ofcourse is supposed to handle these deletes and free up space for the controller to use,
while the G1 and RAID'ed drives are using none, they're prone to suffer from these architectural caveats.
what means here, Intel *!
REALLY!* screwed the G1 buyers..
(and anand was even asking them through "The SSD-Anthology" to support TRIM with the G1's as a gesture (and an healthy marketing technique)..
hopefully it wasn't possible to allow TRIM for the G1's, or did it..?
..
anyhow,
anand seems to have kind of skipped a stage..