From owner-freebsd-current@freebsd.org Tue Aug 8 15:22:16 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 CA808DBDBBB for ; Tue, 8 Aug 2017 15:22:16 +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 9D575660BE for ; Tue, 8 Aug 2017 15:22:15 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id f6Khdb6HWMaqMf6Kidkhlt; Tue, 08 Aug 2017 09:22:14 -0600 X-Authority-Analysis: v=2.2 cv=Qc8WhoTv c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=KeKAF7QvOSUA:10 a=BWvPGDcYAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=jmRh8kgHxhs6vqX0nv4A:9 a=XDJE8Oj6bc3Dp2QF:21 a=SUjmoIluuCpRsCc-:21 a=CjuIK1q_8ugA:10 a=pxhY87DP9d2VeQe4joPk:22 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 8DB561928; Tue, 8 Aug 2017 08:22:10 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v78FKr3v083116; Tue, 8 Aug 2017 08:20:53 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201708081520.v78FKr3v083116@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: Cy Schubert , Warner Losh , "O. Hartmann" , freebsd-current Subject: Re: [autofs] problems with "dirty" UFS2 partitions In-Reply-To: Message from "O. Hartmann" of "Tue, 08 Aug 2017 13:26:21 +0200." <20170808132621.1f14cc1d@freyja.zeit4.iv.bundesimmobilien.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Aug 2017 08:20:53 -0700 X-CMAE-Envelope: MS4wfAaN2IaYEKLf/ZA1tpZflk2o91iG62cilSBKcmlEgcr95FMTZ4vLbNtPcOCa9rS+WDB7uNgvNQqN3z9CZhYEUI6SRnrM6aq1hH4bo4/e0FrgYWF7tn63 HOTwXFqFmXuHe6S41lsmjROQZ5VKl6/aVhdQJZaCP914ot89AbiDjf3LxFtWLYWMyK+YDB+ukx778utQK/jmKMsu3GFHsDQxRJbhgltv2jwFs1GAjql8Z156 vNk1ljFj3ri8KQBrGzaehoRTXfVgaPPOZEGlD/fXBvhRqDxwSMISqWdoi3hm3t7P 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 15:22:16 -0000 In message <20170808132621.1f14cc1d@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > 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 reporti > ng > > > this (maybe due to the fact all logs are going also to that disk since th > e > > > 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. Bu > t > the question is then what is causing this condition. It's not unmounting for this very reason. It can't. (Try umount of a filesystem which has files still open.) > > > > > 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 an > d > 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, th > e > 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 i > s > the essential question to answere here ... You could mount late or issue an fsck in rc.local. In rc.local, if it fails simply spit out an error message (or email). > > > > > > > > [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 -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.