On 03/01/2014 09:11 AM, Niki Gorchilov wrote: > I'm musing on the performance implications of using rock store on SSD. There is very little experience with SSDs for Squid, especially when using Rock store (a relatively new feature). Folks naturally expect SSDs to be faster, but I have not seen (or do not recall) any high-quality comparisons specific to Squid and Rock store. Someday, we will make one. > As per my understanding the underlying filesystem is unaware of any > unused blocks in the big rock file, thereby using fstrim or "discard" > mount option will have no effect. Some Linux file systems know that the blocks are unused (at least the blocks at the end of the file), but unused blocks ought to be irrelevant for a cache in a steady state (the common/interesting case) because there are no unused blocks in that state. > Once the rock file is full, SSD io performance will degrade > considerably, due to the read-earase-modify-write cycle on every rock > change. There should be no erase-modify steps if your rock slot size is a multiple of OS page and disk block sizes. Only read-write. If that is not what you see, it may be a bug. Also, for a typical large cache, it is probably more like write-write-write-read-write-... cycle because a high portion of cache hits should come from the memory cache but nearly all cachable misses are written to disk. Alex.
