In my work, I need some certain files save immediatly. For example: *.c, *.CPP, *.h
So I advice to create a "Direct write list" in PrimoCache's delay-write mode.
When file suffix or directory, matched with the list, there will no delay on the disk write.
[Feature Request] Direct write for certain files
Re: [Feature Request] Direct write for certain files
PrimoCache don't works with files but with blocks......................................................
-
InquiringMind
- Level SS
- Posts: 477
- Joined: Wed Oct 06, 2010 11:10 pm
Re: [Feature Request] Direct write for certain files
Agreed with idefix44, but this option can be implemented another way by using file versioning software that takes immediate backups of files when they change. Use one of these and configure it to back up to a disk that doesn't use PrimoCache's Defer Write and you will have your "immediate save" with the added advantage of previous versions available in the event of any mistake.
Examples of file-versioning utilities include Aphar Backup (my favourite since it is light, fast and doesn't require .NET Framework - the webpage is Dutch but the program uses English), AutoVer, Yadis Backup and File Hamster (commercial).
Examples of file-versioning utilities include Aphar Backup (my favourite since it is light, fast and doesn't require .NET Framework - the webpage is Dutch but the program uses English), AutoVer, Yadis Backup and File Hamster (commercial).
Re: [Feature Request] Direct write for certain files
There's way to watch file changes, there's way to know the postions of them, right?
So it's no a mission impossible for PrimoCache.
Direct write is appreciated, more convenient than additional tools ^_^
So it's no a mission impossible for PrimoCache.
Direct write is appreciated, more convenient than additional tools ^_^
-
InquiringMind
- Level SS
- Posts: 477
- Joined: Wed Oct 06, 2010 11:10 pm
Re: [Feature Request] Direct write for certain files
PrimoCache works at block level not file level. Yes, extra code could be put in to monitor file changes separately and to send messages listing any altered blocks to the caching routine, but that would involve a significant addition for a rarely-requested feature - especially if it needed filesystem-specific code (FAT32, NTFS, ReFS) and would have the downside of causing write amplification (due to large blocks being rewritten repeatedly due to small changes in a single file).
The "additional tool" approach really does have the advantage of simplicity here as well as providing automatic (and multiple) backups onto other media, providing a recovery path from disk failure or corruption. It's well worth considering for any data you value.
The "additional tool" approach really does have the advantage of simplicity here as well as providing automatic (and multiple) backups onto other media, providing a recovery path from disk failure or corruption. It's well worth considering for any data you value.
-
Axel Mertes
- Level 9
- Posts: 180
- Joined: Thu Feb 03, 2011 3:22 pm
Re: [Feature Request] Direct write for certain files
I agree with Inquiring Mind,
PrimoCache works on a block level and does not know anything about files, not even about file systems.
As already suggested you can do so by e.g. adding Syncovery to make constant mirrors of your drive onto a non-cached drive, including versioning history options etc. - we do exactly that with our project RAIDs. Using 2 TByte SSD caching per RAID, we can defragment in nearly no time. We move around about 500 GByte to 1 TByte per single working day, sometimes even more. Defragmentation runs hellfast on this. We know it may affect SSD lifetime, however, it strongly improves performance of the underlying RAID and is a life saver in desaster recovery situations. Have you ever tried to recover data from a fragmented RAID? I did and its hell. You'll find thousands or millions of old unneeded fragments. A small error area on disk will already affect many many files. On a defragmented volume the same error area will affect only a few files and recovering is pretty straight-forward, as there is few to none unused fragments left. It can increase recovery possibility by magnitudes, leaves your drives faster and healthier, reduces risk significantly.
Beside that you might add software such as Condusiv (aka Diskeeper) Undelete Server. This will prevent files from being overwritten and instead keeps version history in place on your target disk. Even from a network client.
Beside all that - and opposed to Inquiring Minds comment - having something like PrimoCache block level caching adapted to perform as a file level cache is not a rarely asked feature. In fact it would be potentially a bigger market than the other way around. But its far more complex to implement. First you may have to make decisions on supported filesystems, such as NTFS, ExFAT, etc. Then you have to implement a cache on a completely different level of the filesystem. While this might be achieveable locally (but making few difference to actual block level caching anyway, then...), its a completely different beast when we think about network. In a network that would be a tremendous improvement. However, that requires a client-server communication model and you will find yourself very close to implemented a SAN software then and re-invent Microsofts Branched cache (but with higher speed).
The best would be a marriage between a true SAN file sharing software like e.g. TigerStore and block level caching like in PrimoCache. That would reduce network traffic dramatically and increase overall system performance easily by 100 times.
PrimoCache works on a block level and does not know anything about files, not even about file systems.
As already suggested you can do so by e.g. adding Syncovery to make constant mirrors of your drive onto a non-cached drive, including versioning history options etc. - we do exactly that with our project RAIDs. Using 2 TByte SSD caching per RAID, we can defragment in nearly no time. We move around about 500 GByte to 1 TByte per single working day, sometimes even more. Defragmentation runs hellfast on this. We know it may affect SSD lifetime, however, it strongly improves performance of the underlying RAID and is a life saver in desaster recovery situations. Have you ever tried to recover data from a fragmented RAID? I did and its hell. You'll find thousands or millions of old unneeded fragments. A small error area on disk will already affect many many files. On a defragmented volume the same error area will affect only a few files and recovering is pretty straight-forward, as there is few to none unused fragments left. It can increase recovery possibility by magnitudes, leaves your drives faster and healthier, reduces risk significantly.
Beside that you might add software such as Condusiv (aka Diskeeper) Undelete Server. This will prevent files from being overwritten and instead keeps version history in place on your target disk. Even from a network client.
Beside all that - and opposed to Inquiring Minds comment - having something like PrimoCache block level caching adapted to perform as a file level cache is not a rarely asked feature. In fact it would be potentially a bigger market than the other way around. But its far more complex to implement. First you may have to make decisions on supported filesystems, such as NTFS, ExFAT, etc. Then you have to implement a cache on a completely different level of the filesystem. While this might be achieveable locally (but making few difference to actual block level caching anyway, then...), its a completely different beast when we think about network. In a network that would be a tremendous improvement. However, that requires a client-server communication model and you will find yourself very close to implemented a SAN software then and re-invent Microsofts Branched cache (but with higher speed).
The best would be a marriage between a true SAN file sharing software like e.g. TigerStore and block level caching like in PrimoCache. That would reduce network traffic dramatically and increase overall system performance easily by 100 times.