quick fix for slow directory shrinking in ffs

[Bruce Evans]

On Wed, 18 May 2016, Bruce Evans wrote:

> On Tue, 17 May 2016, Konstantin Belousov wrote:
>> diff --git a/sys/ufs/ffs/ffs_inode.c b/sys/ufs/ffs/ffs_inode.c
>> index 0202820..50b456b 100644
>> --- a/sys/ufs/ffs/ffs_inode.c
>> +++ b/sys/ufs/ffs/ffs_inode.c
>> @@ -610,7 +610,7 @@ extclean:
>> 		softdep_journal_freeblocks(ip, cred, length, IO_EXT);
>> 	else
>> 		softdep_setup_freeblocks(ip, length, IO_EXT);
>> -	return (ffs_update(vp, !DOINGASYNC(vp)));
>> +	return (ffs_update(vp, (flags & IO_SYNC) != 0 || !DOINGASYNC(vp)));
>> }
>> 
>> /*
>
> Oops, this needs fixing in my version, but in -current the fix has
> little effect since in -current ffs_update() still dishonors the waitfor
> flag for its bwrite()/bdwrite() decision if DOINGASYNC().  This is
> essentially the same as dishonoring the IO_SYNC flag here.
>
> ffs_update() needs the same fix in 4 more places.

Also, ftruncate() seems to be broken.  POSIX doesn't seem to require it
to honor O_SYNC, but POLA requires this.  But there is no VOP_TRUNCATE();
truncation is done using VOP_SETATTR() and there is no way to pass down
the O_SYNC flag to it; in practice, ffs just does UFS_TRUNCATE() without
IO_SYNC.

This makes a difference mainly for async mounts with my fixes to honor
IO_SYNC in ffs_update().  With async mounts, consistency of the file
system is not guaranteed but O_SYNC for a file should at least cause
all of the file data and most of its metdata to be written.  Not syncing
for ftruncate() unnecessarily loses metadata writes.  With !async mounts,
consistency of the file system is partly guaranteed and lost metadata
writes for ftruncate() shouldn't affect this -- they should just lose
the ftruncate() atomically.

vfs could do an fsync() after VOP_SETATTR() for the O_SYNC case.  This
reduces the race window.

Bruce