You are not logged in.
Hi
I'm playing with lvm-cache and I'd like to try a ramdisk as a writethough cache. This needs a block device for lvm pvcreate to work (note tmpfs or - loop wont work). I can create /dev/ram0 using mknod -m 660 /dev/ram0 b 1 1. My issue is that this creates a 16MB ramdisk which is too small of a cache. In the past I've changed ramdisk size using a kernel boot parameter ramdisk_size=xxxx, which you could set in grub.conf. This does not seem to be an option with newer kernels (or I'm doing it wrong). Is there a way to change the default ramdisk size in 4.0.x kernels (hopefully without recompiling).
Thanks in advance.
Offline
It seems mount supports a type called ramfs , have you tried that ?
http://www.jamescoyle.net/how-to/943-cr … k-in-linux
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online
Thanks for the reply.
I'm not trying to mount a ramdisk, that is fairly simply with tmpfs or ramfs. I'm trying to create large ramdisk block devices i.e. /dev/ram0-15 The default is 16MB and I'm searching for how to create a 1GB ramdisk device.
Offline
I think you should load the brd module with all the necessary parameters, maybe think about using zram instead.
https://www.novell.com/support/kb/doc.php?id=7012396
https://www.kernel.org/doc/Documentatio … amdisk.txt
https://www.kernel.org/doc/Documentatio … v/zram.txt
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
brd module has a parameter called rd_size - it's probably what you are looking for.
There's also zram if you're looking for compression.
Offline
You could use tmpfs + losetup to turn it into a block device, but it might be less efficient than a real ram disk and it's not truly a ramdisk (in that tmpfs is allowed to use swap).
cd /dev/shm
truncate -s 1G tmpfs.img
shred -n 0 -z tmpfs.img
losetup --find --show tmpfs.imgOffline
See Documentation/blockdev/ramdisk.txt. Specifically the ramdisk_size parameter.
Offline
I think you should load the brd module with all the necessary parameters, maybe think about using zram instead.
https://www.novell.com/support/kb/doc.php?id=7012396
https://www.kernel.org/doc/Documentatio … amdisk.txt
https://www.kernel.org/doc/Documentatio … v/zram.txt
Awesome, modprobe brd rd_size=1024000 is just what I needed.
Thanks
Offline
@gps - So do you have a script you're calling that setups the needed partition on /dev/ram0 or does the cache function you require not need a partition? I'm also thinking about what advantages a block device ram disk offers that tmpfs does not offer beyond the one you mentioned.
Offline
@gps - So do you have a script you're calling that setups the needed partition on /dev/ram0 or does the cache function you require not need a partition? I'm also thinking about what advantages a block device ram disk offers that tmpfs does not offer beyond the one you mentioned.
I'm experimenting with using ram as a writeback cache to accelerate IO to HDD and SSD devices using dm-cache (via lvm). Here is what I'm trying:
. Create a 1GB /dev/ram0 using the steps figured out here - thanks all
. create lvm physical volume, pvcreate /dev/ram0 - note. pvcreate fails to add tmpfs and zram devices
. add /dev/ram0 pv to an existing volume group (vgextend vg /dev/ram0), with the other pv being a HDD or SSD
. add /dev/ram0 as a cache to an existing logical volume
"lvcreate --type cache -l +100%FREE --cachemode writeback -n data_cache_pool vg/lg /dev/ram0"
The above successfully adds the ramdisk as a writeback cache. Then I've being testing with fio benchmark runs (read, write, randrw etc.) both with and without the cache. The performance is better with the cache, but not by as much as I hoped. I believe dm-cache was design to use SSD as the cache for HDD, so not too shocking I guess.
note. with lvm-cache it is very easy to remove the caching device (advantage over bcache), so I can test with and without cache easily. lvconvert --uncache vg/lg
Todo
try the same with bcache
Offline
I'd worry about data consistency if you cache on RAM instead of an actual persistent storage device. These caching systems are probably designed for the latter...? And Linux already does ram caching for pretty much any VFS/block device for free.
# dd bs=1M skip=1000 count=1000 if=/dev/sda1 of=/dev/null
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 3.25367 s, 322 MB/s
# dd bs=1M skip=1000 count=1000 if=/dev/sda1 of=/dev/null
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.133742 s, 7.8 GB/sOffline
Todo
try the same with bcache
Maybe try flashcache too. It was written for SSDs but it looks like it'll work with whatever block device you give it?
Offline
I'd worry about data consistency if you cache on RAM instead of an actual persistent storage device. These caching systems are probably designed for the latter...? And Linux already does ram caching for pretty much any VFS/block device for free.
# dd bs=1M skip=1000 count=1000 if=/dev/sda1 of=/dev/null 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 3.25367 s, 322 MB/s # dd bs=1M skip=1000 count=1000 if=/dev/sda1 of=/dev/null 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 0.133742 s, 7.8 GB/s
Yes data consistency with a write-back cache is a concern, especially with ramdisks. However write-back caching is potentially still useful for temp/scratch files.
Linux does a great job of caching reads in RAM. I don't think it caches writes, which due to data consistency needs is the right behaviour.
Offline
It caches writes too. Write something and then see how long 'sync' takes. Or mount it in sync mode in the first place and then see how slow it is.
Offline
It caches writes too. Write something and then see how long 'sync' takes. Or mount it in sync mode in the first place and then see how slow it is.
Agreed, but apps like databases require a write acknowledgement via fsync even when you mount with async. In this case using a ramdisk as a cache in dm-cache may improve performance, albeit at the risk of data corruption.
Offline