Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Le -10/01/-28163 20:59, Lars Ellenberg a écrit : > (...) Please be aware that a system that is catching up > from "Behind" mode is "Inconsistent" locally, just as a SyncTarget is, > until the connection mode becomes "Connected" once again.(...) Yes, I am aware of this. Will that trigger the before-resync-target and after-resync-target scripts, to let us do safety LVM snapshots? > "free" buffer/page chache settings are no indication of whether things > are dirty or not, or currently under write-out or not. > This is something completely differnt.(...) Absolutly: now that I know what to expect, I watch nr_dirty in /proc/vmstats. Actually I have a script watch it, and disconnect the DRBD resource before too many pages get dirty, and reconnects when nr_dirty gets low enough. On our workload with no frequent sync(), that does a sort of congestion management. I admit it's not very predictable - and tuning the kernel writeback is a pretty subtle work. > (...) Dirty pages are those pages that have not yet been written to stable > storage, neither local nor remote. > > These are modifications living in volatile main RAM only. > In the event of crash/power out age, > these modifications are lost. Indeed, I don't advise anyone else to use a high vm.dirtyratio with DRBD over a slow network because of the risk of data loss. > And that has nothing to do with replication, or RAID, or storage > backend. If you just did not submit things to the block layer yet, > there is just nothing the block layer can do to preserve these changes. > > [application] > [filesystem layer] > [page cache (buffer cache)] > -------------- > things that are accounted in "free" as buffers/cached live above this > line, both clean (identical as on stable storage, as far as the OS > knows; useful as "read cache"), and dirty (yet to be submitted and > confirmed to be on stable storage). > -------------- > [block layer]<--- that is where DRBD lives > [DRBD] > +--- ["local" storage] > | > N| > E|<--- this is where the DRBD proxy lives > T| > | > [remote DRBD] > `-- ["remote" storage] Totally agreed. > Don't hesitate to give us a call. I'm discussing drbd-proxy with Linbit's sales dept. already, thanks. Thanks for your answers. Lionel