From owner-freebsd-current@freebsd.org Tue Aug 8 06:49:40 2017 Return-Path: Delivered-To: freebsd-current@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 4600DDC6125 for ; Tue, 8 Aug 2017 06:49:40 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BC36722FE for ; Tue, 8 Aug 2017 06:49:39 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id eyKZdXiu4DJTWeyKadv3Kn; Tue, 08 Aug 2017 00:49:33 -0600 X-Authority-Analysis: v=2.2 cv=B4DJ6KlM c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=KeKAF7QvOSUA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=3tXEeKKawwdt6bmBpPUA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 2A79612E7; Mon, 7 Aug 2017 23:49:31 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v786mFic090494; Mon, 7 Aug 2017 23:48:15 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201708080648.v786mFic090494@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "O. Hartmann" cc: freebsd-current Subject: Re: [autofs] problems with "dirty" UFS2 partitions In-Reply-To: Message from "O. Hartmann" of "Tue, 08 Aug 2017 07:17:58 +0200." <20170808071758.6a815d59@freyja.zeit4.iv.bundesimmobilien.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Aug 2017 23:48:15 -0700 X-CMAE-Envelope: MS4wfCSqbeyFSXfBo7b7luBNFqO2RoooE8G33PJdZfEYQCVaAzgt/cUQxs7oGyjd/Upsn2TYKbF5gAtWtO0aQ0KNtGXxcOtH6acWPa3kYmj2tX91vK+soR4a Mw7jQ9vH8hIRDcGk1A35SMYH/JQ4Gfq/DkIRyi6ZDJUA3TDO+WB1IJ9eXpe5y7Lddih096au9TYVOKT+iO2l6MUJGyGgNDytBP95SK4XXKmYdEcHk8fpx7HY X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 06:49:40 -0000 In message <20170808071758.6a815d59@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > Hello, > > we're running a NanoBSD based appliance which resides on a small SoC and > utilises a mSATA SSD for logging, database storage and mail folder. The > operating system is recent CURRENT as it is still under development. > > The problem ist, that from time to time, without knowing or seeing the reason > , > the automounted partitions become "dirty (UFS2 partitions, no ZFS dur to > memory and performance limitations). Journaling is enbaled. > > When the partitions on the SSD become "dirty", logging or accessing them isn' > t > possible anymore and for some reason I do not see any log entries reporting > this (maybe due to the fact all logs are going also to that disk since the lo > gs > would pollute the serial console/console and the console is used for > maintenance purposes/ssh terminal). > > Is it possible to - automated! - check the filesystem on bootup? As on ordina > ry > FreeBSD systems with fstab-based filesystems, this happens due to the > rc-init-infrastructure but autofs filesystems seem to be somehow standing asi > de > from this procedure. I'd be interested in finding out if your system either panicked or simply failed to unmount the filesystems in question during a boot or shutdown. Is the SSD being removed prior to FreeBSD having the chance to unmount it? I think if we answer These questions we're more than half way there. Warner has a good suggestion worth considering. Another option might be to use amd program maps. The program map being a program or script that would run fsck prior to issuing a mount. Having said that, this treats the symptom rather than addressing the cause. It's preferred to discover the cause so that autofs (or amd) can mount a clean filesystem. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.