03-29-2014 09:11 AM - edited 03-29-2014 09:12 AM
Just to clarify, when I posted that delay with only 17GB cached it was due to a Win logo freeze at the usual point, but it was way shorter (only about 2-3s) than annoying ones with >22GB filled. They seem related, anyway.
Also, after reducing the caching partion I've had no more casual freezes later in the boot with stuck hdd led lit. Those happened when cache was near full.
Most probably, a 2/3 ssd size cache partition should be near the limit before trouble happens for most, given that it won't fill completely. I still hope most issues can be solved either by software, or a ssd firmware update.
04-07-2014 07:34 AM
With my cache drive capped at 18Gb I haven't had any problems yet. I wish sandisk would fix this so I didn't have to cap the drive. Honestly, it's beginning to seem like a design flaw and they should have made it a 64Gb drive that is overprovisioned to 32Gb.
This is exactly what my OCZ synapse drive I used to use did. Honestly, Sandisk should just release a new drive and give us all discounts on a new one if we send the old one in.
04-14-2014 07:38 AM
I tried "Preview" before submitting a long post and could not find a way to edit the post further, in so doing lost the post -- out of time to type it all again now.
So without explanations, my recomendation for anyone experiencing what they feel are excessive boot delays are to try a partition size of 25Gb (25 x 1024 = 25600) using one of the methods previously discussed in this thread. That may be the largest cache size you can use to reduced this problem if you are experiencing it.
Regardless of partition size one uses, occasionally seeing the Windows logo for up to two revolutions of the dots is part of normal cache operation. Testing continues, I have two of these in different machines now now, one will remain at the original 29.xx Gb partition and one will vary.
04-14-2014 08:23 AM
I've given more thought overprovisioning since I mentioned it as a possible way to reduce cache housekeeping delays. If I personally bought a 64 Gb SSD cache drive, I'd probably run it in the 50-60 Gb range rather than half of that to overprovision. In other words I'd accept reduced longevity and occasional housekeeping delays to gain additional files cached.
Another issue is marketing. Although one could justify overprovisioning a small SSD used as a cache due to the relatively low total cost of going from 32 to 64 Gb of NAND, what about a 1Tb SSD? How are you going to sell increased reliability for one product and not another? I can see it for 'mission critical' enterprise level cost relatively no object installations but for the home market, "I can give you TWICE the storage for the same money" would be impossible (IMO) to beat.
04-14-2014 10:37 PM - edited 04-14-2014 10:38 PM
Yea that would be an unfortunate design flaw if its failing because the relatively cheap controller it uses can't keep up with all the writes when full, causing resets or whatever.
That being said I never got close to full on mine after a while, so I guess it failed.
04-15-2014 10:25 AM
I don't think it's the controller, it should easily be able to keep up with LBA requests. I agree with AlleyViper, this is most likely a Condicive software glitch. My hypothesis is that something is that some permanent or temporary data array is, under some circumstances, running out of pre-allocated or available space, or possibly some numerical value is exceeding type allowd value (not likely these days).
Two things that can negatively affect caching performance:
Security software scans. We all (hopefully) do a quick scan each boot, and probably idle time scans -- and every so often I scan every single file, archive, etc. This makes the cache record lots of LBAs many of which are otherwise rarely read.
Defragging moves data from one LBA to another, cache has to adjust to new read patterns. Active defraggers that try to move files around in real time to keep them contiguous generate 'spurious' (from a caching perspective) LBA reads and change which LBAs hold which data, again forcing the cache to reorder/reprioritize.