From owner-freebsd-hackers@freebsd.org Sun Jul 12 20:13:00 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 17F8436D5A4 for ; Sun, 12 Jul 2020 20:13:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4dHv04ZHz40p2 for ; Sun, 12 Jul 2020 20:12:58 +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 06CKCoJp040985 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 23:12:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 06CKCoJp040985 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 06CKCo3j040984; Sun, 12 Jul 2020 23:12:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 12 Jul 2020 23:12:50 +0300 From: Konstantin Belousov To: Eugene Grosbein Cc: Freebsd hackers list Subject: Re: fsync(2) Message-ID: <20200712201250.GC44314@kib.kiev.ua> References: <0cdc3315-0213-8522-c8d6-695c2ee02923@grosbein.net> <20200712190517.GA44314@kib.kiev.ua> <12fb648f-8c37-be9b-f18a-5dc2ec9a09c9@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12fb648f-8c37-be9b-f18a-5dc2ec9a09c9@grosbein.net> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4B4dHv04ZHz40p2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [0.92 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.31)[0.306]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(0.44)[0.444]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.17)[0.172]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 20:13:00 -0000 On Mon, Jul 13, 2020 at 02:55:32AM +0700, Eugene Grosbein wrote: > 13.07.2020 2:05, Konstantin Belousov wrote: > > > On Mon, Jul 13, 2020 at 01:49:22AM +0700, Eugene Grosbein wrote: > >> Hi! > >> > >> Assume we have parent process that created a file and keeps it open not writing anything there. > >> The parent spawns a child passing file name and the child opens it, > >> fills it with data and exits without fsync()'ing the file. > >> > >> In case of UFS there is upto 30 seconds time gap when file size is not updated, > >> so if crash occurs, the file ends up empty. > >> > >> The question: will fsync() in parent work for such still open file descriptor? > > > > fsync() syncs the vnode, not the file or file descriptor. So fsync() on > > any file descriptor referencing the same vnode, is enough to ensure that > > the data is written to the underlying volume. > > Thanks! This seems to be undocumented. > > https://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html does not mention > implementation details (and could not) but our manual page could be improved, could it? Our manual page for fsync(2) is already good enough IMO. It talks about modified data of file. 'With the kernel-colored glasses', it means the vnode there, but describing the fine difference between file and (vnode, inode) is perhaps too much of useless details for normal application writer.