From owner-freebsd-fs@freebsd.org Tue May 17 23:11:57 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 150EDB40E1A for ; Tue, 17 May 2016 23:11:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F209A1D52 for ; Tue, 17 May 2016 23:11:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id F1559B40E19; Tue, 17 May 2016 23:11:56 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0F75B40E18 for ; Tue, 17 May 2016 23:11:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71FD11D51 for ; Tue, 17 May 2016 23:11:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u4HNBpVC033011 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 May 2016 02:11:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4HNBpVC033011 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4HNBoea033010; Wed, 18 May 2016 02:11:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 May 2016 02:11:50 +0300 From: Konstantin Belousov To: Bruce Evans Cc: fs@freebsd.org Subject: Re: quick fix for slow directory shrinking in ffs Message-ID: <20160517231150.GG89104@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160518081302.X6396@besplex.bde.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 23:11:57 -0000 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.