You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+22Lines changed: 22 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,6 +93,14 @@ file="output1.txt"
93
93
occurrence=5
94
94
parts=3#or parts_bytes=[4096,3600,1260]
95
95
persist=[1,3]
96
+
97
+
[[injection]]
98
+
type="clear"
99
+
from="f1.txt"
100
+
timing="before"
101
+
op="fsync"
102
+
occurrence=6
103
+
crash=true
96
104
```
97
105
98
106
I recommend following the `simple` cache configuration (indicating the cache size and using a similar configuration file as `default.toml`), since it's currently the most tested schema in our experiments. Additionally, for the section **[cache]**, you can specify the following:
@@ -105,6 +113,7 @@ I recommend following the `simple` cache configuration (indicating the cache siz
105
113
106
114
-**torn-seq**: This fault type is used when a sequence of system calls, targeting a single file, is executed consecutively without an intervening `fsync`. *In the example*, during the second group of consecutive writes (the group number is defined by the parameter `occurrence`), to the file "output.txt", the first and fourth writes will be persisted to disk (the writes to be persisted are defined by the parameter `persist`). After the fourth write (the last in the `persist` vector), LazyFS will crash itself.
107
115
-**torn-op**: This fault type involves dividing a write system call into smaller parts, with some of these parts being persisted while others are not. In the example, the fifth write issued (the number of the write is defined by the parameter `occurrence`) to the file "output1.txt" will be divided into three equal parts if the `parts` parameter is used, or into customizable-sized parts if the `parts_bytes` parameter is defined. In the commented code, there's an example of using `parts_bytes`, where the write will be torn into three parts: the first with 4096 bytes, the second with 3600 bytes, and the last with 1200 bytes. The `persist` vector determines which parts will be persisted. After the persistence of these parts, LazyFS will crash.
116
+
-**clear-cache**: Clears unsynced data in a certain point of the execution. In the example above, this fault will be injected after (`timing`) the sixth (`occurrence`) `fsync` (`op`) to the file "f1.txt" (`from`). The `op` parameter must be a system call, and if it involves two paths (such as `rename`), the `to` parameter should also be specified. The `crash` parameter determines whether LazyFS should crash after the fault injection.
108
117
109
118
Other parameters:
110
119
@@ -209,6 +218,19 @@ Finally, one can control LazyFS by echoing the following commands to the configu
209
218
210
219
> Kills LazyFS before executing a link operation to the file pattern 'fileabd'.
211
220
221
+
- **Kill the filesystem** after injecting `torn-op` or `torn-seq`faults:
222
+
223
+
The parameters are the same as the ones presented in the above configuration file. Parameters that have multiple values, must be specified without the parenthesis (e.g., `persist=1,2` ).
LazyFS expects that every buffer written to the FIFO file terminates with a new line character (**echo** does this by default). Thus, if using `pwrite`, for example, make sure you end the buffer with `\n`.
* @brief Persists a write if a there is a programmed reorder fault for write in the given path and if the counter matches one of the writes to persist.
@@ -328,36 +361,6 @@ class LazyFS : public Fusepp::Fuse<LazyFS> {
0 commit comments