mpx (mpx@nomail.pl) on 1/26/11 wrote:
---------------------------
>iz (i@z.x) on 1/25/11 wrote:
>---------------------------
>> TRIM was introduced as a sort of panic reaction.
>
>Perhaps, as TRIM magically appeared soon after the reports of performance degradation were published.
>
>On the other hand you have to notice that the concept itself is very useful for
>consumer usage pattern. Eg. contemporary software can have 3 sets of files: downloaded
>form, unpacked and ready for installation form, final installed form. Two of them
>are deleted after use - a perfect scenario to show TRIM benefits. This includes things like patches etc.
>
>And if a software is a game that weights 8 GB, and has 12-90 hours of play, then
>gets uninstalled, then you have potentially 3x8GB of data created and deleted. Perhaps
>regularly, and with few days-weeks of rest time, when the SSD is mostly empty.

Yes, great, but if the FS just reuses the same 8GB disk space no fragmentation happens. Fragmentation only happens when previously deleted blocks get reused little by little. And if no fragmentation happens TRIM does nothing.

>There is also a case of temporary files, used frequently. Typical desktop software
>creates backup files for every file opened for editing. Various software can create
>temporary on-disk buffers. The biggest usage of temporary files may be hidden in
>certain scenarios of decompression programs - quite from 7-zip FAQ:
>
>"Why does drag-and-drop archive extraction from 7-Zip to Explorer use temp files?
>
>7-Zip doesn't know folder path of drop target. Only Windows Explorer knows exact
>drop target. And Windows Explorer needs files (drag source) as decompressed files
>on disk. So 7-Zip extracts files from archive to temp folder and then 7-Zip notifies
>Windows Explorer about paths of these temp files. Then Windows Explorer copies these
>files to drop target folder." (of course temp files are then deleted).

Any modern FS doesn't even write those temp files to disk, it all stays in ram. And the "move" can often be done with a rename. And when it can't, it's on another partition/disk, and we got the same situation as above. Even when it happens in a brain dead way, the same applies as above: If the FS uses the same blocks as before eveything works out fine in the end.