To get an idea of the efficiency of EPRD caching I repeated the lessfs benchmark test with EPRD caching the Intel 320 SSD.
The Intel 320SSD was registered as /dev/sdc.
EPRD was setup like this : ./eprd_setup -f /dev/sdc -m 3 -b -p 2048M
The databases eventually reach a size of 8.5 GB during this test.
As the graph’s show a user space application like Lessfs speeds up with EPRD even when it is used to cache a relatively fast medium like an Intel 320 SSD. I intend to test EPRD with a number of other applications as well. Candidates that come to mind are for example openldap and Mysql.
Was checking EPRD this morning, looks really interesting! Just a couple of thoughts:
I was just thinking if eprd can also act as a cache to speed up an existing slow disk based filesystems, somhow haven’t got the guts to just try it with one of my live filesystems ;o)
Also interesting would be if the cache in RAM can be saved, so the cache doesn’t need a full rebuild after a reboot.
Hope this helps.
Although to my best knowledge eprd-0.3.1 should be safe I would suggest not using EPRD for production until I release 1.0.
Extending the EPRD project to support automatic data tiering has been on my mind for some time.
And I have decided to at least investigate it.
Hi Maru
I think is very great way have “data tiering” at the moment there are no project with auto tier ssd+disk+ram perhaps other like bcache is near the corner but they need newer kernel.
Thanks in advance
Hello Maru,
first thanks for programming of lessfs.
I have question about EPRD. What are the benefits versus kernel disk cache? (assuming i have lot of ram)
Thanks in advance,
Hanz
eprd kernel module does not compile (or, actually, fails to insmod) on 32-bit (i686) systems; a simple fix changes that:
diff -dr eprd-0.4.0.b1/eprd.c eprd-0.4.0/eprd.c
136c136
cachesize / BLKSIZE * .66;
—
> low_water = dev->cachesize / BLKSIZE * 2 / 3;
although I am not completely sure it still works completely as intended, but at least it works.
Uh, should’ve htmlescaped that.
Anyway, paste.ubuntu.com/981504/
(though I suppose the required change is clear anyway)