Date: Wed, 18 May 2016 02:11:50 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: fs@freebsd.org Subject: Re: quick fix for slow directory shrinking in ffs Message-ID: <20160517231150.GG89104@kib.kiev.ua> In-Reply-To: <20160518081302.X6396@besplex.bde.org> References: <20160517072705.F2157@besplex.bde.org> <20160517082050.GX89104@kib.kiev.ua> <20160517192933.U4573@besplex.bde.org> <20160517111715.GC89104@kib.kiev.ua> <20160518035413.L4357@besplex.bde.org> <20160518052656.R5764@besplex.bde.org> <20160517212227.GE89104@kib.kiev.ua> <20160518081302.X6396@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160517231150.GG89104>