Date: Mon, 07 Aug 2017 23:48:15 -0700 From: Cy Schubert <Cy.Schubert@komquats.com> To: "O. Hartmann" <ohartmann@walstatt.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: [autofs] problems with "dirty" UFS2 partitions Message-ID: <201708080648.v786mFic090494@slippy.cwsent.com> In-Reply-To: Message from "O. Hartmann" <ohartmann@walstatt.org> of "Tue, 08 Aug 2017 07:17:58 %2B0200." <20170808071758.6a815d59@freyja.zeit4.iv.bundesimmobilien.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201708080648.v786mFic090494>