From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87658 invoked by alias); 20 Jun 2019 07:29:46 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 87648 invoked by uid 89); 20 Jun 2019 07:29:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*MI:sk:2019062, H*i:sk:2019062, H*f:sk:2019062 X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Jun 2019 07:29:44 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id E74FD300045F; Thu, 20 Jun 2019 09:29:41 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 97011413CC0E; Thu, 20 Jun 2019 09:29:41 +0200 (CEST) Message-ID: Subject: Re: [PATCH] libelf: Fix some 32bit offset/size issues that break updating 4G+ files. From: Mark Wielaard To: "Dmitry V. Levin" Cc: elfutils-devel@sourceware.org, fche@redhat.com, mcermak@redhat.com, dpranke@chromium.org, thestig@chromium.org, thomasanderson@chromium.org Date: Thu, 20 Jun 2019 07:29:00 -0000 In-Reply-To: <20190620015419.GA31302@altlinux.org> References: <1560902643-20602-1-git-send-email-mark@klomp.org> <88f529e444b84b7b58813fcaf185b80473fd569c.camel@klomp.org> <20190620015419.GA31302@altlinux.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q2/txt/msg00117.txt.bz2 On Thu, 2019-06-20 at 04:54 +0300, Dmitry V. Levin wrote: > On Thu, Jun 20, 2019 at 01:10:53AM +0200, Mark Wielaard wrote: > > +# Make sure the disk is reasonably fast, should be able to write > > 100MB/s > > +fast_disk=3D1 > > +timeout -s9 10s dd conv=3Dfsync if=3D/dev/urandom of=3Dtempfile bs=3D1M > > count=3D1K \ > > + || fast_disk=3D0; rm tempfile >=20 > Why /dev/urandom? I suggest to use /dev/zero instead. Good question. In early testing I noticed some file systems seemed to optimize away the whole writing of zeros and dd would finish almost immediately. So I used /dev/urandom to get some "real bits" in the file. But even that didn't always show the true write-through speed. Then I added conv=3Dfsync which makes sure to physically write output file data before finishing. That seems to work to see the actual write speed with either /dev/urandom or /dev/zero. So, I'll change it to /dev/zero again. Thanks. > Also, the check itself is quite expensive, it writes 1G into > tempfile, > I suggest to move it after mem_available check. OK. Moved. > > +if test $fast_disk -eq 0; then > > + echo "Disk not fast enough, need at least 100MB/s" >=20 > It isn't necessarily a disk, I'd say that file system is not fast > enough. Changed. Thanks, Mark