In message <>, 
"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 

Cy Schubert <>
FreeBSD UNIX:  <>   Web:

        The need of the many outweighs the greed of the few.

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to