On Sun, Jun 12, 2011 at 1:10 AM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 12/06/11 00:57, Randall R Schulz escribió:
Hi,
My next question relating to using SSDs on openSUSE is whether they enable or implement the so-called Idle Time Garbage Collection used by SandForce SSD chips (such as the SandForce 1222 chips on the RevoDrive x2 card I bought).
afaics, "Idle Time Garbage Collection" is implemented in the controller.
Nothing I've found has made it clear whether this is something that requires OS / filesystem support, but the descriptions I've found (which have been very sketchy) suggest filesystem support is required.
TRIM needs support in the filesystem, ext4 has a support for it, using the "discard" mount option, which is apparently on its infancy.
Cheers.
Randall, I'm not a SSD designer, etc., but I like to keep up and I have talked to a couple "data recovery" people that have tried to reverse engineer how a SSD works. The below is based on that process, and may not relate to reality at all, but I think it is pretty close. === "mount --discard" is implemented by interlacing trims with normal i/o. For current generation SSDs, this reduces performance instead of increasing it. Windows 7 implements a background discard feature. Thus if you monitor the SATA bus, you will see trim commands coming even when there is no normal i/o. A far more efficient approach. (Apparently SSDs flush their cache when the get a trim command, so interlacing them is like adding tons of flush commands.) There is a userspace tool in 11.4 (and newer): fstrim. It is part of the util-linux package I believe. It is simple userspace tool to invoke a kernel filesystem scan for free blocks and send trim commands to an underlying SSD. If you set fstrim up to run from cron every now and then, you have a good situation. It typically takes less than 30 seconds, so just calling it during boot might be good enough for a laptop that is booted every week or two. As to garbage collection. I don't know what the sandforce does, but in general all modern SSDs need to have a Erase Block (EB) consolidator. Modern SSDs have EBs which are typically 128KB, but they allow those EBs to hold non-contiguous pages of data. The key thing to understand is EB re-use is all or nothing. To re-write any of the data, you have to Erase the entire EB, then re-write it. In very slow / cheap thumb drives, they live with the restriction and write speeds can be as slow MBs/minute. In a decent SSD, they have much more complicated algorithms to make the drive much more responsive. So lets assume a SSD tracks and maps data in 4KB pages, even though it has a 128KB EB. So a newly allocated and written EB would typically have 32 4KB pages in it. If some of the pages are overwritten, the most efficient thing for the SSD to do is mark the pages in the allocated EB free, and queue the new pages to go to a newly allocated EB. When the SSD has 32 pages of new data queued, it will allocate a new EB and write out the data. Seems pretty smart, but think about the original EB. Over time as data is overwritten it goes from 32 of 32 pages in use to less and less pages in use. At some point the SSD controller says, what a waste of space, let me consolidate some of these partially used EBs. That consolidation activity is what I assume Sandforce is calling garbage collection. And you can see it is needed even in the absence of OS level support. And it does not need to understand the filesystem layout etc. The trouble is if your drive is 100% full or close too it, the EBs will tend to be fairly full as well, and so you can end up with all the EBs in use with 75% or more good data. Having a consolidator be efficient with such a high average in-use percentage is very difficult. Thus the concept of trim was created a few years ago. As I understand it, the goal is for the SSD to have greater knowledge of what pages are really in use, vs. not in use. And with that knowledge be able to more efficiently consolidate EBs for background erasing. Thus, my opinion is that the SandForce Idle Time Garbage Collection is implemented in the SSD and does not need Linux support to work, but calling fstrim on occasion will let the SSD know better what data pages are free and thus allow the process to work better. Hope that helps Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org