Bcache versus btier
After my previous post about bcache , I was advised to use a faster btier. After some time, the opportunity to try it in combat conditions. This post will be about comparing two different approaches to speeding up hard drives ...
Bcache relies on data caching. If the data has been read one or several times, they will most likely be cached and the next time they will be read from the cache. The main acceleration is obtained when caching random read operations. Therefore, according to bcache, it is unlikely that it will speed up sequential read operations, and a large file will not force many small ones out of the cache. But here the problem arises, how to determine whether the read operation that has just begun will be sequential, or will there be many of them and to different small files? Of course, for each process, you can cache the last N blocks, and if all N + 1 blocks go in a row, do not enter this data into the cache. In this case, there will be a large load on the memory and the decision on the length of the read operation will be obtained only when this length has exceeded or did not exceed a certain threshold. Bcache uses another solution. For each process, the moving average of the read operation is stored. If it is longer than the sequential_cutoff parameter, the read process data will not get into the cache. Another interesting solution worth mentioning is the high load threshold. Suppose if many requests for read operations come at the same time and all of them fall on data that is cached. The cache will be overloaded, and hdd will be idle. For such cases, there is a congested_read_threshold parameter that sets the time in milliseconds that the read operation waits in the cache queue, after which the request goes to hdd. The same parameter exists for a write operation. All this mechanics is configured or disabled as desired, which is very useful when it is necessary to adjust the parameters of bcache for a difficult task.
Btier is much simpler, but that does not mean worse. :) It just uses a different approach to speed up the work with data - multilayer discs (tell me a more accurate translation). The idea is very simple: the disks stick together among themselves from faster, to slower. Data blocks that are more commonly used — are transferred to a fast disk, data blocks that have not been used for a long time — are transferred to a slow disk. Migration occurs at a configurable interval. But if someone actively uses the disk, there will be no migration. The popularity statistics of the blocks is accumulated over a period of time, and if there are no hits to the block, it migrates to the slowest disk. Everything is simple, fast enough and for some tasks very efficiently.
')
There is no universal solution. It is also impossible to say that btier is better than bcache, or bcache is better than btier. They help in solving one problem. But their effectiveness is very dependent on the specific task. I import the OpenStreetMap data into the database and try to speed up this process. For this task, bcache is better suited, since all work rests on iops and disk speed - it caches necessary data faster on ssd and quickly adapts to the needs of the import process. On the other hand, after importing, you have to perform a lot of queries on the resulting database and these requests, some of the time run into the processor, and some of the time against the disk. In this case, btier will be able to migrate popular blocks to ssd when the disk is idle, and speed up the work of requests that used to run into the disk.
Bcache
Bcache relies on data caching. If the data has been read one or several times, they will most likely be cached and the next time they will be read from the cache. The main acceleration is obtained when caching random read operations. Therefore, according to bcache, it is unlikely that it will speed up sequential read operations, and a large file will not force many small ones out of the cache. But here the problem arises, how to determine whether the read operation that has just begun will be sequential, or will there be many of them and to different small files? Of course, for each process, you can cache the last N blocks, and if all N + 1 blocks go in a row, do not enter this data into the cache. In this case, there will be a large load on the memory and the decision on the length of the read operation will be obtained only when this length has exceeded or did not exceed a certain threshold. Bcache uses another solution. For each process, the moving average of the read operation is stored. If it is longer than the sequential_cutoff parameter, the read process data will not get into the cache. Another interesting solution worth mentioning is the high load threshold. Suppose if many requests for read operations come at the same time and all of them fall on data that is cached. The cache will be overloaded, and hdd will be idle. For such cases, there is a congested_read_threshold parameter that sets the time in milliseconds that the read operation waits in the cache queue, after which the request goes to hdd. The same parameter exists for a write operation. All this mechanics is configured or disabled as desired, which is very useful when it is necessary to adjust the parameters of bcache for a difficult task.
Virtues
- Flexible configuration options.
- Filling cache while running heavy tasks.
- Automatic initialization at boot time.
- Can work in caching mode as read, read and write.
- Included in the kernel since version 3.10.
disadvantages
- Before the cache will be useful, it must be filled, and the speed increase will not be instant.
- If a process reads a large file and, at the same time, it often accesses small files, these frequent small read operations will most likely not get into the cache, although they could seriously speed up the work.
- There cannot be several SSDs in the cache.
Btier
Btier is much simpler, but that does not mean worse. :) It just uses a different approach to speed up the work with data - multilayer discs (tell me a more accurate translation). The idea is very simple: the disks stick together among themselves from faster, to slower. Data blocks that are more commonly used — are transferred to a fast disk, data blocks that have not been used for a long time — are transferred to a slow disk. Migration occurs at a configurable interval. But if someone actively uses the disk, there will be no migration. The popularity statistics of the blocks is accumulated over a period of time, and if there are no hits to the block, it migrates to the slowest disk. Everything is simple, fast enough and for some tasks very efficiently.
')
Virtues
- You can combine multiple disks.
- The volume of ssd disks is added to the total volume.
- During the growth of btier data is placed primarily on fast disks.
- High speed after starting work.
- Easily assembled as a module to the current kernel.
disadvantages
- Reliability like RAID-0
- Migration occurs when btier is idle. During the hard task for the disk, you can not hope that the data migrates to a faster disk.
- If we run some heavy tasks on a partition with btier, all data gradually migrates to the slowest disk.
Total
There is no universal solution. It is also impossible to say that btier is better than bcache, or bcache is better than btier. They help in solving one problem. But their effectiveness is very dependent on the specific task. I import the OpenStreetMap data into the database and try to speed up this process. For this task, bcache is better suited, since all work rests on iops and disk speed - it caches necessary data faster on ssd and quickly adapts to the needs of the import process. On the other hand, after importing, you have to perform a lot of queries on the resulting database and these requests, some of the time run into the processor, and some of the time against the disk. In this case, btier will be able to migrate popular blocks to ssd when the disk is idle, and speed up the work of requests that used to run into the disk.
Source: https://habr.com/ru/post/201944/
All Articles