I want to ask about image files. Example: I make an X GB image file, put that image file on a fast SSD.
Question: will SSD trim work with the image? Or will the system be rewriting the same blocks where the image file is stored?
SoftPerfect RAM Disk
SSD trim and RAM disk image
Started by mraksoll
SSD trim and RAM disk image 05 May 2020, 21:15 |
Registered: 4 years ago Posts: 11 |
Re: SSD trim and RAM disk image 05 May 2020, 22:51 |
Admin Registered: 18 years ago Posts: 3 570 |
The image file is a regular file. Upon shutdown or manual saving to the image parts of the file are updated (overwritten). We don't (re)write the entire file, but only the 2 MB blocks that have changed since the image was read or last saved.
As far as I know The TRIM command only applies to file deletions. The OS marks deleted blocks as such and then the TRIM command lets the SSD controller know that the block is free.
What you are asking about is called wear leveling. It's up to the controller whether to move overwritten blocks around or not. From the point of view of the OS, the file stays in the same sectors of the disk, the controller will usually move blocks around to prevent SSD's wear.
As far as I know The TRIM command only applies to file deletions. The OS marks deleted blocks as such and then the TRIM command lets the SSD controller know that the block is free.
What you are asking about is called wear leveling. It's up to the controller whether to move overwritten blocks around or not. From the point of view of the OS, the file stays in the same sectors of the disk, the controller will usually move blocks around to prevent SSD's wear.
Re: SSD trim and RAM disk image 06 May 2020, 22:24 |
Admin Registered: 18 years ago Posts: 3 570 |
It's worth noting that we have added sparse file support and new images are created as sparse files. This results in much faster image creation, compact disk presentation and faster reading from that image.
We will soon make the new build available. In the meantime, here is what it looks like:
We will soon make the new build available. In the meantime, here is what it looks like:
Re: SSD trim and RAM disk image 07 May 2020, 00:53 |
Registered: 4 years ago Posts: 11 |
Re: SSD trim and RAM disk image 07 May 2020, 11:26 |
Admin Registered: 18 years ago Posts: 3 570 |
It's called a sparse file. Simply put, any empty space inside a sparse file is not stored on the physical disk.
With regards to the RAM Disk, it acts like a dynamic image file that grows and occupies disk space when it's populated. Upon creation most of the image file is filled with zeros and therefore it takes little space regardless of its logical size.
You can download the latest build with sparse file support here.
With regards to the RAM Disk, it acts like a dynamic image file that grows and occupies disk space when it's populated. Upon creation most of the image file is filled with zeros and therefore it takes little space regardless of its logical size.
You can download the latest build with sparse file support here.
Re: SSD trim and RAM disk image 07 May 2020, 20:47 |
Registered: 4 years ago Posts: 11 |
Works perfectly!
Does the image self-compact when data was deleted? Or do I need to do it somehow manually?
Tested: no compacting when data deleted and saved to .img. Maybe need a new flag in GUI with autocompacting during mount/unmount or after saving, and manual compacting from the image menu.
Does the image self-compact when data was deleted? Or do I need to do it somehow manually?
Tested: no compacting when data deleted and saved to .img. Maybe need a new flag in GUI with autocompacting during mount/unmount or after saving, and manual compacting from the image menu.
Re: SSD trim and RAM disk image 07 May 2020, 21:38 |
Admin Registered: 18 years ago Posts: 3 570 |
The file is not compacted when data is deleted from a RAM disk or image. In general when you delete a file, the OS marks the space within the file system as unallocated, but it doesn't zero it out. Later that space is reused to write another file in it.
It is technically doable to zero-out free space with a third-party utility and then compress the sparse image file. However this will in turn cause the image file to have multiple "holes" (areas with zeros) and become heavily fragmented.
It is technically doable to zero-out free space with a third-party utility and then compress the sparse image file. However this will in turn cause the image file to have multiple "holes" (areas with zeros) and become heavily fragmented.