<div dir="ltr"><div class="gmail_default" style="font-size:small">On Fri, Dec 14, 2018 at 2:57 AM Lars Ellenberg <<a href="mailto:lars.ellenberg@linbit.com">lars.ellenberg@linbit.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 12, 2018 at 10:16:09AM +0100, Harald Dunkel wrote:<br>
> Hi folks,<br>
> <br>
> using drbd umounting /data1 takes >50 seconds, even though the file<br>
> system (ext4, noatime, default) wasn't accessed for more than 2h.<br>
> umount ran with 100% CPU load.<br>
> <br>
> # sync<br>
> # time umount /data1<br>
> <br>
> real 0m52.772s<br>
> user 0m0.000s<br>
> sys 0m52.740s<br>
> <br>
> <br>
> This appears to be a pretty long time. I am concerned that there<br>
> is some data sleeping in a buffer that gets flushed only at umount<br>
> time.<br>
> <br>
> Kernel is version 4.18.0-0.bpo.1-amd64 on Debian Stretch. drbdutils<br>
> is 8.9.10-2. drbd.conf is attached. The bond2 interface used for<br>
> drbd synchronization is based upon 2 * 10 Gbit/sec NICs.<br>
> <br>
> Every insightful comment is highly appreciated.<br>
<br>
Unlikely to have anything to do with DRBD.<br>
<br>
since you apparently can reproduce, monitor<br>
grep -e Dirty -e Writeback /proc/meminfo<br>
and slabtop before/during/after umount.<br>
<br>
Also check sysctl settings<br>
sysctl vm | grep dirty<br clear="all"></blockquote><div><br></div><div style="font-size:small" class="gmail_default">Good point, people running servers with huge amount of ram should understand there is also a huge amount of cache that needs to get flushed to the device before it gets removed.</div></div></div>