From owner-freebsd-bugs@freebsd.org Tue Nov 21 17:08:16 2017 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E00DDF4557 for ; Tue, 21 Nov 2017 17:08:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C29E7661F for ; Tue, 21 Nov 2017 17:08:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vALH8Gfg097807 for ; Tue, 21 Nov 2017 17:08:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 223786] Remounting a UFS filesystem read-only takes very long time Date: Tue, 21 Nov 2017 17:08:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mi@ALDAN.algebra.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 17:08:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223786 Bug ID: 223786 Summary: Remounting a UFS filesystem read-only takes very long time Product: Base System Version: 10.4-STABLE Hardware: Any OS: Any Status: New Keywords: regression Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: mi@ALDAN.algebra.com I usually keep my / mounted read-only -- mostly for safety. When I need to change some aspect of configuration or add a port, I remount rw, do what ne= eds doing, and then remount back to read-only mode. This worked for me for many years, but lately I noticed, the remounting bac= k to the ro-mode is taking longer than it used to. Many seconds, especially, whe= n it was active shortly before the remount command. Today, however, with the freshly rebuilt kernel (FreeBSD 10.4-STABLE #15 r325999M), it takes well over a minute! A minute, during which the machine largely freezes -- for example, making new logins impossible. I understand the need to flush the unwritten to disk, when switching to ro,= but just how much should that take in the scenario I just had: 1048 11:56 mount -orw -u / 1049 11:56 chmod u+s /opt/cyrus/bin/deliver 1050 11:56 mount -oro -u / ? The second remount took well over minute and it seems wrong. The filesystem is based on SSD and looks like: /dev/ada0s1a on / (ufs, NFS exported, local, read-only) `tunefs -p /` reports: tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 1048576 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 0 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) --=20 You are receiving this mail because: You are the assignee for the bug.=