Page 3 of 3

Re: [2012-02-27] FancyCache Beta 0.7.2 published

Posted: Fri Mar 16, 2012 10:05 am
by fsommer1968
@onder,

your assumption is not true. On the level of operating of FC (block level filter driver) there is no information of the file that might be written or read, FC deals only with numbered "data blocks" relative to the partitions 1st data block or disks 1st data block. Maybe FC knows something about the filesystem underneath. But your initial feature request was: "Exclude specific files from being cached". And this would require exact information about every file that is currently in operation by FC *AND* the files corresponding data block (numbers). This would require far more than a block driver. Anyway your requirement is possible of course - everything is possible.
The fact, that FC works as a block level filter driver is one of the major advantages. Example: As we know FC works well with encrypting filesystems like Truecrypt or NTFS enryption (EFS). How can FC be aware of a specific file on an encrypted filesystem when the encryption/decryption takes place in an upper level of the operating system and the encrypted filesystem is represented as one large file on the storage?
I´m very happy with the general architecture of FC as it leads to a fast, reliable solution. Everything that would require more checking of the content during operations like "to which file does this block belongs to" would have an impact on the performance.
In addition if FC would know which files is being written, it should be aware of much more as the MBR. And it should know the details not only of NTFS, but also of FAT16/FAT32 and any other filesystem (Truecrypt, EFS, NTFS compression) that might exist on Windows.

Re: [2012-02-27] FancyCache Beta 0.7.2 published

Posted: Tue Mar 20, 2012 6:55 am
by NickJ
Intel SRT's solution to the problem is to not cache large sequential operations which doesn't require file awareness. This would accomplish the same objective as not caching "large files" that are "read only sequentially".

Re: [2012-02-27] FancyCache Beta 0.7.2 published

Posted: Tue Mar 20, 2012 9:40 am
by fsommer1968
Q: How effective is Intels approach in detecting real large files operations belonging to the same file, as a large file is probably fragmented resulting in a couple of larger and smaller sequential operations?

Re: [2012-02-27] FancyCache Beta 0.7.2 published

Posted: Sat Mar 24, 2012 3:21 am
by NickJ
Due to Win7 background defragmentation that's not an issue. The last few times I've loaded up the defrag utility I've been at 0% fragmentation.

Re: [2012-02-27] FancyCache Beta 0.7.2 published

Posted: Sun Mar 25, 2012 1:53 pm
by Mradr
I have to agree with fsommer1968, anything under the encrypted filesystem will be seen as one big file. Encrypted filesystem usally takes the whole file(s) and then applies the encryption code across so others can not simply break into it just by knowing one of the file(s) inside.

However, we can do exclude file extensions and folder locations at almost any level allowing little to no slow down. The trick is to find out who requested what and where before being cached would be the only differents... Just saying... I've seen other products do it and it does not slow them down as the cache data was never writen, so the block driver never has to look for it.