On 2013/06/11 07:21, Dag Wieers wrote:
> On Mon, 10 Jun 2013, jdow wrote:
>
>> Just a little note, Vladimir, please be aware that there appears to be
>> a problem with SSDs when you read the same portion of the disk very many
>> times per day. The section of flash seems to lose data and cannot be
>> refreshed after a couple years. We have customers who use SSDs in theme
>> park rides in the vehicles for an audio server. It was a short, ride
>> length, audio track repeated every run for the ride vehicle - every few
>> minutes for a 12 hour day 365 days per year.
>>
>> We now counsel customers to use features in the program to allow storing
>> many copies of the audio track and rotate their use to avoid this wear
>> problem.
>>
>> This is mentioned so infrequently in the literature that I am not sure it
>> has been generally recognized or dealt with by the disk manufacturers. It
>> surely astounded us when the reports started coming in.
>
> Wouldn't the VFS layer make sure the audio track was in cache, avoiding to read
> from SSD on every request ? Even if the cache pressure (for whatever reason)
> would flush it from cache, make sure it stays in memory by putting it in a tmpfs
> filesystem during boot and use that instead ?
>
> Seems to me more worthwhile than rotating over different entries in a filesystem
> on an SSD. Especially since there's no need to keep reading it from SSD...

This was on a custom built piece of machinery with an OS that the box's
designer built. We've also seen it with an early adopter of Loren's tool.
He didn't listen to recommendations. Loren's tool used Windows XP in that
case, I believe. Windows treats caching differently - a given. And the
files were one ride duration of uncompressed multi-channel audio (a few
minutes worth). That's large enough to fall out of most simple caches
anyway. Arguably the file should be read once into something like ramfs
and read many from there. Certainly the current machines have enough ram
to make that practical.

{^_^}