[2012-02-27] FancyCache Beta 0.7.2 published

First hand news related to FancyCache
fsommer1968
Level 4
Level 4
Posts: 27
Joined: Fri Jan 07, 2011 3:11 pm

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

Post 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.
NickJ
Level 3
Level 3
Posts: 11
Joined: Thu Feb 09, 2012 12:02 am

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

Post 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".
fsommer1968
Level 4
Level 4
Posts: 27
Joined: Fri Jan 07, 2011 3:11 pm

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

Post 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?
NickJ
Level 3
Level 3
Posts: 11
Joined: Thu Feb 09, 2012 12:02 am

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

Post 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.
Mradr
Level 7
Level 7
Posts: 87
Joined: Sun Mar 25, 2012 1:36 pm

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

Post 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.
Post Reply