What the people are asking for + a few others.

Report bugs or suggestions around FancyCache
Mradr
Level 7
Level 7
Posts: 87
Joined: Sun Mar 25, 2012 1:36 pm

Re: What the people are asking for + a few others.

Post by Mradr »

Two new items added: Defer write times and GUI interface request.
Last edited by Mradr on Fri May 11, 2012 5:42 am, edited 1 time in total.
User avatar
Support
Support Team
Support Team
Posts: 2792
Joined: Sun Dec 21, 2008 2:42 am

Re: What the people are asking for + a few others.

Post by Support »

Thank you, Mradr. I have set this topic sticky at top of lists.
Mradr
Level 7
Level 7
Posts: 87
Joined: Sun Mar 25, 2012 1:36 pm

Re: What the people are asking for + a few others.

Post by Mradr »

support wrote:Thank you, Mradr. I have set this topic sticky at top of lists.
Np. Let me know if you get them finish via the PM system if you like. This way people will know what will be comming into the next release and what issues are already fixed for the release.

Updated version 0.8.0.1:
Includes new:
7) Power Fail
8) Add a Pro/Advanced mode to hide some features
9) Suspend All Writes (New, edv)
Also added a version tag base off [Current FC Build #].[Current Future/Bug Requested Version #]

Changes:
Number 4: "Set L2 to ready/write/both" and number 6: "Disable L1 for L2" are now the same number as they were perty much the same idea/request.
PtDragon
Level 3
Level 3
Posts: 12
Joined: Mon Nov 07, 2011 8:38 pm

Re: What the people are asking for + a few others.

Post by PtDragon »

Dynamic pool sounds good (hope there will be option to configure limits, not only priority).
Mradr
Level 7
Level 7
Posts: 87
Joined: Sun Mar 25, 2012 1:36 pm

Re: What the people are asking for + a few others.

Post by Mradr »

PtDragon wrote:Dynamic pool sounds good (hope there will be option to configure limits, not only priority).
Yes. I think I need to do a better example of what was being ask for it.


Update V#: [0.8.0].[2] ^^
Did a better example of what I mean for number two of the list.
mabellon
Level 3
Level 3
Posts: 10
Joined: Fri May 25, 2012 5:32 pm

Re: What the people are asking for + a few others.

Post by mabellon »

Mradr wrote: 1) Persistent L2.
Complete this feature alone and you've got my money. Obviously not so easy as you're a layer on top of the filesystem which can be changed 'offline' without FC knowledge. I'm crossing my fingers.
Mradr wrote: 3) Pool Dynamic Priority Percent Base L1.
4) Set L2 to Read, Write, or R/W, and give the option to disable L1 for L2 (Mradr, laferrierejc)
Using L1 for Write-Cache is simply too risky for me personally. As a read cache, I just don't see the point. It's especially pointless as RAM is volatile/not persistent between boots. Windows + Superfetch are going to do a better job for most workloads. Also, Windows will automatically give you the pooling behavior - use all RAM based on priority of files accessed. If FancyCache is caching something in L1 and Windows has the file in mem (on the Standby list for instance) then you've just wasted 2x the RAM for nothing. For those interested, this waste of memory can be proven with RAMMAP (SysInternals).
Mradr wrote: 6) Keep-Alive Performance Monitor.
Please consider using the standard Windows performance counters to track FC performance (perfmon, logman). That is, make FC a provider of counter data. Then users can track usage in logs, schedule when to capture data and for how long. Why reinvent the wheel here - there is already a facility for tracking and graphing perf data. With this approach, you can even graph FC hits against actual disk IOps, memory usage etc. (thus better showing the incredible benefits of FC). Also users should be able to capture perf logs for scenarios like boot performance (post login) long before the FC management UI could ever come up.

Thanks for this awesome Beta. And thank you Mradr for composing this list.
kalua
Level 4
Level 4
Posts: 35
Joined: Thu Aug 19, 2010 1:38 pm

Re: What the people are asking for + a few others.

Post by kalua »

Pooling memory with a min/max would be good, so all drives can share from the same pool. As it is now, I give about 16GB of a 24GB system to FC, but that is 8GB to one drive, 7GB to another, and 1GB to the system drive. When I launch something big like a VM, I have to reconfigure FC to use less. A better way would be to tell FC to use a min of 2GB, a max of 12GB, and have it dynamically allocate up to that 12GB only when needed.

L2 writable would also be helpful in a way you might not have thought of. In particular, I would love to use less-expensive and lower power spinning hard drives of large capacity. I can't, because they are slower. A large FC read cache makes them very usable, but the slow write speeds means the write cache limited to RAM gets filled quickly.

I realize that with WD black and other 7200 RPM drives, using a conventional SSD that is only two times faster that the spinning drive for L2 cache may not give you much improvement if L2 was writable. But when the spinning media is a 5400 RPM low-power drive, and your L2 cache is on a high-end SSD (like a Revo X2 or a RAID-0) I believe the huge difference (my L2 cache disk is over 8 times faster writing than my other disks) in write speeds would make writable L2 a big plus.
Mradr
Level 7
Level 7
Posts: 87
Joined: Sun Mar 25, 2012 1:36 pm

Re: What the people are asking for + a few others.

Post by Mradr »

kalua wrote:Pooling memory with a min/max would be good, so all drives can share from the same pool. As it is now, I give about 16GB of a 24GB system to FC, but that is 8GB to one drive, 7GB to another, and 1GB to the system drive. When I launch something big like a VM, I have to reconfigure FC to use less. A better way would be to tell FC to use a min of 2GB, a max of 12GB, and have it dynamically allocate up to that 12GB only when needed.
There are two levels of the dynamically caching going on. One at the pool level and the other at the drive level. The pool level has very little user control as the system/FC handels that one. You just set the max size of it and the system will take care on how it grows or shrinks for the need. At the drive level you'll be able to set the dynamic min and max use of the pool. This would allow for the VM to take on more ram if it needs but still makes sure it has the min 4GB of the pooled cached ram. I'll updated a better example to help clear up this misunderstanding later.
kalua wrote: L2 writable would also be helpful in a way you might not have thought of. In particular, I would love to use less-expensive and lower power spinning hard drives of large capacity. I can't, because they are slower. A large FC read cache makes them very usable, but the slow write speeds means the write cache limited to RAM gets filled quickly.

I realize that with WD black and other 7200 RPM drives, using a conventional SSD that is only two times faster that the spinning drive for L2 cache may not give you much improvement if L2 was writable. But when the spinning media is a 5400 RPM low-power drive, and your L2 cache is on a high-end SSD (like a Revo X2 or a RAID-0) I believe the huge difference (my L2 cache disk is over 8 times faster writing than my other disks) in write speeds would make writable L2 a big plus.
Yup, the same idea I guess. A sort of software RAID that takes on less risk as the data is being saved as a 1+0 configuration (Note: don't get this confused with a raid 0 or a raid 0+1). All the speed with "lower" risk to data lost. What happens mainly is that instead of the main disk getting hited with all the write request, the next drive would be able to take on "half" on them. In the case of a SSD, the SSD can write faster than a HDD and provide almost 3-4x the performance as the drive can take on more write request than the HDD can. Even if the SSD was another HDD, the increase would still be higher as the main drive would be able to finish the write request and then get to work on the read request that much faster.

The only danger to this is that if data was changed in "off line mode" then FC might return the wrong data. I question what they mean by that along side that fact when and why data would change in "off line mode," but I am guessing they've seen something in the testing that would say otherwise. I don't have much details on this subject ^^; I'll get back to you later on. This feature may never be included. It just has a high requested feature from the community.

Update V#: [0.8.0].[3]
Reword the example for 3) Pool Dynamic Priority Percent Base L1.
mabellon
Level 3
Level 3
Posts: 10
Joined: Fri May 25, 2012 5:32 pm

Re: What the people are asking for + a few others.

Post by mabellon »

The only danger to this is that if data was changed in "off line mode" then FC might return the wrong data. I question what they mean by that along side that fact when and why data would change in "off line mode,"
"offline mode" likely just refers to any time a disk is mounted when FC isn't running. Such as booting into a different OS partition, or running chkdsk on boot. Alternatively, if your cache was on a USB device and was removed/used elsewhere. The only way around it is likely to be hackery, or a best-effort (not 100% stable) solution. I guess you could write your own filesystem as well.
Mradr
Level 7
Level 7
Posts: 87
Joined: Sun Mar 25, 2012 1:36 pm

Re: What the people are asking for + a few others.

Post by Mradr »

mabellon wrote:
The only danger to this is that if data was changed in "off line mode" then FC might return the wrong data. I question what they mean by that along side that fact when and why data would change in "off line mode,"
"offline mode" likely just refers to any time a disk is mounted when FC isn't running. Such as booting into a different OS partition, or running chkdsk on boot. Alternatively, if your cache was on a USB device and was removed/used elsewhere. The only way around it is likely to be hackery, or a best-effort (not 100% stable) solution. I guess you could write your own filesystem as well.
Well yea, editing data when FC isn't around would refer to "offline mode," but:
As for the "persistent cache" part of it:
Even if the data changes, why not check the data's "MD5" to make sure it is current? This would increase startup time of the program, so it wouldn't be really useful at startup[or aka first run of the program], but would offer that "safer" offline mode change to happen.

Then again... What data is being changed offline? I mean, most users wont be booting into Linux and changing data on a windows partition for fun. Even if they are, they would already know the risk of doing so. If they did not, then that would be a user failer on how to use their system. Even still, the File System should also be updating the Time Changed or the Data Accessed variable on the file. This gives even another option for a "safer" offline experience would it not?
More or less.. you would just have to force the file system to always be NTFS even on flash drive, or as you said, create your own file system. Good luck on forcing people to use a whole new file system, lol. NTFS would on the other hand be ok as 90% of most drives use it already I guess.

As I said, if you are going to change data offline, then you should know the risk. All FC would have to do is put a warning sign up saying, "Drives/volumes cached can not be edited while offline." After that, that be a user issue as they should already know. I mean most common people do not dual boot, and the ones that do usally know what they're doing already and know the risk of dual booting and accessing data that is not part of their current system.

The only true issue would be flash drives. As most people do move their flash drives around. Forgetting to replugin your flash drive could cause errors if you enabled L2 to do writes along side reads. In this case, you would have to either say, "Hey look, FC can use the flash drive as a write device, but you have to keep it in there at all times or else something bad could happen," or say, "Look, FC can not enable write on L2 on removeable devices, please selected a non-moveable device if you wish to enable write L2." Other wise, read only is mainly cache data in it self. Cache data isn't really that important and can be lost if such an error does happen. You mainly just end up rebuilding the read-cache data anyways in the worest case. Deleteing or changing the data on any device would still be a user issue and not FC fault as the user should know already that it is not wise to pull active working data/devices from a computer without suffuring data lost.

There isn't a safe way to do this no matter how you look at it. The user still would have the final say if they wanted to "destory" their computer. The user atm still could clear the ram for fun while there was data still in ram and would end up causing the data lost, too. So I mean, the risk is already out there, you just have to make sure the information is getting out there by put up warnning signs for them to read and know the risk of accessing a cache drive would not be wise from another system unless the system is using NTFS (because the system updates file access/changes). After that, it would just be a user error at best as FC already warn the user and the user did not lisen.

Also, as far as I know, Scan Disk also updates file access/change access as long as it is in NTFS.

I'm not picking on you. I'm just having a hard time seeing what the big deal is in having a persistent L2 cache is all. It perty much comes down to 3 things:
1) Did you warn the user what could happen if x and x was changed?
2) Do or Do not enable L2 writes, or enable L2 writes but either limit it to non-removeable drives or let users decide for themselves.
3) Force NTFS on the cache drives or increase starting first time runs to also create a hash that you can compare it to later.

After that, it just comes down to user-error. There isn't much more you can do it protect the user from themselves.

At best I would say do this:
1) Enable "persistent cache" on L2 default Read-Only (Can still use Write Only or Read/Write)
2) If Write is included, force L2 to be a HDD or a SSD (Or flash based) only type drive. Warn users that it must be a non-volatile type storage drive.
3) Warn users that the L2 drive can not be removed in the future and that the Cache drive can not be accessed off-line when they hit apply.
4) Run a hash check on the first time a program is started up, else See Number 8.
5) If the hash is not in the list on the persistent cache, store the hash and the cache data for future loads.
6) If a reboot has happen, See Number 7
7) If hash is still the same, continue to Number 8, else See Number 9
8) On next start of the program, countine loading from the persistent cache.
9) Delete all cache and hash data on that program, See Number 5

^-Should be perty close to the right order in terms of flow commands...

The only issue comes down to the fact that FC is a driver block base program and most of this comes from having a bit higher level of access (I wanna say file level?) I'm not sure on all the levels for say. I guess I really should learn up on em really fast before I really say anything, but I am perty sure even at the block level there would still have to be some sort of organization and checksums going on that you could use to help program this in.
Post Reply