2 very exciting updates from Andrew Rawnsley's related to CascheFS and Iris, so they deserved their own follow-up article and some more investigation....
As part of his talk Andrew provided 24 hour links to download some links to both CacheFS and Iris (a reward for attending his talk).
CacheFS
CahceFS is a filing system which currently provides speed improvements reading files from file systems. The slower the system the better the results. Andrew's demo on opening the PDF guide was certainly impressive!
The system is really transparent and easy to use - just open a FS link in CacheFS. Something like *Filer_OpenDir CacheFS#<Boot$Dir>.^
Andrew said it should work on most FS systems but is also intelligent about not caching where system is already likely to be cached or no gain (like RamFS). Currently there is no caching on any writes but CacheFS does make sure it synchronises data it has cached on any write.
The actual download I snagged on the night gives some more details. It includes a single module and a very well-written ReadMe file with lots of info. CacheFS is currently version 0.05 and beta release (so make sure you have backups of all data and use it for testing and non-critical data but expect things might go wrong).
As well as being easy to use, it also has a nice list command (*CacheFS_List) which shows cached files and even has a -csv option to generate pretty ouput.
CacheFS is not on general release yet, but I am sure RISCOS Developments would be happy to talk to anyone interested in trying it or helping to improve it.
When I first heard about CacheFS, I had a bit of a 'so what' response to it. Having tried it, I am really excited!
Iris
An obvious use for CacheFS is the Browser and Andrew also had a version of Iris running CacheFS. This makes a big difference on pages with lots of content to load!
The version of Iris itself is still the April edition. Lots of work going on behind the scenes to update it to a later version of WebKit and to fix those last issues before a general release can happen. As a software developer myself, I know the final part of moving from Beta to release quality is always the hardest bit!
Final thoughts
So some really exciting exciting news from RISC OS Developments on software developments (the R-Comp stuff Andrew showed was also pretty cool as well but that is another article).
And a reminder you really should be showing up to the WROCC talks if you do not want to miss out...
| |
CachesFS and Iris update from WROCC November meeting |
| |
nunfetishist (11:45 10/11/2023)
Elesar (08:34 11/11/2023)
markee174 (09:01 11/11/2023)
richw (17:00 12/11/2023)
arawnsley (22:37 12/11/2023)
richw (18:29 13/11/2023)
arawnsley (00:25 14/11/2023)
|
| |
|
Rob Kendrick |
Message #125519, posted by nunfetishist at 11:45, 10/11/2023 |
 Today's phish is trout a la creme.
Posts: 522
|
Is this WSS CacheFS that shipped in NCOS? |
| |
 [ Log in to reply ] |
| |
|
Robert Sprowson |
Message #125520, posted by Elesar at 08:34, 11/11/2023, in reply to message #125519 |
Member
Posts: 41
|
Is this WSS CacheFS that shipped in NCOS? That seems unlikely, the NCOS version is still in the closed part of the ROOL repository, maybe you're thinking of CacheFS by David O'Shea for use with Browse?
So the question is: which one of the 3 modules got in first and allocated the name 'CacheFS' and which 2 should be in the naughty corner? |
| |
[ Log in to reply ] |
| |
|
Mark Stephens |
Message #125522, posted by markee174 at 09:01, 11/11/2023, in reply to message #125520 |
Does all the
work around here
Posts: 144
|
Is this WSS CacheFS that shipped in NCOS? That seems unlikely, the NCOS version is still in the closed part of the ROOL repository, maybe you're thinking of http://homepage.eircom.net/~djkoshea/cachefs.html">CacheFS by David O'Shea for use with Browse?
So the question is: which one of the 3 modules got in first and allocated the name 'CacheFS' and which 2 should be in the naughty corner?
Maybe all three are in the naughty corner! How would they allocate the name correctly? |
| |
[ Log in to reply ] |
| |
|
Richard Walker |
Message #125524, posted by richw at 17:00, 12/11/2023, in reply to message #125522 |
Member
Posts: 66
|
From what I remember of the NC-related CacheFS, it was like a RAM disk but would auto expire the less used (or was it oldest?) items to make space for new. Presumably the idea was to use it to house the browser's disk cache.
One thing I didn't understand about R-Comp's solution is that there was a mention of apps benefiting from 'tweaking' to fully harness CacheFS. This makes no sense to me. Surely it's transparent? |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #125526, posted by arawnsley at 22:37, 12/11/2023, in reply to message #125524 |
R-Comp chap
Posts: 594
|
First let me correct that for you - RISC OS Developments' solution. Wouldn't want to give the wrong idea 
The user still has the choice to load things direct from the base filing system, or from the CacheFS# version. CacheFS doesn't replace the base filing systems because that could potentially be a problem if something didn't work as expected. It is an overlay filing system, like Computer Concepts' old !CFS, as I have explained in the talk.
If the user access the CacheFS# version of things, then everything is transparent and works as before. But they choose to do so.
However, an application author may know that their application benefits from CacheFS significantly (eg. Iris or PDF renderer), they might choose to add code to read from CacheFS#<file> rather than just <file> so that the performance gain is transparent to the user regardless.
Essentially, if you bake it into an app, you can avoid the user needing to understand and do it manually. There's no need to do so, but doing so can give a more seemless experience.
Why not make CacheFS "take over" everything? IMHO software shouldn't take over in that manner unless it is darned sure that it is perfect in every situation. That would, I think, be rather presumptous for beta software. |
| |
[ Log in to reply ] |
| |
|
Richard Walker |
Message #125527, posted by richw at 18:29, 13/11/2023, in reply to message #125526 |
Member
Posts: 66
|
Thanks Andrew. I did listen to the talk, as that's what prompted my question. And apologies for the ROD/RC mix-up - and that's even with your fashion accessory in play!
Your app-tweak explanation makes sense. I can't decide if it's a bit yucky for two reasons:
1. The App author is baking in a requirement for CacheFS, unless I guess, they code it in a way to gracefully fail.
2.I think your ultimate aim should be to 'take over'. Just do it on everything. It's a beta. If it causes issues, people can turn it off and report bugs or whatever.
I also vaguely recall the CFS mechanism. They had some amazing ideas those CC guys!  |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #125528, posted by arawnsley at 00:25, 14/11/2023, in reply to message #125527 |
R-Comp chap
Posts: 594
|
Thanks for the feedback.
I don't think it is unreasonable to "bake in" cachefs support as it will be free, and can be bundled with apps that need it.
Also, the example code in the zip shows how to do a simple if statement to handle cachefs availability, so it should be pretty easy to deal with.
I will give some thought to an "always on" mode.
We certainly want to be careful if/when we do write caching though, as that needs to be handled with care - a lot of data will be critical and shouldn't be buffered in case of power outage or crashes. |
| |
[ Log in to reply ] |
| |
|
