Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 06/20/2012 01:43 PM, Shaun Thomas wrote: > I guess it would be pretty embarrassing if DRBD wasn't honoring fsync > under certain kernel combinations. For what it's worth, we have 8.3.10 > on our existing cluster pending upgrade, and fsync times are > definitely longer when both nodes are present. I wouldn't be surprised > if something in kernel 3.2.0 causes a subtle break here. The 2nd test I did, the one directly on a SATA disk, was with just one node present. I just never bothered to configure the 2nd node for the quick test. What OS and kernel version are you running? Also, when you say slower with both nodes present, is it slower enough to indicate that fsync is working? Or just slower because of network latency? In my case I expect latency would go up at least by the network RTT with both nodes present as well, but the RTT of 180us is almost two orders of magnitude smaller than the mean random access latency of my drives. In the case of small synchronous writes, I'd expect any difference in latency to be indistinguishable from measurement error. For that matter, is anyone absolutely sure that fsync is working on their DRBD devices? Any reproducible tests demonstrating such? At this point, I'm not sure if the behavior I'm expecting is supported in DRBD at all, or if it's something about my configuration or environment that's causing the issue. Before I go on a witch hunt installing different versions of things and pulling levers here and there I'd like to know that success is at least possible.