| xj | b04a402 | 2021-11-25 15:01:52 +0800 | [diff] [blame] | 1 | The writecache target caches writes on persistent memory or on SSD. It |
| 2 | doesn't cache reads because reads are supposed to be cached in page cache |
| 3 | in normal RAM. |
| 4 | |
| 5 | When the device is constructed, the first sector should be zeroed or the |
| 6 | first sector should contain valid superblock from previous invocation. |
| 7 | |
| 8 | Constructor parameters: |
| 9 | 1. type of the cache device - "p" or "s" |
| 10 | p - persistent memory |
| 11 | s - SSD |
| 12 | 2. the underlying device that will be cached |
| 13 | 3. the cache device |
| 14 | 4. block size (4096 is recommended; the maximum block size is the page |
| 15 | size) |
| 16 | 5. the number of optional parameters (the parameters with an argument |
| 17 | count as two) |
| 18 | start_sector n (default: 0) |
| 19 | offset from the start of cache device in 512-byte sectors |
| 20 | high_watermark n (default: 50) |
| 21 | start writeback when the number of used blocks reach this |
| 22 | watermark |
| 23 | low_watermark x (default: 45) |
| 24 | stop writeback when the number of used blocks drops below |
| 25 | this watermark |
| 26 | writeback_jobs n (default: unlimited) |
| 27 | limit the number of blocks that are in flight during |
| 28 | writeback. Setting this value reduces writeback |
| 29 | throughput, but it may improve latency of read requests |
| 30 | autocommit_blocks n (default: 64 for pmem, 65536 for ssd) |
| 31 | when the application writes this amount of blocks without |
| 32 | issuing the FLUSH request, the blocks are automatically |
| 33 | commited |
| 34 | autocommit_time ms (default: 1000) |
| 35 | autocommit time in milliseconds. The data is automatically |
| 36 | commited if this time passes and no FLUSH request is |
| 37 | received |
| 38 | fua (by default on) |
| 39 | applicable only to persistent memory - use the FUA flag |
| 40 | when writing data from persistent memory back to the |
| 41 | underlying device |
| 42 | nofua |
| 43 | applicable only to persistent memory - don't use the FUA |
| 44 | flag when writing back data and send the FLUSH request |
| 45 | afterwards |
| 46 | - some underlying devices perform better with fua, some |
| 47 | with nofua. The user should test it |
| 48 | |
| 49 | Status: |
| 50 | 1. error indicator - 0 if there was no error, otherwise error number |
| 51 | 2. the number of blocks |
| 52 | 3. the number of free blocks |
| 53 | 4. the number of blocks under writeback |
| 54 | |
| 55 | Messages: |
| 56 | flush |
| 57 | flush the cache device. The message returns successfully |
| 58 | if the cache device was flushed without an error |
| 59 | flush_on_suspend |
| 60 | flush the cache device on next suspend. Use this message |
| 61 | when you are going to remove the cache device. The proper |
| 62 | sequence for removing the cache device is: |
| 63 | 1. send the "flush_on_suspend" message |
| 64 | 2. load an inactive table with a linear target that maps |
| 65 | to the underlying device |
| 66 | 3. suspend the device |
| 67 | 4. ask for status and verify that there are no errors |
| 68 | 5. resume the device, so that it will use the linear |
| 69 | target |
| 70 | 6. the cache device is now inactive and it can be deleted |