quick fix for slow directory shrinking in ffs

[Konstantin Belousov]

On Wed, May 18, 2016 at 08:39:08AM +1000, Bruce Evans wrote:
> Looks good.
...

> 
> This should probably also be done for truncations with O_TRUNC at open
> time.  There are a couple of these in vfs_syscalls.c.  O_TRUNC is used
> much more than ftruncate() so the extra overhead from this would be
> more noticeable.  I think the implementation is not very good.  If
> open() with O_TRUNC or truncate with O_FSYNC or fsync() fails, then
> the file contents might be garbage.  So it would be better to do
> large truncations mostly async and only sync at the end.  *fs_truncate()
> could operate like that, but I think it takes the IO_SYNC flag as a
> directive to do the whole operation synchronously. A non-sync truncation
> followed by fsync() is likely to work better for ffs and just work for
> all fs's.

I see only two places which calls fo_truncate() in vfs_syscalls.c,
after O_TRUNC test.  Both cases are after some kind of open, and
the mechanism from my patch does synchronous truncation automatically
for the callers.

Of course, truncation errors from O_TRUNC in open are fatal, and the
precious file (otherwise O_SYNC would be not specified at all) is in
undefined and damaged state if that happens. From this point of view,
O_TRUNC was bad idea.

I looked at POSIX text, and while ftruncate(2) is allowed to return e.g.
EIO, for open(2) EIO is not listed in case of truncation problems.
I am not sure if generic rules of POSIX allow to say that the condition
is undefined.  Implementation cannot handle that without loss.