On 0808T0717, O. Hartmann wrote: > 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 logs > 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 ordinary > FreeBSD systems with fstab-based filesystems, this happens due to the > rc-init-infrastructure but autofs filesystems seem to be somehow standing aside > from this procedure. There are several ways. The easiest of them - since you probably know the device name upfront - is what Warner suggested: add it to fstab(5) with the "noauto" option, and then maybe use the -noauto autofs map (see auto_master(5) man page to see what it does). If you don't know the exact device name, you could add a call to fsck to /etc/autofs/special_media, somewhere in print_map_entry() function. It's the script that automountd(8) runs to figure out what devices are available for mounting, and how to mount them. You might need to increase the vfs.autofs.timeout sysctl, though. Yet another would be to run fsck from devd(8), on "GEOM" event, as documented in devd.conf(5).Received on Thu Aug 10 2017 - 09:22:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC