From owner-freebsd-current@freebsd.org Tue Aug 8 11:26:32 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 A86E1DD5360 for ; Tue, 8 Aug 2017 11:26:32 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 210D48172D for ; Tue, 8 Aug 2017 11:26:31 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LzGV3-1daJVm13OT-014Sqz; Tue, 08 Aug 2017 13:26:23 +0200 Date: Tue, 8 Aug 2017 13:26:21 +0200 From: "O. Hartmann" To: Cy Schubert , Warner Losh Cc: "O. Hartmann" , freebsd-current Subject: Re: [autofs] problems with "dirty" UFS2 partitions Message-ID: <20170808132621.1f14cc1d@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <201708080648.v786mFic090494@slippy.cwsent.com> References: <20170808071758.6a815d59@freyja.zeit4.iv.bundesimmobilien.de> <201708080648.v786mFic090494@slippy.cwsent.com> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Kz+iOcyYOr/9LiN4w+GGY5PK/XCtgcYxD+jP6WUjfWimF4EPhww 3xOpMLq3pj5nizslbEz34JtWaPxRQWmrR/Y7NVPFjUabQ4Jgmv589s645AWzJpaSpeV2WFq FTTvLmRw6Tfdql2eXbtyM7Mag5QjwwqKoZcZBzHG3hz8jMSvDKxuEvp49ARawOZA4W2CqqU AZRmf9PmETEIx/ddqmTdw== X-UI-Out-Filterresults: notjunk:1;V01:K0:G3nNvYhX+yM=:xF/fkpSRiNlT7IAAIczPAi N+X3WQ+M/Ps8HxX53Ctokh+WSYtks7R5HiOA7YPlMcOlCSIfh4H6hUUNQfVeZ6tSlxzyVGyMm wY7tyEfWluZpNANoi63JRjfEJ9Tqw/CXQDQlznwcaWzP6almBbG47mxiG0M1uebuojAAnAC9J fblC0hbUtd9tIHll714O/IAWV/70XcPBdNJVL3kZipMSuevBwWI9pAGGNYBCFmTZ6miSnGf7I IaaeuJK2odiP3UJzX+gIiBPSsZ/sOm4B4e6F1fBMunUPW3dwyAViSO1CX5RxA0kakFp7CP1Tp 7DWnk6MhZ0wPZ6RioxfJRRHsIO3w/wj+E6Y4L5+23/81Jf2lzbUtXnYsAgM7tbdJuo1FtSRNN iTW5eTIk0xwWOwJLctf9YTFM1wYs6NkBJ0xmvWcUdcPrB/88fLAKCyc0OW0gSQZpjtTIIhid9 O8BDN9z9XtwcMoO7tV51+/vQkCQSVCSDpzyoP1Hem3kShyf5NmpyvepuOU8aS1m8QsxulKEeE w2SGHhBusvwL51cYNQNQf+aupjw12uyCFaYYaevJpzPLRzP18AUYSPtTv12fA6YbIwK2zPd+W HBInB/dRDZzg8YJ5uNTqsXr9UQIZvzElt75GZtW6DnvdmhwqqAlgFMW10aYr9V93p47Ge/Tne oI1QqgcQO8sZ1p4Kn9kpSRyKPVJg1J0UWC738iCexOKF5cB8+52hCwy4v4YEnTL9KqCH7eStZ YmfLya9SAJdwSufNAoQuStFxQEQDIqoZiPQ6DXuy5d44Kx9F5UE9SAEE1fPbnpP/BRyHQSQrr n0lw8m4Iin4r+pldpkiCdcx0kDNeEZBrAlFwPMfg46uu139lg0= X-Mailman-Approved-At: Tue, 08 Aug 2017 11:38:13 +0000 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 11:26:32 -0000 On Mon, 07 Aug 2017 23:48:15 -0700 Cy Schubert wrote: Just for convenience, I 'glued" Warner Losh's messages below and reply inline as usual. > 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. The system in question is logging onto this mSATA SSD and the filesystem is mounted/unmounted via autofs. I do not see any syystem/core faults when doing a reboot and the cases, where the filesystem is unclean after a reboot are rare. But it is even deadly if the system is required to log (it is a routing/PBX/DNS/firewalling system with FAX and answering machine/recording facilities). The only clue I have is that due to the unmount attempt of autounmountd while still writing logging data the filesystem remains in an unclean condition. But the question is then what is causing this condition. > > 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. Is this also possible with the in-kernel autofs facility? I replaced the amd daemon by the more modern autofs feature and - sorry - I didn't look into the man page while writing the mail. I'll check that out. The main question is, if the above described condition of writing log data and unmount at the same time results in an unresolvable race condition, to simply mount the SSD filesystem via /etc/fstab. The box is booting off a SD card, the mSATA SSD is for loggin/data only and I wanted it to make it as robust as possible with the main on having the firewall/router online to let traffic traverse instead of being blocked when the system fails mounting a filesystem, which is not necessary for survival. To have log or to have traffic passing is the essential question to answere here ... > > [from Warner Losh] > Can't you just list them in /etc/fstab with the noauto option, but with a > non-zero number listed in the 'pass' number column? I know nanobsd doesn't > generate things this way, but maybe it should.... > > Warner I haven't though of this ever - will it force a check of a dirty filesystem even when it is mounted via autofs? I considered /etc/fstab and autofs as mutual exclusive - in my naive view ... Thank you very much, Oliver