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
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
