From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: Filipus Klutiero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 20 Jan 2012 07:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 10561@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.132704385118405 (code B ref -1); Fri, 20 Jan 2012 07:18:02 +0000 Received: (at submit) by debbugs.gnu.org; 20 Jan 2012 07:17:31 +0000 Received: from localhost ([127.0.0.1]:36014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro8j4-0004ml-8M for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:17:31 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56638) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro8j1-0004me-Us for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:17:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ro8hn-0003hp-Bs for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:16:12 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:56611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ro8hn-0003hh-AJ for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:16:11 -0500 Received: from eggs.gnu.org ([140.186.70.92]:49613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ro8hm-000702-8W for bug-coreutils@gnu.org; Fri, 20 Jan 2012 02:16:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ro8hk-0003hV-S9 for bug-coreutils@gnu.org; Fri, 20 Jan 2012 02:16:10 -0500 Received: from mail-qw0-f41.google.com ([209.85.216.41]:48805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ro8hk-0003hR-Pv for bug-coreutils@gnu.org; Fri, 20 Jan 2012 02:16:08 -0500 Received: by qadc11 with SMTP id c11so216220qad.0 for ; Thu, 19 Jan 2012 23:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=50C/Yn/D+pD31A3kKAf2CJqwzu6fDUf5A/e2wYcTpMY=; b=iQMwlHLAxlwNd/vyT4/ANyQbRnDY6oPPuch8uncrdsyfludmTA+O9Ms6Q/LL94qBYh 9OTmn5igPuK+a5g6NHoBSYM7Z3KDvCQwDQPB8BNFEfTUIX1fM26Zb0WAmpJ3I+M4IlDO 7r34ycOVq977oHhedVwlwZO9iwP1sGnCfm45k= Received: by 10.224.188.137 with SMTP id da9mr31760883qab.29.1327043768110; Thu, 19 Jan 2012 23:16:08 -0800 (PST) Received: from [192.168.1.9] (modemcable156.191-56-74.mc.videotron.ca. [74.56.191.156]) by mx.google.com with ESMTPS id d5sm4780204qaj.18.2012.01.19.23.16.06 (version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 23:16:07 -0800 (PST) Message-ID: <4F1914B4.6000406@gmail.com> Date: Fri, 20 Jan 2012 02:16:04 -0500 From: Filipus Klutiero User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) Today I tried figuring out how much disk space a small file took. I used stat, but that turned out surprisingly difficult: > # LANG=C stat htpasswd.setup > File: `htpasswd.setup' > Size: 54 Blocks: 8 IO Block: 4096 regular file > Device: 805h/2053d Inode: 5268976 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 33/www-data) > Access: 2012-01-19 15:00:58.000000000 -0500 > Modify: 2012-01-19 15:00:54.000000000 -0500 > Change: 2012-01-19 15:00:54.000000000 -0500 > Birth: - > root@vinci:/etc/phpmyadmin# The "real" size is clear, but at first I thought that didn't say the size on disk. There are 3 interesting format sequences: > %b > Number of blocks allocated (see %B) > %B > The size in bytes of each block reported by %b > %o > I/O block size In the default format, %b is shown as "Blocks" and %o is shown as "IO Block". On my system, there are 2 kinds of blocks, those on the HDD, 512 bytes each, and those of the filesystem, 4096 each. The manual's descriptions do not make it clear which kind of block is referred to. After verification, %b refers to HDD blocks. I'm not sure what language should be used instead. Perhaps instead of blocks the manual should talk about "data storage device blocks". As for %o, if you'd ask me what "I/O block size" means without any context, I'm far from being sure I would answer it means size on disk. I suggest to call this Size on disk, or Size used on the filesystem. From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 20 Jan 2012 12:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Filipus Klutiero Cc: 10561@debbugs.gnu.org Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.132706253719641 (code B ref 10561); Fri, 20 Jan 2012 12:29:01 +0000 Received: (at 10561) by debbugs.gnu.org; 20 Jan 2012 12:28:57 +0000 Received: from localhost ([127.0.0.1]:36491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoDaS-00056i-HI for submit@debbugs.gnu.org; Fri, 20 Jan 2012 07:28:57 -0500 Received: from mail3.vodafone.ie ([213.233.128.45]:23737) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoDaP-00056Z-KN for 10561@debbugs.gnu.org; Fri, 20 Jan 2012 07:28:54 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAD9dGU9tTAze/2dsb2JhbAAMN6tdhRoBAQEDAXkFCwsNAQoJFg8JAwIBAgFFBgoDAQcBAYd4uSiDfogoBJsQjFQ Received: from unknown (HELO [192.168.1.79]) ([109.76.12.222]) by mail3.vodafone.ie with ESMTP; 20 Jan 2012 12:27:35 +0000 Message-ID: <4F195DB6.9080208@draigBrady.com> Date: Fri, 20 Jan 2012 12:27:34 +0000 From: =?UTF-8?Q?P=C3=A1draig?= Brady User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> In-Reply-To: <4F1914B4.6000406@gmail.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.6 (/) On 01/20/2012 07:16 AM, Filipus Klutiero wrote: > Today I tried figuring out how much disk space a small file took. I used stat, but that turned out surprisingly difficult: First of all, `du` is probably a better tool to this use case. Anyway... >> # LANG=C stat htpasswd.setup >> File: `htpasswd.setup' >> Size: 54 Blocks: 8 IO Block: 4096 regular file >> Device: 805h/2053d Inode: 5268976 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 33/www-data) >> Access: 2012-01-19 15:00:58.000000000 -0500 >> Modify: 2012-01-19 15:00:54.000000000 -0500 >> Change: 2012-01-19 15:00:54.000000000 -0500 >> Birth: - >> root@vinci:/etc/phpmyadmin# > > The "real" size is clear, but at first I thought that didn't say the size on disk. > > There are 3 interesting format sequences: > >> %b >> Number of blocks allocated (see %B) >> %B >> The size in bytes of each block reported by %b > >> %o >> I/O block size > > In the default format, %b is shown as "Blocks" and %o is shown as "IO Block". > On my system, there are 2 kinds of blocks, those on the HDD, 512 bytes each, and those of the filesystem, 4096 each. The manual's descriptions do not make it clear which kind of block is referred to. After verification, %b refers to HDD blocks. Well %B may not always refer to "HDD blocks". Just interpret it as described. I.E. an abstract multiplier for %b. To be concrete about block sizes, there are generally 3 to consider: 1. physical defined by the hardware device 2. logical the smallest addressable unit used for the device 3. file system ditto for the file system Traditionally one had a physical block size of 512, but a larger logical size of say 4096, with the size determining the usual I/O ops vs fragmentation trade-off. One can query 1. and 2. like: # strace -e ioctl blockdev --getpbsz /dev/sda ioctl(3, BLKPBSZGET, 512) = 0 512 # strace -e ioctl blockdev --getbsz /dev/sda ioctl(3, BLKBSZGET, 4096) = 0 4096 `stat` works at the file and file system level, so 3. can be queried like: $ stat -f -c "%S" . 4096 > As for %o, if you'd ask me what "I/O block size" means without any context, I'm far from being sure I would answer it means size on disk. I suggest to call this Size on disk, or Size used on the filesystem. I/O implies transfer. So it corresponds to an "optimal transfer size hint" This value can be different at each layer, for example: $ stat -c "%o" . # file level $ stat -f -c "%s" . # file system level # blockdev --getioopt /dev/sda # device level > I'm not sure what language should be used instead. Perhaps instead of blocks the manual should talk about "data storage device blocks". I suppose we could clarify "I/O block size" a bit. How about s|I/O block size|optimal I/O block transfer size| cheers, Padraig. From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 20 Jan 2012 14:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?P=C3=A1draig?= Brady Cc: 10561@debbugs.gnu.org, Filipus Klutiero Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.132706826532594 (code B ref 10561); Fri, 20 Jan 2012 14:05:02 +0000 Received: (at 10561) by debbugs.gnu.org; 20 Jan 2012 14:04:25 +0000 Received: from localhost ([127.0.0.1]:36535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoF4q-0008Te-6s for submit@debbugs.gnu.org; Fri, 20 Jan 2012 09:04:25 -0500 Received: from mx.meyering.net ([88.168.87.75]:43972) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoF4n-0008TU-Tm for 10561@debbugs.gnu.org; Fri, 20 Jan 2012 09:04:23 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 306F4600D0; Fri, 20 Jan 2012 15:03:03 +0100 (CET) From: Jim Meyering In-Reply-To: <4F195DB6.9080208@draigBrady.com> ("=?UTF-8?Q?P=C3=A1draig?= Brady"'s message of "Fri, 20 Jan 2012 12:27:34 +0000") References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> Date: Fri, 20 Jan 2012 15:03:03 +0100 Message-ID: <87ipk6eajs.fsf@rho.meyering.net> Lines: 26 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) P=E1draig Brady wrote: ... >> As for %o, if you'd ask me what "I/O block size" means without any >> context, I'm far from being sure I would answer it means size on >> disk. I suggest to call this Size on disk, or Size used on the >> filesystem. > > I/O implies transfer. > So it corresponds to an "optimal transfer size hint" > This value can be different at each layer, for example: > > $ stat -c "%o" . # file level > $ stat -f -c "%s" . # file system level > # blockdev --getioopt /dev/sda # device level > >> I'm not sure what language should be used instead. Perhaps instead >> of blocks the manual should talk about "data storage device blocks". > > I suppose we could clarify "I/O block size" a bit. > How about s|I/O block size|optimal I/O block transfer size| or even without "block", "optimal I/O transfer size" Either way. Thanks. From unknown Fri Sep 05 18:57:50 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Filipus Klutiero Subject: bug#10561: closed (Re: bug#10561: stat unclear about size on disk and type of blocks discussed) Message-ID: References: <4F19770D.8000006@draigBrady.com> <4F1914B4.6000406@gmail.com> X-Gnu-PR-Message: they-closed 10561 X-Gnu-PR-Package: coreutils Reply-To: 10561@debbugs.gnu.org Date: Fri, 20 Jan 2012 14:18:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1327069082-1570-1" This is a multi-part message in MIME format... ------------=_1327069082-1570-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #10561: stat unclear about size on disk and type of blocks discussed which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 10561@debbugs.gnu.org. --=20 10561: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D10561 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1327069082-1570-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 10561-done) by debbugs.gnu.org; 20 Jan 2012 14:17:12 +0000 Received: from localhost ([127.0.0.1]:36561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoFH9-0000Nt-CG for submit@debbugs.gnu.org; Fri, 20 Jan 2012 09:17:11 -0500 Received: from mail3.vodafone.ie ([213.233.128.45]:15995) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoFH3-0000NL-A1 for 10561-done@debbugs.gnu.org; Fri, 20 Jan 2012 09:17:06 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJd1GU9tTAze/2dsb2JhbAAMN6tdhRsBAQEEMgFGEAsNCwkWDwkDAgECAUUGCgMBBwEBwFKMJgSbEIxU Received: from unknown (HELO [192.168.1.79]) ([109.76.12.222]) by mail3.vodafone.ie with ESMTP; 20 Jan 2012 14:15:42 +0000 Message-ID: <4F19770D.8000006@draigBrady.com> Date: Fri, 20 Jan 2012 14:15:41 +0000 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#10561: stat unclear about size on disk and type of blocks discussed References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> In-Reply-To: <87ipk6eajs.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 10561-done Cc: 10561-done@debbugs.gnu.org, Filipus Klutiero X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.6 (/) On 01/20/2012 02:03 PM, Jim Meyering wrote: > Pádraig Brady wrote: > ... >>> As for %o, if you'd ask me what "I/O block size" means without any >>> context, I'm far from being sure I would answer it means size on >>> disk. I suggest to call this Size on disk, or Size used on the >>> filesystem. >> >> I/O implies transfer. >> So it corresponds to an "optimal transfer size hint" >> This value can be different at each layer, for example: >> >> $ stat -c "%o" . # file level >> $ stat -f -c "%s" . # file system level >> # blockdev --getioopt /dev/sda # device level >> >>> I'm not sure what language should be used instead. Perhaps instead >>> of blocks the manual should talk about "data storage device blocks". >> >> I suppose we could clarify "I/O block size" a bit. >> How about s|I/O block size|optimal I/O block transfer size| > > or even without "block", > > "optimal I/O transfer size" OK I'll go with "optimal I/O transfer size hint", since there is nothing guaranteed about it, and in fact it's often wrong. cheers, Pádraig. p.s. marking bug done... ------------=_1327069082-1570-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 20 Jan 2012 07:17:31 +0000 Received: from localhost ([127.0.0.1]:36014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro8j4-0004ml-8M for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:17:31 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56638) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro8j1-0004me-Us for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:17:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ro8hn-0003hp-Bs for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:16:12 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:56611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ro8hn-0003hh-AJ for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:16:11 -0500 Received: from eggs.gnu.org ([140.186.70.92]:49613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ro8hm-000702-8W for bug-coreutils@gnu.org; Fri, 20 Jan 2012 02:16:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ro8hk-0003hV-S9 for bug-coreutils@gnu.org; Fri, 20 Jan 2012 02:16:10 -0500 Received: from mail-qw0-f41.google.com ([209.85.216.41]:48805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ro8hk-0003hR-Pv for bug-coreutils@gnu.org; Fri, 20 Jan 2012 02:16:08 -0500 Received: by qadc11 with SMTP id c11so216220qad.0 for ; Thu, 19 Jan 2012 23:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=50C/Yn/D+pD31A3kKAf2CJqwzu6fDUf5A/e2wYcTpMY=; b=iQMwlHLAxlwNd/vyT4/ANyQbRnDY6oPPuch8uncrdsyfludmTA+O9Ms6Q/LL94qBYh 9OTmn5igPuK+a5g6NHoBSYM7Z3KDvCQwDQPB8BNFEfTUIX1fM26Zb0WAmpJ3I+M4IlDO 7r34ycOVq977oHhedVwlwZO9iwP1sGnCfm45k= Received: by 10.224.188.137 with SMTP id da9mr31760883qab.29.1327043768110; Thu, 19 Jan 2012 23:16:08 -0800 (PST) Received: from [192.168.1.9] (modemcable156.191-56-74.mc.videotron.ca. [74.56.191.156]) by mx.google.com with ESMTPS id d5sm4780204qaj.18.2012.01.19.23.16.06 (version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 23:16:07 -0800 (PST) Message-ID: <4F1914B4.6000406@gmail.com> Date: Fri, 20 Jan 2012 02:16:04 -0500 From: Filipus Klutiero User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: bug-coreutils@gnu.org Subject: stat unclear about size on disk and type of blocks discussed Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) Today I tried figuring out how much disk space a small file took. I used stat, but that turned out surprisingly difficult: > # LANG=C stat htpasswd.setup > File: `htpasswd.setup' > Size: 54 Blocks: 8 IO Block: 4096 regular file > Device: 805h/2053d Inode: 5268976 Links: 1 > Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 33/www-data) > Access: 2012-01-19 15:00:58.000000000 -0500 > Modify: 2012-01-19 15:00:54.000000000 -0500 > Change: 2012-01-19 15:00:54.000000000 -0500 > Birth: - > root@vinci:/etc/phpmyadmin# The "real" size is clear, but at first I thought that didn't say the size on disk. There are 3 interesting format sequences: > %b > Number of blocks allocated (see %B) > %B > The size in bytes of each block reported by %b > %o > I/O block size In the default format, %b is shown as "Blocks" and %o is shown as "IO Block". On my system, there are 2 kinds of blocks, those on the HDD, 512 bytes each, and those of the filesystem, 4096 each. The manual's descriptions do not make it clear which kind of block is referred to. After verification, %b refers to HDD blocks. I'm not sure what language should be used instead. Perhaps instead of blocks the manual should talk about "data storage device blocks". As for %o, if you'd ask me what "I/O block size" means without any context, I'm far from being sure I would answer it means size on disk. I suggest to call this Size on disk, or Size used on the filesystem. ------------=_1327069082-1570-1-- From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: Filipus Klutiero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 20 Jan 2012 17:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?P=C3=A1draig?= Brady Cc: 10561@debbugs.gnu.org, Jim Meyering Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.132708175823973 (code B ref 10561); Fri, 20 Jan 2012 17:50:01 +0000 Received: (at 10561) by debbugs.gnu.org; 20 Jan 2012 17:49:18 +0000 Received: from localhost ([127.0.0.1]:36894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoIaT-0006Eb-H7 for submit@debbugs.gnu.org; Fri, 20 Jan 2012 12:49:18 -0500 Received: from mail-qy0-f172.google.com ([209.85.216.172]:62947) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoIaP-0006ER-Va for 10561@debbugs.gnu.org; Fri, 20 Jan 2012 12:49:15 -0500 Received: by qcsc1 with SMTP id c1so424211qcs.3 for <10561@debbugs.gnu.org>; Fri, 20 Jan 2012 09:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Sdrm+Id0GUgIrVI3YRj4wxZmZ9Yl4tXaWJzUGudpP1g=; b=me9myGgg6aCiJ/ObRjUrIY3ACRVruw64/iqYeIV+ikvo6ja0/M4QItzPO4zIjE681r LL4ryGZ7HjDZRwaiB5R2PNLnJoJsnIO3jPOQzhh/wqfR5/ao/euQNP/cdMhYJU0VYpK2 69PSDQLPNh4/U9mw3PYvhgg6IlzVwIi1nONg4= Received: by 10.229.137.79 with SMTP id v15mr12860636qct.68.1327081675243; Fri, 20 Jan 2012 09:47:55 -0800 (PST) Received: from [192.168.1.9] (modemcable156.191-56-74.mc.videotron.ca. [74.56.191.156]) by mx.google.com with ESMTPS id r17sm7723712qap.11.2012.01.20.09.47.52 (version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 09:47:53 -0800 (PST) Message-ID: <4F19A8C5.2010309@gmail.com> Date: Fri, 20 Jan 2012 12:47:49 -0500 From: Filipus Klutiero User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> <4F19770D.8000006@draigBrady.com> In-Reply-To: <4F19770D.8000006@draigBrady.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi Pádraig and Jim, On 2012-01-20 09:15, Pádraig Brady wrote: > On 01/20/2012 02:03 PM, Jim Meyering wrote: >> Pádraig Brady wrote: >> ... >>>> As for %o, if you'd ask me what "I/O block size" means without any >>>> context, I'm far from being sure I would answer it means size on >>>> disk. I suggest to call this Size on disk, or Size used on the >>>> filesystem. >>> I/O implies transfer. >>> So it corresponds to an "optimal transfer size hint" >>> This value can be different at each layer, for example: >>> >>> $ stat -c "%o" . # file level >>> $ stat -f -c "%s" . # file system level >>> # blockdev --getioopt /dev/sda # device level >>> >>>> I'm not sure what language should be used instead. Perhaps instead >>>> of blocks the manual should talk about "data storage device blocks". >>> I suppose we could clarify "I/O block size" a bit. >>> How about s|I/O block size|optimal I/O block transfer size| >> or even without "block", >> >> "optimal I/O transfer size" > OK I'll go with "optimal I/O transfer size hint", > since there is nothing guaranteed about it, > and in fact it's often wrong. > > cheers, > Pádraig. > I'm sorry but this change does not really address my concern. The previous definition of %o did refer to "block" without specifying which kind of block. This is no longer the case as the new definition no longer refers to blocks. However, I still do not consider the new definition, "Optimal I/O transfer size hint", understandable. To come back to my original problem, I tried figuring out how much disk space a small file took. In Windows, I would look at "Size on disk". If "optimal I/O transfer size hint" means size on disk, this is still very unclear. Even after reading your answers, I don't understand what "Optimal I/O transfer size" means. I am not looking for a transfer size. My question is, if I'm putting a small file on my filesystem, how much space will it use. Here are 2 new descriptions I suggest: Size occupied when including slack space Size of the clusters occupied Appart from %o, the ambiguity problem in the descriptions of %b and %B remains. Thank you for the information about blocks and commands Pádraig. From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 21 Jan 2012 00:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Filipus Klutiero Cc: 10561@debbugs.gnu.org Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.13271042883616 (code B ref 10561); Sat, 21 Jan 2012 00:05:01 +0000 Received: (at 10561) by debbugs.gnu.org; 21 Jan 2012 00:04:48 +0000 Received: from localhost ([127.0.0.1]:37042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoORs-0000wH-Bc for submit@debbugs.gnu.org; Fri, 20 Jan 2012 19:04:48 -0500 Received: from mail3.vodafone.ie ([213.233.128.45]:13059) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoORp-0000w5-LN for 10561@debbugs.gnu.org; Fri, 20 Jan 2012 19:04:46 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBACMAGk9tTftj/2dsb2JhbAAMN6tkhR0BAQEDATIBPwcFCwsNAQoJFg8JAwIBAgFFBgoDAQcBAYd4uGqMJgSbEIxU Received: from unknown (HELO [192.168.1.79]) ([109.77.251.99]) by mail3.vodafone.ie with ESMTP; 21 Jan 2012 00:03:23 +0000 Message-ID: <4F1A00CC.6010706@draigBrady.com> Date: Sat, 21 Jan 2012 00:03:24 +0000 From: =?UTF-8?Q?P=C3=A1draig?= Brady User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> <4F19770D.8000006@draigBrady.com> <4F19A8C5.2010309@gmail.com> In-Reply-To: <4F19A8C5.2010309@gmail.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 01/20/2012 05:47 PM, Filipus Klutiero wrote: > Hi Pádraig and Jim, > > On 2012-01-20 09:15, Pádraig Brady wrote: >> On 01/20/2012 02:03 PM, Jim Meyering wrote: >>> Pádraig Brady wrote: >>> ... >>>>> As for %o, if you'd ask me what "I/O block size" means without any >>>>> context, I'm far from being sure I would answer it means size on >>>>> disk. I suggest to call this Size on disk, or Size used on the >>>>> filesystem. >>>> I/O implies transfer. >>>> So it corresponds to an "optimal transfer size hint" >>>> This value can be different at each layer, for example: >>>> >>>> $ stat -c "%o" . # file level >>>> $ stat -f -c "%s" . # file system level >>>> # blockdev --getioopt /dev/sda # device level >>>> >>>>> I'm not sure what language should be used instead. Perhaps instead >>>>> of blocks the manual should talk about "data storage device blocks". >>>> I suppose we could clarify "I/O block size" a bit. >>>> How about s|I/O block size|optimal I/O block transfer size| >>> or even without "block", >>> >>> "optimal I/O transfer size" >> OK I'll go with "optimal I/O transfer size hint", >> since there is nothing guaranteed about it, >> and in fact it's often wrong. >> >> cheers, >> Pádraig. >> > > I'm sorry but this change does not really address my concern. It does actually, because... > The previous definition of %o did refer to "block" without specifying which kind of block. This is no longer the case as the new definition no longer refers to blocks. However, I still do not consider the new definition, "Optimal I/O transfer size hint", understandable. > To come back to my original problem, I tried figuring out how much disk space a small file took. In Windows, I would look at "Size on disk". If "optimal I/O transfer size hint" means size on disk, this is still very unclear. Even after reading your answers, I don't understand what "Optimal I/O transfer size" means. > I am not looking for a transfer size. ... you know to ignore %o > My question is, if I'm putting a small file on my filesystem, how much space will it use. > Here are 2 new descriptions I suggest: > Size occupied when including slack space > Size of the clusters occupied > > Appart from %o, the ambiguity problem in the descriptions of %b and %B remains. No it does not. As I said they're abstract entities only valid in relation to each other. Just multiple %b x %B to get your answer. You may have missed the start of the last mail, where I said the du command is more appropriate (it does the above for you). cheers, Pádraig. From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 21 Jan 2012 00:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 10561@debbugs.gnu.org, P@draigBrady.com Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.13271056816155 (code B ref 10561); Sat, 21 Jan 2012 00:28:02 +0000 Received: (at 10561) by debbugs.gnu.org; 21 Jan 2012 00:28:01 +0000 Received: from localhost ([127.0.0.1]:37071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoOoK-0001bD-Th for submit@debbugs.gnu.org; Fri, 20 Jan 2012 19:28:01 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:45341) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoOoH-0001b1-Ik for 10561@debbugs.gnu.org; Fri, 20 Jan 2012 19:27:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9AD82A60007; Fri, 20 Jan 2012 16:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npJ7l1kw+NLr; Fri, 20 Jan 2012 16:26:36 -0800 (PST) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 3754CA60001; Fri, 20 Jan 2012 16:26:36 -0800 (PST) Message-ID: <4F1A063C.4000700@cs.ucla.edu> Date: Fri, 20 Jan 2012 16:26:36 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> <4F19770D.8000006@draigBrady.com> In-Reply-To: <4F19770D.8000006@draigBrady.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 01/20/2012 06:15 AM, P=C3=A1draig Brady wrote: > I'll go with "optimal I/O transfer size hint", There's no guarantee that it's optimal, and I/O is always transfer, so how about something like "I/O buffer size hint" instead? From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 21 Jan 2012 00:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Paul Eggert Cc: 10561@debbugs.gnu.org Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.13271070048618 (code B ref 10561); Sat, 21 Jan 2012 00:51:01 +0000 Received: (at 10561) by debbugs.gnu.org; 21 Jan 2012 00:50:04 +0000 Received: from localhost ([127.0.0.1]:37077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoP9f-0002Ex-SK for submit@debbugs.gnu.org; Fri, 20 Jan 2012 19:50:04 -0500 Received: from mail3.vodafone.ie ([213.233.128.45]:58736) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoP9d-0002ER-A4 for 10561@debbugs.gnu.org; Fri, 20 Jan 2012 19:50:02 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAEQKGk9tTftj/2dsb2JhbAAMNw6EdqZghR0BAQEEIw8BRhALDQsCAgUWCwICCQMCAQIBRQYKAwEHAQGvFpFSgS+JYYEWBJsQjB03 Received: from unknown (HELO [192.168.1.79]) ([109.77.251.99]) by mail3.vodafone.ie with ESMTP; 21 Jan 2012 00:48:39 +0000 Message-ID: <4F1A0B67.6010201@draigBrady.com> Date: Sat, 21 Jan 2012 00:48:39 +0000 From: =?UTF-8?Q?P=C3=A1draig?= Brady User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> <4F19770D.8000006@draigBrady.com> <4F1A063C.4000700@cs.ucla.edu> In-Reply-To: <4F1A063C.4000700@cs.ucla.edu> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 01/21/2012 12:26 AM, Paul Eggert wrote: > On 01/20/2012 06:15 AM, Pádraig Brady wrote: >> I'll go with "optimal I/O transfer size hint", > > There's no guarantee that it's optimal, > and I/O is always transfer, so how about > something like "I/O buffer size hint" instead? Well I used optimal so that'sit's clear it's a performance knob, and it correlates with ioctl() and blockdev(1) params. Also "buffer size" might be construed as referring to an existing system buffer. So I marginally prefer what's already committed. cheers, Pádraig. From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: Filipus Klutiero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 07 Feb 2012 18:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?P=C3=A1draig?= Brady Cc: 10561@debbugs.gnu.org Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.13286392537124 (code B ref 10561); Tue, 07 Feb 2012 18:28:01 +0000 Received: (at 10561) by debbugs.gnu.org; 7 Feb 2012 18:27:33 +0000 Received: from localhost ([127.0.0.1]:59261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuplL-0001qp-QI for submit@debbugs.gnu.org; Tue, 07 Feb 2012 13:27:32 -0500 Received: from mail-qw0-f44.google.com ([209.85.216.44]:45020) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuplJ-0001qd-9l for 10561@debbugs.gnu.org; Tue, 07 Feb 2012 13:27:30 -0500 Received: by qafi29 with SMTP id i29so3097443qaf.3 for <10561@debbugs.gnu.org>; Tue, 07 Feb 2012 10:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JYpB6+ZACJpfCOOFsb8efQMHCe9jJo7Oz12BM4x0xCc=; b=ams3va0BveE6SWIXAzvZpaC2DqDP8sLR2genL7JOajxbeBcGGkCjIu19WPv5IDmX2r EQhHKKbYpuGQZTzXvmvWuLATeT8hJ5zXpItzlanNB4A8YAVefq1k7dYRzf85k/QaWCxL kLZf9oEk6LNQ2cdyhtlYb+dFvs7yZaZzAAQd0= Received: by 10.229.111.89 with SMTP id r25mr9752886qcp.106.1328639186714; Tue, 07 Feb 2012 10:26:26 -0800 (PST) Received: from [192.168.1.9] (modemcable156.191-56-74.mc.videotron.ca. [74.56.191.156]) by mx.google.com with ESMTPS id k19sm36003015qak.4.2012.02.07.10.26.25 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 10:26:25 -0800 (PST) Message-ID: <4F316CCD.3020904@gmail.com> Date: Tue, 07 Feb 2012 13:26:21 -0500 From: Filipus Klutiero User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> <4F19770D.8000006@draigBrady.com> <4F19A8C5.2010309@gmail.com> <4F1A00CC.6010706@draigBrady.com> In-Reply-To: <4F1A00CC.6010706@draigBrady.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi Pádraig, On 2012-01-20 19:03, Pádraig Brady wrote: > On 01/20/2012 05:47 PM, Filipus Klutiero wrote: >> Hi Pádraig and Jim, >> >> On 2012-01-20 09:15, Pádraig Brady wrote: >>> On 01/20/2012 02:03 PM, Jim Meyering wrote: >>>> Pádraig Brady wrote: >>>> ... >>>>>> As for %o, if you'd ask me what "I/O block size" means without any >>>>>> context, I'm far from being sure I would answer it means size on >>>>>> disk. I suggest to call this Size on disk, or Size used on the >>>>>> filesystem. >>>>> I/O implies transfer. >>>>> So it corresponds to an "optimal transfer size hint" >>>>> This value can be different at each layer, for example: >>>>> >>>>> $ stat -c "%o" . # file level >>>>> $ stat -f -c "%s" . # file system level >>>>> # blockdev --getioopt /dev/sda # device level >>>>> >>>>>> I'm not sure what language should be used instead. Perhaps instead >>>>>> of blocks the manual should talk about "data storage device blocks". >>>>> I suppose we could clarify "I/O block size" a bit. >>>>> How about s|I/O block size|optimal I/O block transfer size| >>>> or even without "block", >>>> >>>> "optimal I/O transfer size" >>> OK I'll go with "optimal I/O transfer size hint", >>> since there is nothing guaranteed about it, >>> and in fact it's often wrong. >>> >>> cheers, >>> Pádraig. >>> >> I'm sorry but this change does not really address my concern. > It does actually, because... > >> The previous definition of %o did refer to "block" without specifying which kind of block. This is no longer the case as the new definition no longer refers to blocks. However, I still do not consider the new definition, "Optimal I/O transfer size hint", understandable. >> To come back to my original problem, I tried figuring out how much disk space a small file took. In Windows, I would look at "Size on disk". If "optimal I/O transfer size hint" means size on disk, this is still very unclear. Even after reading your answers, I don't understand what "Optimal I/O transfer size" means. >> I am not looking for a transfer size. > ... you know to ignore %o What do you mean? > >> My question is, if I'm putting a small file on my filesystem, how much space will it use. >> Here are 2 new descriptions I suggest: >> Size occupied when including slack space >> Size of the clusters occupied >> >> Appart from %o, the ambiguity problem in the descriptions of %b and %B remains. > No it does not. Really? The description of %b still reads: > Number of blocks allocated (see %B) How does this description exclude that it refers to file system blocks? > As I said they're abstract entities only valid in relation to each other. > Just multiple %b x %B to get your answer. If these statistics are internals, please mention that. It would also be nice to explain if the user can do anything with these internals. > You may have missed the start of the last mail, where I said > the du command is more appropriate (it does the above for you). > I did not miss that. I was looking for information from stat. I am not asking stat to provide that information. What annoyed me was that I couldn't tell if stat was providing that information because some of the statistics displayed were unclear. I'll try to remember to use du for that, thanks, but it's easier to remember a single command, and I generally prefer a command that tells me both the size on disk and the actual size. From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 07 Feb 2012 18:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Filipus Klutiero Cc: 10561@debbugs.gnu.org Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.13286410279862 (code B ref 10561); Tue, 07 Feb 2012 18:58:01 +0000 Received: (at 10561) by debbugs.gnu.org; 7 Feb 2012 18:57:07 +0000 Received: from localhost ([127.0.0.1]:59288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuqDv-0002Yo-N4 for submit@debbugs.gnu.org; Tue, 07 Feb 2012 13:57:07 -0500 Received: from mail3.vodafone.ie ([213.233.128.45]:52795) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuqDs-0002Y1-TT for 10561@debbugs.gnu.org; Tue, 07 Feb 2012 13:57:02 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAVzMU9tTdw1/2dsb2JhbAAMN60shSIBAQEDATIBPwcQCw0BCgkWDwkDAgECAUUGCgMBBwEBh3i6I4s2AQQCAQICCQICAQYHBAYBCwmDJR0DDBcFUgIMJQIEgzoEmyaMYw Received: from unknown (HELO [192.168.1.79]) ([109.77.220.53]) by mail3.vodafone.ie with ESMTP; 07 Feb 2012 18:55:56 +0000 Message-ID: <4F3173BA.1070506@draigBrady.com> Date: Tue, 07 Feb 2012 18:55:54 +0000 From: =?UTF-8?Q?P=C3=A1draig?= Brady User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> <4F19770D.8000006@draigBrady.com> <4F19A8C5.2010309@gmail.com> <4F1A00CC.6010706@draigBrady.com> <4F316CCD.3020904@gmail.com> In-Reply-To: <4F316CCD.3020904@gmail.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 02/07/2012 06:26 PM, Filipus Klutiero wrote: > Hi Pádraig, > > On 2012-01-20 19:03, Pádraig Brady wrote: >> On 01/20/2012 05:47 PM, Filipus Klutiero wrote: >>> Hi Pádraig and Jim, >>> >>> On 2012-01-20 09:15, Pádraig Brady wrote: >>>> On 01/20/2012 02:03 PM, Jim Meyering wrote: >>>>> Pádraig Brady wrote: >>>>> ... >>>>>>> As for %o, if you'd ask me what "I/O block size" means without any >>>>>>> context, I'm far from being sure I would answer it means size on >>>>>>> disk. I suggest to call this Size on disk, or Size used on the >>>>>>> filesystem. >>>>>> I/O implies transfer. >>>>>> So it corresponds to an "optimal transfer size hint" >>>>>> This value can be different at each layer, for example: >>>>>> >>>>>> $ stat -c "%o" . # file level >>>>>> $ stat -f -c "%s" . # file system level >>>>>> # blockdev --getioopt /dev/sda # device level >>>>>> >>>>>>> I'm not sure what language should be used instead. Perhaps instead >>>>>>> of blocks the manual should talk about "data storage device blocks". >>>>>> I suppose we could clarify "I/O block size" a bit. >>>>>> How about s|I/O block size|optimal I/O block transfer size| >>>>> or even without "block", >>>>> >>>>> "optimal I/O transfer size" >>>> OK I'll go with "optimal I/O transfer size hint", >>>> since there is nothing guaranteed about it, >>>> and in fact it's often wrong. >>>> >>>> cheers, >>>> Pádraig. >>>> >>> I'm sorry but this change does not really address my concern. >> It does actually, because... >> >>> The previous definition of %o did refer to "block" without specifying which kind of block. This is no longer the case as the new definition no longer refers to blocks. However, I still do not consider the new definition, "Optimal I/O transfer size hint", understandable. >>> To come back to my original problem, I tried figuring out how much disk space a small file took. In Windows, I would look at "Size on disk". If "optimal I/O transfer size hint" means size on disk, this is still very unclear. Even after reading your answers, I don't understand what "Optimal I/O transfer size" means. >>> I am not looking for a transfer size. >> ... you know to ignore %o > > What do you mean? Above you realised you're not looking for a transfer size. Hence it should be apparent that %o doesn't output anything you're interested in. >> >>> My question is, if I'm putting a small file on my filesystem, how much space will it use. >>> Here are 2 new descriptions I suggest: >>> Size occupied when including slack space >>> Size of the clusters occupied >>> >>> Appart from %o, the ambiguity problem in the descriptions of %b and %B remains. >> No it does not. > > Really? The description of %b still reads: >> Number of blocks allocated (see %B) > How does this description exclude that it refers to file system blocks? > >> As I said they're abstract entities only valid in relation to each other. >> Just multiple %b x %B to get your answer. > > If these statistics are internals, please mention that. It would also be nice to explain if the user can do anything with these internals. I don't see any ambiguity. %b and %B are described in relation to each other, which is all that's required. See how each refers to the other in the docs: %b Number of blocks allocated (see %B) %B The size in bytes of each block reported by %b >> You may have missed the start of the last mail, where I said >> the du command is more appropriate (it does the above for you). >> > > I did not miss that. I was looking for information from stat. I am not asking stat to provide that information. What annoyed me was that I couldn't tell if stat was providing that information because some of the statistics displayed were unclear. > I'll try to remember to use du for that, thanks, but it's easier to remember a single command, and I generally prefer a command that tells me both the size on disk and the actual size. The best we can do is: stat -c 'allocated-space=%B*%b apparent-size=%s' $file cheers, Pádraig. From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: Filipus Klutiero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 07 Feb 2012 19:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?P=C3=A1draig?= Brady , 10561@debbugs.gnu.org Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.132864251515068 (code B ref 10561); Tue, 07 Feb 2012 19:22:01 +0000 Received: (at 10561) by debbugs.gnu.org; 7 Feb 2012 19:21:55 +0000 Received: from localhost ([127.0.0.1]:59315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ruqby-0003uy-8G for submit@debbugs.gnu.org; Tue, 07 Feb 2012 14:21:54 -0500 Received: from mail-qw0-f44.google.com ([209.85.216.44]:54777) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ruqbv-0003uU-9W for 10561@debbugs.gnu.org; Tue, 07 Feb 2012 14:21:53 -0500 Received: by qafi29 with SMTP id i29so3136355qaf.3 for <10561@debbugs.gnu.org>; Tue, 07 Feb 2012 11:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=h8sLfpQsnXaXdcAdxjaWwWFHR6KhXUAQ5M13vzLHIXA=; b=mPg8TQekdBBRLRkCS0PhaUvt3NFubTIqhrzDURuDiDotAS89hWhj9fbfuuPxfLy8le IgHRCUM+qQps0sxYYJ5JghtSUBQRVukCLUE0H2B65tTFXnWeI0pSqybS+mdPtP0zM46Z GpFdQObVhu/ggR0gPh8Zgt0Y/hRbxhpe6HHew= Received: by 10.229.136.77 with SMTP id q13mr9839290qct.154.1328642448521; Tue, 07 Feb 2012 11:20:48 -0800 (PST) Received: from [192.168.1.9] (modemcable156.191-56-74.mc.videotron.ca. [74.56.191.156]) by mx.google.com with ESMTPS id ef1sm42647010qab.19.2012.02.07.11.20.46 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 11:20:47 -0800 (PST) Message-ID: <4F31798B.5020508@gmail.com> Date: Tue, 07 Feb 2012 14:20:43 -0500 From: Filipus Klutiero User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> <4F19770D.8000006@draigBrady.com> <4F19A8C5.2010309@gmail.com> <4F1A00CC.6010706@draigBrady.com> <4F316CCD.3020904@gmail.com> <4F3173BA.1070506@draigBrady.com> In-Reply-To: <4F3173BA.1070506@draigBrady.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 2012-02-07 13:55, Pádraig Brady wrote: > On 02/07/2012 06:26 PM, Filipus Klutiero wrote: >> Hi Pádraig, >> >> On 2012-01-20 19:03, Pádraig Brady wrote: >>> On 01/20/2012 05:47 PM, Filipus Klutiero wrote: >>>> Hi Pádraig and Jim, >>>> >>>> On 2012-01-20 09:15, Pádraig Brady wrote: >>>>> On 01/20/2012 02:03 PM, Jim Meyering wrote: >>>>>> Pádraig Brady wrote: >>>>>> ... >>>>>>>> As for %o, if you'd ask me what "I/O block size" means without any >>>>>>>> context, I'm far from being sure I would answer it means size on >>>>>>>> disk. I suggest to call this Size on disk, or Size used on the >>>>>>>> filesystem. >>>>>>> I/O implies transfer. >>>>>>> So it corresponds to an "optimal transfer size hint" >>>>>>> This value can be different at each layer, for example: >>>>>>> >>>>>>> $ stat -c "%o" . # file level >>>>>>> $ stat -f -c "%s" . # file system level >>>>>>> # blockdev --getioopt /dev/sda # device level >>>>>>> >>>>>>>> I'm not sure what language should be used instead. Perhaps instead >>>>>>>> of blocks the manual should talk about "data storage device blocks". >>>>>>> I suppose we could clarify "I/O block size" a bit. >>>>>>> How about s|I/O block size|optimal I/O block transfer size| >>>>>> or even without "block", >>>>>> >>>>>> "optimal I/O transfer size" >>>>> OK I'll go with "optimal I/O transfer size hint", >>>>> since there is nothing guaranteed about it, >>>>> and in fact it's often wrong. >>>>> >>>>> cheers, >>>>> Pádraig. >>>>> >>>> I'm sorry but this change does not really address my concern. >>> It does actually, because... >>> >>>> The previous definition of %o did refer to "block" without specifying which kind of block. This is no longer the case as the new definition no longer refers to blocks. However, I still do not consider the new definition, "Optimal I/O transfer size hint", understandable. >>>> To come back to my original problem, I tried figuring out how much disk space a small file took. In Windows, I would look at "Size on disk". If "optimal I/O transfer size hint" means size on disk, this is still very unclear. Even after reading your answers, I don't understand what "Optimal I/O transfer size" means. >>>> I am not looking for a transfer size. >>> ... you know to ignore %o >> What do you mean? > Above you realised you're not looking for a transfer size. > Hence it should be apparent that %o doesn't output anything > you're interested in. So are you saying that stat cannot display a file's size on disk? > >>>> My question is, if I'm putting a small file on my filesystem, how much space will it use. >>>> Here are 2 new descriptions I suggest: >>>> Size occupied when including slack space >>>> Size of the clusters occupied >>>> >>>> Appart from %o, the ambiguity problem in the descriptions of %b and %B remains. >>> No it does not. >> Really? The description of %b still reads: >>> Number of blocks allocated (see %B) >> How does this description exclude that it refers to file system blocks? >> >>> As I said they're abstract entities only valid in relation to each other. >>> Just multiple %b x %B to get your answer. >> If these statistics are internals, please mention that. It would also be nice to explain if the user can do anything with these internals. > I don't see any ambiguity. %b and %B are described in relation > to each other, which is all that's required. That's not all that's required. Each directive should have a useful description, not just a circular definition. > See how each refers to the other in the docs: > > %b Number of blocks allocated (see %B) > %B The size in bytes of each block reported by %b > I see that, but I fail to see how that would make the description of %b unambiguous. A file has a number of file system blocks allocated. I do not see what would prevent a reader from interpreting %b as that number. From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 07 Feb 2012 19:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Filipus Klutiero Cc: 10561@debbugs.gnu.org, =?UTF-8?Q?P=C3=A1draig?= Brady Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.132864391920347 (code B ref 10561); Tue, 07 Feb 2012 19:46:02 +0000 Received: (at 10561) by debbugs.gnu.org; 7 Feb 2012 19:45:19 +0000 Received: from localhost ([127.0.0.1]:59349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ruqyb-0005I7-CE for submit@debbugs.gnu.org; Tue, 07 Feb 2012 14:45:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12868) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuqyV-0005Hr-CQ for 10561@debbugs.gnu.org; Tue, 07 Feb 2012 14:45:14 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q17Ji9Ud028924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2012 14:44:09 -0500 Received: from [10.3.113.116] (ovpn-113-116.phx2.redhat.com [10.3.113.116]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q17Ji8rD004550; Tue, 7 Feb 2012 14:44:08 -0500 Message-ID: <4F317F07.9080101@redhat.com> Date: Tue, 07 Feb 2012 12:44:07 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> <4F19770D.8000006@draigBrady.com> <4F19A8C5.2010309@gmail.com> <4F1A00CC.6010706@draigBrady.com> <4F316CCD.3020904@gmail.com> <4F3173BA.1070506@draigBrady.com> <4F31798B.5020508@gmail.com> In-Reply-To: <4F31798B.5020508@gmail.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig0D5BDBF7E131B24CCC65974E" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Spam-Score: -6.9 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0D5BDBF7E131B24CCC65974E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/07/2012 12:20 PM, Filipus Klutiero wrote: >=20 > So are you saying that stat cannot display a file's size on disk? Not without inventing a new % modifier, or else you doing the math yourself. So maybe it is worth adding a new one, as in: %S Allocated size (same as %b * %B) >> I don't see any ambiguity. %b and %B are described in relation >> to each other, which is all that's required. >=20 > That's not all that's required. Each directive should have a useful > description, not just a circular definition. >> See how each refers to the other in the docs: >> >> %b Number of blocks allocated (see %B) >> %B The size in bytes of each block reported by %b >> >=20 > I see that, but I fail to see how that would make the description of %b= > unambiguous. A file has a number of file system blocks allocated. I do > not see what would prevent a reader from interpreting %b as that number= =2E Maybe it would help to do things like: %b Number of blocks allocated (see %B), corresponds to st_blocks %B The size in bytes of each block reported by %b, or st_blksize for those that are familiar with the stat(2) interface. For that matter, tying ALL of the existing % modifiers back to struct stat members might be handy. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig0D5BDBF7E131B24CCC65974E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPMX8IAAoJEKeha0olJ0NqzW0H/1NkB+UPiRzKard/QohqnC18 ZKCtvZa3XBakMPf9rCMAOL4vSPpNDC/ZBwLlcqWmNkkwPHflvKV4lBUOFQ1/nRpx tduzsUWjCogi26OdKhdvJ6fHjZXKjopTG/s53Dirq8yjWUyaQpxA5ir72+IuCqFd A0ky+LdkAhOxy123rn0wkysBwEANWwvtynKDKFOdXsvJS9kHqZNxxmUIOe8cALSa i2BsCL2q156JnHWIBib8qrZ9Sv5z7Fu+SqXKCDshCA0L1Vx9cZ5U3b/kCBWiNCm8 +lW16i1e6ftqHBUXk9k0OM/R/ryDrS4mm1YjSu+ffAN9nPUZgaNv3HCdJn+0QjQ= =uD3Y -----END PGP SIGNATURE----- --------------enig0D5BDBF7E131B24CCC65974E-- From unknown Fri Sep 05 18:57:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10561: stat unclear about size on disk and type of blocks discussed Resent-From: Filipus Klutiero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 07 Feb 2012 20:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10561 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake , 10561@debbugs.gnu.org Received: via spool by 10561-submit@debbugs.gnu.org id=B10561.132864795229406 (code B ref 10561); Tue, 07 Feb 2012 20:53:02 +0000 Received: (at 10561) by debbugs.gnu.org; 7 Feb 2012 20:52:32 +0000 Received: from localhost ([127.0.0.1]:59428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rus1f-0007eE-S1 for submit@debbugs.gnu.org; Tue, 07 Feb 2012 15:52:32 -0500 Received: from mail-qw0-f44.google.com ([209.85.216.44]:61443) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rus1e-0007e0-58 for 10561@debbugs.gnu.org; Tue, 07 Feb 2012 15:52:31 -0500 Received: by qafi29 with SMTP id i29so3201119qaf.3 for <10561@debbugs.gnu.org>; Tue, 07 Feb 2012 12:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MnuUFed4pcJYOPfnfrYkxezfr5G4uafaXAu6GyhFh9Q=; b=TrlX+jGJlFL0bowj88UGOkqfjWsbhQzAxm6WzwWCxJupacZ3jpqdAlKVzao/Y7oc4X EIczpConIJYCNQ/UAkxGI5wpk+xOUBxtiyiN0nKw5Z05VnOI4IB6Xg9thxLPgjAMlrHV G1nCMhuEV7uJhYbtpiaGM2yfaneFcAWNpzc+E= Received: by 10.229.136.15 with SMTP id p15mr9642860qct.59.1328647887196; Tue, 07 Feb 2012 12:51:27 -0800 (PST) Received: from [192.168.1.9] (modemcable156.191-56-74.mc.videotron.ca. [74.56.191.156]) by mx.google.com with ESMTPS id eb5sm43152324qab.10.2012.02.07.12.51.24 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 12:51:25 -0800 (PST) Message-ID: <4F318EC9.4040406@gmail.com> Date: Tue, 07 Feb 2012 15:51:21 -0500 From: Filipus Klutiero User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 References: <4F1914B4.6000406@gmail.com> <4F195DB6.9080208@draigBrady.com> <87ipk6eajs.fsf@rho.meyering.net> <4F19770D.8000006@draigBrady.com> <4F19A8C5.2010309@gmail.com> <4F1A00CC.6010706@draigBrady.com> <4F316CCD.3020904@gmail.com> <4F3173BA.1070506@draigBrady.com> <4F31798B.5020508@gmail.com> <4F317F07.9080101@redhat.com> In-Reply-To: <4F317F07.9080101@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi Eric, On 2012-02-07 14:44, Eric Blake wrote: > On 02/07/2012 12:20 PM, Filipus Klutiero wrote: >> So are you saying that stat cannot display a file's size on disk? > Not without inventing a new % modifier, or else you doing the math > yourself. Thank you very much. I apologize for much of what I said in this report. I started with the assumption that stat could display the size on disk. When I saw that no field other than %o contained that, that %o's description read "I/O block size" and that %o indeed matched the size on disk for one file, I concluded that %o meant size on disk. It turns out that was just a coincidence, which happens only when a file fits in a single block. Please disregard everything I said about %o. From this point, please consider this bug report to be only about the descriptions of %b and %B. > So maybe it is worth adding a new one, as in: > > %S Allocated size (same as %b * %B) Absolutely. I requested that in #10755: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10755 > >>> I don't see any ambiguity. %b and %B are described in relation >>> to each other, which is all that's required. >> That's not all that's required. Each directive should have a useful >> description, not just a circular definition. >>> See how each refers to the other in the docs: >>> >>> %b Number of blocks allocated (see %B) >>> %B The size in bytes of each block reported by %b >>> >> I see that, but I fail to see how that would make the description of %b >> unambiguous. A file has a number of file system blocks allocated. I do >> not see what would prevent a reader from interpreting %b as that number. > Maybe it would help to do things like: > > %b Number of blocks allocated (see %B), corresponds to st_blocks > %B The size in bytes of each block reported by %b, or st_blksize > > for those that are familiar with the stat(2) interface. For that > matter, tying ALL of the existing % modifiers back to struct stat > members might be handy. Probably. I am not familiar with stat(2), and although that would indeed provide a way to decide which sense is meant, it would not be a very accessible one to me. I still recommend to specify the type of blocks discussed. Based on Pádraig's explanation, I believe a reference to "physical blocks" rather than "blocks" would address the problem.