[DRBD-user] umount /drbdpart takes >50 seconds

[Lars Ellenberg]

On Fri, Dec 14, 2018 at 09:32:14AM +0100, Harald Dunkel wrote:
> Hi folks,
> 
> On 12/13/18 11:49 PM, Igor Cicimov wrote:
> > On Fri, Dec 14, 2018 at 2:57 AM Lars Ellenberg wrote:
> > 
> > 
> >     Unlikely to have anything to do with DRBD.
> > 
> >     since you apparently can reproduce, monitor
> >     grep -e Dirty -e Writeback /proc/meminfo
> >     and slabtop before/during/after umount.
> > 
> >     Also check sysctl settings
> >     sysctl vm | grep dirty
> > 
> 
> Attached. Hope this helps.
> 
> > 
> > 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.
> > 
> 
> I agree that the problem might be unrelated to drbd, but isn't sync
> supposed to flush page cache to the block device? The sample test I
> ran took 47 secs *after* the sync; see output.txt. sync itself took
> just a few millisecs.

There was nothing dirty (~ 7  MB; nothing worth to mention).
So nothing to sync.

But it takes some time to invalidate and shrink 20 million dentries
and inodes and 13 million buffer heads and associated caches.
Also, cpu bound now makes more sense.
Apparently no (or negligible) IO happening.
(you have 20 Gig in ext4_inode_cache alone...
I'm not surprised that umount takes "a while"). 

> Is sync broken for drbd?

Well, I don't think so.
But thank you for considering that ;-)

-- 
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker

DRBD® and LINBIT® are registered trademarks of LINBIT
__
please don't Cc me, but send to list -- I'm subscribed