Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110331 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 29736 invoked from network); 1 Jun 2020 21:14:46 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Jun 2020 21:14:46 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0D76A180556 for ; Mon, 1 Jun 2020 12:56:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 1 Jun 2020 12:56:28 -0700 (PDT) Received: by mail-ot1-f51.google.com with SMTP id h7so9056672otr.3 for ; Mon, 01 Jun 2020 12:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I8m6+Rd5PoMgci2Uw85VtMsDrXJswlEP719AD0sgKK4=; b=TYokMkT6/8He7pjvldUAz7wm6CAS5oWjVW0a+8oNaQJsk3KG2xUXLZ/EMWHDMJR1jV iqKE9V958vKbDOyQdYtfL9uIpdCQsBfpWA3QTqbaH34krwdmgB1zNzqNTqX3hFCo/0Dn mBMYRAmhMETY6+kVd0TwcppS97jiQbQIz1W3+zgQHrr2E5TdKEBkKhv3GCr8KKAGjeN7 +Gzqayc7IqBEaWFTqquGvdtPXOlyoeTwsXpc61IVGgLYeP7N23+RhBPSOyVDI+K+DHEE dOTPRxvBZWCDhn9hrhvpi/URVItIX6QBvOz5U7UiXFZtTNum9hFmYKahtSoOz7XNUStV uZbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I8m6+Rd5PoMgci2Uw85VtMsDrXJswlEP719AD0sgKK4=; b=MjQHjB/lgQHzonGjtslSBJ0+N2mccQpGW9xvDt2E2uIUp3l/Exmir/xYd/vQ2Lk4QO C8YnWYQZHJt8HrwEf0zK+hLVNfIyU1OeXec4Bn46kTvUQdB7uv6wIKPoJBaVErLbKlyu UcQGoxNXGZkBiSWQuhzerBKKcmqcrotR+PkZyLAiD3ZmM+qFSIPBiFKe0vx9+AOBfuxN hVR/ybVFcyyX/lOSkojnbA5XGDWt1LPN8b//IPKzInaC0uaRT2yPkVGhd5sNQCZ4yZ4M Y2efpJg3kepZEIRmm48BxtupLJXEoC1M66F7pTRRN8SwSwfV8P6idnwZADo89Ol5e8Q6 gVhw== X-Gm-Message-State: AOAM532uuVDJmnaBPr7VZyAwtDfcZlt3KckGddbAOF72dGqsDZvfnV64 tZR4Wadl64AU2Bol5Ei3LDWY+Ub/YUYdfPapyJdNXtrh X-Google-Smtp-Source: ABdhPJyzztPTjGxC7oq9dMjApYT5EEIv7+S1FdDhWbGha6zYSfiP9y2W2bxZd3bAZmfbHft5cbIpwywxXupcuaU1IxU= X-Received: by 2002:a9d:2253:: with SMTP id o77mr17574252ota.236.1591041385714; Mon, 01 Jun 2020 12:56:25 -0700 (PDT) MIME-Version: 1.0 References: <843C9840-7AFD-4A8F-9C90-06DC1882AB05@cschneid.com> In-Reply-To: <843C9840-7AFD-4A8F-9C90-06DC1882AB05@cschneid.com> Date: Mon, 1 Jun 2020 20:56:14 +0100 Message-ID: To: Christian Schneider Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000009e57aa05a70b308e" Subject: Re: [PHP-DEV] RFC proposal: fsync support for file resources From: davidgebler@gmail.com (David Gebler) --0000000000009e57aa05a70b308e Content-Type: text/plain; charset="UTF-8" fsync() does not *guarantee* data has been persisted because no software mechanism which exists can do that. It is however the *best assurance* we can have that data has been physically persisted by the time the function returns. fsync() is the best operating-system level assurance we can get regarding data persistence and PHP is the only major programming language I can think of which doesn't support a means of doing it. I've had use cases in web systems and microservices written in PHP where the ability to provide durable file writes would have been very valuable, other cases where services have had to be written in Java or some other language specifically because they require durability where PHP might otherwise have been a good candidate. > While there is little reason not to add fsync() to PHP the importance and benefits are IMHO not that big. Arguably so, but neither that big is the effort required to implement this feature. On Mon, Jun 1, 2020 at 8:47 PM Christian Schneider wrote: > Am 01.06.2020 um 18:56 schrieb David Gebler : > > It seems to me an odd oversight that this has never been implemented in > PHP > > and means PHP has no way to perform durable file write operations, making > > it inherently unsuitable for any systems requiring more intensive I/O, > > mission critical logs, auditing, etc. > > I think there is a misconception of the usefulness of fsync() here. > > First of all it does not *really* guarantee the data is safe from power > outages etc, see > https://stackoverflow.com/a/706688 > https://stackoverflow.com/a/725742 > and other answers in that thread. > > Secondly I'd rather rely on something like a proper DB if not losing any > data is crucial. > Trying to implement it in pure PHP and plain old files seems like using > the wrong tools for the job to me. > > While there is little reason not to add fsync() to PHP the importance and > benefits are IMHO not that big. > > - Chris > > --0000000000009e57aa05a70b308e--