In message <20170808071758.6a815...@freyja.zeit4.iv.bundesimmobilien.de>,
> 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'
> 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
> 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
> FreeBSD systems with fstab-based filesystems, this happens due to the
> rc-init-infrastructure but autofs filesystems seem to be somehow standing asi
> 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
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"