svn commit: r306012 - head/etc/autofs

[Bruce Evans]

On Tue, 20 Sep 2016, Edward Tomasz Napierala wrote:

> On 0920T1653, Bruce Evans wrote:
>> On Tue, 20 Sep 2016, Edward Tomasz Napierala wrote:
>>
>>> Log:
>>>  Fix -media to not mount ufs with "async"; it doesn't make sense when
>>>  there is softupdates.
>>
>> It does make sense when there isn't soft updates.  With soft updates, it
>> is silently ignored.
>
> True.  It might be possible to make special_media to check whether softdep
> is enabled using tunefs(8).

But nothing is needed for soft updates, since it silently ignores being
misconfigured with async.  Not that I like this...

>> However, I don't like changing the default.  async gives less robustness
>> and noatime breaks POSIX conformance.

... I also don't like noatime being silently ignored by file systems that
don't support it, e.g., nfs.  nfs just gives the noatime policy of the
server without telling you what that policy is.

> I liked the previous defaults too, until I've started to use this more
> often.  For things like SD cards, "sync" is just annoyingly slow.

"sync" is too slow for everything, but the default is neither async or
sync for any of ffs, msdosfs or extfs.  The default (without soft updates)
works OK only for large files since there are not many metadata updates
then.

>> I use async a lot, but rarely for removable backup media except for the
>> first use, and noatime almost always, and type a lot of mount commands,
>> mostly using shell history to retrieve nearly-correct options and then
>> edit just to toggle ro/rw and async/noasync flags.
>
> Btw, /etc/autofs is in /etc for a reason - so that the system administrators
> can tweak it.

The best tweaks are device-dependent and probably not well known.  I don't
have much hardware, but find that a USB3 disk drive works almost as well
as a SATA drive and doesn't need async hacks, but a USB3 memory drive is
almost as slow as USB2 memory drives and DVDs for writing.  All of the
latter have large write latency and probably large wear in the slow cases,
and no file system in FreeBSD (except maybe nandfs) understands this.
Clustering stops at 128K, but that is not large enough and only helps for
individual files and never helps for metadata.  Removable media tends to
have dumber controllers that don't compensate for this.

Bruce