:fill(white):strip_exif()/i/2005309846.jpeg?f=thumbmini)
Extra over Perfect Disk 12 SSD optimization:
white paper:
http://www.raxco.com/user..._drives_ssds_6_1_2011.pdf
--------------------------
Antwoord van een medewerker van Raxco no 1:
The SSD optimization pass identifies the largest consolidated free space chunk already existing on your SSD and grows it. This results in a larger consolidated free space chunk on the volume - but the primary reason for doing so is to maximize the number of blocks which can be trimmed by the OS or the device. This is increases the effectiveness of garbage collection. (TRIM)
Edit: I want to make clear here that while the pass effectively increases free space consolidation - it should not be confused with our normal free space consolidation pass since that pass defragments files and creates a large free space gap at the end of the drive. The SSD optimization pass does not defragment files and it does not consolidate free space at the end of the drive, instead it grows the largest existing gap on the volume. The two should not be confused.
The pass is designed to do this without creating excessive erase/write cycles - and this is evidenced by how quickly this optimization pass runs. Our SSD optimization pass won't have your SSD churning through data and can be run as often as you like.
----------------
Antwoord van een medewerker van Raxco no 2:
Growing free space:
By moving out data into blocks that are not full. This quickly eliminates as many partially full blocks as possible. This is done using a one shot method, so there is no use of swap space (no churn). The result is a marked increase in the number of blocks which can be trimmed in exchange for incurring a single read/write cycle for a very small number of partially full blocks. If there are any free blocks that can be used to relocate data, those are used instead since this is both faster (no read/write cycle), and aids wear leveling a bit by not writing to a previously written to block. How we determine which blocks to target and how we target them is strictly proprietary.
Of course, this is a very simplistic description of the rules that govern the behavior of the algorithm because the behavior described operates within the context of growing out the largest consolidated free space chunk and not wholly consolidating all free space. Thus, no defragmentation of either free space or files is performed. This is why the primary action is referred to as "growing" free space. Also not to be confused with "freeing up" or "recovering" free space.
This eliminates one flaw in wear leveling and trim in that partially full blocks are not trimmed. Only blocks that are verified as empty are reset by the SSD (based on block boundaries). This means that when organic writes are committed to the device, the wear leveling algorithm has more trimmed blocks to work with. This helps TRIM both restore performance, and the wear leveling algorithm extend the life of the device. (though we do not make a claim on extending the life of devices, this is because it is impractical to inorganically trash every SSD known to man SSDs in our labs - and because not all SSDs are created equal where wear leveling is concerned)
All that said, this solution is designed to allow trim and the wear leveling algorithm on your SSD to do the best job possible – any performance benefits or improved wear leveling are solely the responsibility of the OS and the SSD firmware. In this sense, our SSD optimization pass is in some aspects a prep pass. Going into much more detail than this is not really possible since I think digging deeper would start to delve into proprietary information. We do understand that this annoys people in that there is a general sense that there is not much useful information floating around regarding the mechanics of SSDs and how they should be optimized – but this is a reflection of the fact that SSDs are still really young in the market and things are changing rapidly. I think you'll find that competitors in the SSD hardware market tend to be tight lipped on what they are doing in order to maintain whatever edge they might have over another vendor. Likewise, we closely guard our methods since we have competitors too. Thus, I’m unable to provide details on the full depth of what we do, why we do it, and how. Hopefully the above is sufficient in explaining the general behavior of our SSD optimization pass and the benefits it provides.
Excluded “permanent” files:
The algorithm respects excluded data and works around it. This is true of all things PerfectDisk. Files that are exclusively locked are simply unmovable since we stick to using the system API – thus, illegal moves are not possible with PerfectDisk.
white paper:
http://www.raxco.com/user..._drives_ssds_6_1_2011.pdf
--------------------------
Antwoord van een medewerker van Raxco no 1:
The SSD optimization pass identifies the largest consolidated free space chunk already existing on your SSD and grows it. This results in a larger consolidated free space chunk on the volume - but the primary reason for doing so is to maximize the number of blocks which can be trimmed by the OS or the device. This is increases the effectiveness of garbage collection. (TRIM)
Edit: I want to make clear here that while the pass effectively increases free space consolidation - it should not be confused with our normal free space consolidation pass since that pass defragments files and creates a large free space gap at the end of the drive. The SSD optimization pass does not defragment files and it does not consolidate free space at the end of the drive, instead it grows the largest existing gap on the volume. The two should not be confused.
The pass is designed to do this without creating excessive erase/write cycles - and this is evidenced by how quickly this optimization pass runs. Our SSD optimization pass won't have your SSD churning through data and can be run as often as you like.
----------------
Antwoord van een medewerker van Raxco no 2:
Growing free space:
By moving out data into blocks that are not full. This quickly eliminates as many partially full blocks as possible. This is done using a one shot method, so there is no use of swap space (no churn). The result is a marked increase in the number of blocks which can be trimmed in exchange for incurring a single read/write cycle for a very small number of partially full blocks. If there are any free blocks that can be used to relocate data, those are used instead since this is both faster (no read/write cycle), and aids wear leveling a bit by not writing to a previously written to block. How we determine which blocks to target and how we target them is strictly proprietary.
Of course, this is a very simplistic description of the rules that govern the behavior of the algorithm because the behavior described operates within the context of growing out the largest consolidated free space chunk and not wholly consolidating all free space. Thus, no defragmentation of either free space or files is performed. This is why the primary action is referred to as "growing" free space. Also not to be confused with "freeing up" or "recovering" free space.
This eliminates one flaw in wear leveling and trim in that partially full blocks are not trimmed. Only blocks that are verified as empty are reset by the SSD (based on block boundaries). This means that when organic writes are committed to the device, the wear leveling algorithm has more trimmed blocks to work with. This helps TRIM both restore performance, and the wear leveling algorithm extend the life of the device. (though we do not make a claim on extending the life of devices, this is because it is impractical to inorganically trash every SSD known to man SSDs in our labs - and because not all SSDs are created equal where wear leveling is concerned)
All that said, this solution is designed to allow trim and the wear leveling algorithm on your SSD to do the best job possible – any performance benefits or improved wear leveling are solely the responsibility of the OS and the SSD firmware. In this sense, our SSD optimization pass is in some aspects a prep pass. Going into much more detail than this is not really possible since I think digging deeper would start to delve into proprietary information. We do understand that this annoys people in that there is a general sense that there is not much useful information floating around regarding the mechanics of SSDs and how they should be optimized – but this is a reflection of the fact that SSDs are still really young in the market and things are changing rapidly. I think you'll find that competitors in the SSD hardware market tend to be tight lipped on what they are doing in order to maintain whatever edge they might have over another vendor. Likewise, we closely guard our methods since we have competitors too. Thus, I’m unable to provide details on the full depth of what we do, why we do it, and how. Hopefully the above is sufficient in explaining the general behavior of our SSD optimization pass and the benefits it provides.
Excluded “permanent” files:
The algorithm respects excluded data and works around it. This is true of all things PerfectDisk. Files that are exclusively locked are simply unmovable since we stick to using the system API – thus, illegal moves are not possible with PerfectDisk.
) en ze beweren dat somehow te kunnen bewerkstelligen.
:strip_icc():strip_exif()/u/157053/crop574c68cea92df_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/109539/avatar_kerst_still.jpg?f=community){kind=avatar}
Tot 2GB ging het in het RAM, maar daarboven was het 2 minuten per GB.
....
Agility/solid 3 dan ...
:strip_exif()/u/164293/logo.gif?f=community){kind=logo}
. 
/u/162933/arch_gnu.png?f=community)
:strip_exif()/u/347735/crop58f65ba8bbb3d_cropped.gif?f=community)
:strip_exif()/u/420693/nvidia_logo.gif?f=community){kind=logo}
:strip_icc():strip_exif()/u/93148/NaNthor_Ultimate_Avatar_Tweakers.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/363314/avator3.jpg?f=community)
/u/400/defember100.png?f=community)
/u/243953/crop56f55a7bcf291.png?f=community)
/u/1176/crop635f8931b2b68_cropped.png?f=community)
:strip_icc():strip_exif()/u/47854/Bitchin.jpg?f=community)
