Is possible enable write defer-write ?

[Augusto7743]

Hello rapiddisk creator.
I wait to use your software to write cache using an time latency in system and user data partitions formated with BTRFS.
Is possible enable write defer-write ? If yes possible what command to enable an write cache with defer-write latency time ?
Thanks for read.

[pkoutoupis]

@Augusto7743 A deferred write would essentially be a write-back caching policy which rapiddisk is not designed to do at the moment, for a couple of reasons. The most important being that when write data is being cached to RAM, we cannot guarantee data integrity of the backing store in the event of a failure (i.e. power or other hardware).

Also, as it relates to btrfs, if btrfs is being used on more than a single volume, relying on solutions such as rapiddisk, dm-cache or bcache becomes very problematic, which is described in a tiny bit of detail here: https://btrfs.wiki.kernel.org/index.php/Project_ideas#dm_cache_or_bcache_like_cache_e.g._on_a_SSD

It would be nice though, if btrfs were to introduce an intent log (to an SSD) or some sort of ARC in RAM.

[Augusto7743]

Thanks for reply.
I understand the problems if using write-back caching, but if used with care help to be less write to disk.
In windows I had used Primocache configured to use deferwrite value infinite that only will flush write cache from RAM to disk when system is shutdown. That feature help to avoid repeated write in disk.
Using Primocache I had configured to use 256 MB for system partition. In 5 or 6 hours using the system was need more of 1,5 GB (system logs, browser files when accessing internet not being temp files and other files created by system or others softwares) writing on disk, but was avoided using primocache and even thus was used less of 180 MB of 256 cache buffer in RAM. If shutdown the system will be write 180 MB in disk thus avoiding useless 1,5 GB write in disk.
In windows I had used an partition for system and other for data that is the because of only 256 MB for write cache buffer in system partition.
In the data partition I had used 128 MB for write cache with flush interval of 240 seconds.
Understand ? write back for avoid repeated writes of same files on disk created by system and softwares.
An example Lubuntu since that was started to now that I only had accessed 3 or 4 web sistes without videos or animations was write in disk 50 MB even not saving any type of file. Using write cache perhaps will be even of half to write on disk.

Seeing in
http://manpages.ubuntu.com/manpages/bionic/man5/btrfs.5.html
have an section about commit
commit=seconds (since: 3.12, default: 30)
Set the interval of periodic transaction commit when data are synchronized to permanent storage. Higher interval values lead to larger amount of unwritten data, which has obvious consequences when the system crashes. The upper bound is not forced, but a warning is printed if it’s more than 300 seconds (5 minutes). Use with care.

I am new Linux user and wait not return to windows. I not understand exactly if the configuration value above is about exactly the feature that I wait use in write-back caching.

Rapiddisk have any command option to help to avoid repeated write in disk ? If yes what is the command ?
Any chance to add write cache to rapiddisk ? I not see any software or feature in Linux with write caching using an time to flush data to disk.

Thanks and have an nice week.

[pkoutoupis]

Sadly, today, Rapiddisk does not have such a command option. I am not sure if it will in the near future either. The implementation would be quite complicated. I would recommend that you look at dm-writecache (https://www.admin-magazine.com/HPC/Articles/Linux-Writecache) and possibly dm-cache. There may be some parameters or tunables in its module that will help you achieve what you are trying to achieve to delay flushing writes.

You also highlighting the commit interval for btrfs. Nearly all file systems have this mount option. You can test this one out as well.

[pkoutoupis]

It seems like dm-writecache does offer something similar with the autocommit_time and autocommit_blocks options:

autocommit_blocks n (default: 64 for pmem, 65536 for ssd)
when the application writes this amount of blocks without issuing the FLUSH request, the blocks are automatically committed
autocommit_time ms (default: 1000)
autocommit time in milliseconds. The data is automatically committed if this time passes and no FLUSH request is received

Closing since it will likely not be implemented in RapidDisk and function already exists in an upstream kernel module.

[pkoutoupis]

Note that a similar feature will be implemented as part of the #23 work.