Re: What the people are asking for + a few others.
Posted: Tue May 29, 2012 5:56 pm
I was only half serious about the Filesystem part. That would simply be the cleanest solution - caching built right in. Obviously the work involved would mostly outweigh the gains. Personally I am OK with not-100% solutions at home as long as the error cases are fully disclosed.
Agreed. For removable flash drives, hopefully they can be detected and flagged not to be persistent. Otherwise, user error. Ignoring dual boot and USB flash, I'm still not convinced that there isn't a possibility of things changing in 'offline mode' (that is normal use-cases where the storage changes without FC, regardless of if FC can handle them) There are just a ton of possibilities, but hopefully they figure them out or work around. More food for thought - Safe Mode, restore points, defrag (moves blocks, but files are the same), chkdsk remapping bad sectors. I honestly don't use these features, so I'm not sure.
You've mentioned MD5 a few times. Please elaborate. It seems that you want to read the file off disk again, hash it and compare against the cache before using the cached copy? Sorry, I must be misunderstanding you because that would seem to defeat the entire purpose. At that point you've not only wasted CPU cycles on MD5, but also waited on the slow disk. If NTFS already had checksums/MD5 precomputed then it could be a great idea.
Also, depending on the implementation, File Access timestamps may not perform all that well. If the cache is implemented at block level, you would probably still have to re-read the file to block mapping and file timestamps every time on boot. Not to mention reading timestamps for every little file. Perhaps just an inconvenience, but still not ideal performance wise. Better than what we have currently, that's for sure.
Perhaps another possibility would be using the NTFS log/journal. I know little about it, but in theory, if the log hasn't changed since the last time FC was running, the cache is good. If the log has changed, either fallback to timestamps or rebuild the cache.
Agreed. For removable flash drives, hopefully they can be detected and flagged not to be persistent. Otherwise, user error. Ignoring dual boot and USB flash, I'm still not convinced that there isn't a possibility of things changing in 'offline mode' (that is normal use-cases where the storage changes without FC, regardless of if FC can handle them) There are just a ton of possibilities, but hopefully they figure them out or work around. More food for thought - Safe Mode, restore points, defrag (moves blocks, but files are the same), chkdsk remapping bad sectors. I honestly don't use these features, so I'm not sure.
You've mentioned MD5 a few times. Please elaborate. It seems that you want to read the file off disk again, hash it and compare against the cache before using the cached copy? Sorry, I must be misunderstanding you because that would seem to defeat the entire purpose. At that point you've not only wasted CPU cycles on MD5, but also waited on the slow disk. If NTFS already had checksums/MD5 precomputed then it could be a great idea.
Also, depending on the implementation, File Access timestamps may not perform all that well. If the cache is implemented at block level, you would probably still have to re-read the file to block mapping and file timestamps every time on boot. Not to mention reading timestamps for every little file. Perhaps just an inconvenience, but still not ideal performance wise. Better than what we have currently, that's for sure.
Perhaps another possibility would be using the NTFS log/journal. I know little about it, but in theory, if the log hasn't changed since the last time FC was running, the cache is good. If the log has changed, either fallback to timestamps or rebuild the cache.