| 1 |
On 20/12/2021 18:52, Mark Knecht wrote: |
| 2 |
> The thing is that the ZIL is only used for synchronous writes and I |
| 3 |
> don't know whether anything I'm doing to back up my user machines, |
| 4 |
> which currently is just rsync commands, is synchronous or could be |
| 5 |
> made synchronous, and I do not know if the NFS writes from the R_Pi |
| 6 |
> are synchronous or could be made so. |
| 7 |
|
| 8 |
"Synchronous writes" basically means "in the order they were written". |
| 9 |
|
| 10 |
And it might also mean blocking writes, which is why you don't want it |
| 11 |
on spinning rust. But it also means that it is (almost) guaranteed to |
| 12 |
get to permanent storage, which is why you do want it for mail, |
| 13 |
databases, etc. |
| 14 |
|
| 15 |
Your typical (asynchronous) app calls "write", chucks it at the kernel, |
| 16 |
and forgets about it. Hence "asynchronous" - "without regard to time". |
| 17 |
|
| 18 |
Your app which has switched on synchronicity will lock until the write |
| 19 |
has completed. |
| 20 |
|
| 21 |
Your understanding about the ZIL sounds about right - whatever you throw |
| 22 |
at the NAS will be saved to the ZIL before it gets written properly |
| 23 |
later. Your apps (rsync etc) don't need to worry, the kernel will cache |
| 24 |
stuff, flood it through to the ZIL, and the NAS will take it from there. |
| 25 |
|
| 26 |
The only thing I'd worry about is how "bursty" is the data being chucked |
| 27 |
at the NAS. A backup is likely to be a stream that could easily |
| 28 |
overwhelm the buffers, and that's not good. Do you have an rsync daemon |
| 29 |
on the NAS? The more you can make the writes smaller and bursty the |
| 30 |
better, and running an rsync daemon is one of the ways. |
| 31 |
|
| 32 |
Cheers, |
| 33 |
Wol |
Archives