bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22363: Bug of stat in bash


From: Eric Blake
Subject: bug#22363: Bug of stat in bash
Date: Tue, 19 Jan 2016 09:40:52 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

[re-adding the list, with permission]
[top-posting makes it harder to follow conversations on a technical
list; I'm reformatting your message]

On 01/16/2016 04:14 AM, Arturo wrote:
> Eric, thank you very much for your response. I don't know the question of 
> .jpg added, excuse me.

Basically, I was trying to point out that a screenshot of text is less
efficient than the actual text itself, when it comes to the size of the
email sent describing a problem.  It's a common first-timer mistake
(you're not the first one who has sent a .jpg instead of
copying-and-pasting text), and I was merely trying to help you avoid the
problem in the future.

> I've read your response and I don't understand "almost nothing" (I'm beginner 
> in this field). What means so the number 159744 in my case, despite the real 
> size of the files contained? I can't obtain their origin (blocks x number of 
> blocks...?)

The 'st_size' of a directory is how much disk space is occupied by that
directory, and is dependent on the choice of file system used.  And it
has nothing to do with how much space is occupied by the files within
that directory.

A common page size is 4k; and 159744 happens to be 39 * 4k.  So one
could assume that on that particular file system, your directory
occupies 39 pages of disk space.  But without knowing which file system
you are using, nor how many files are in that directory, that's all the
more I can tell you.

Maybe some examples from my system will help:

$ ls -ld /etc
drwxr-xr-x. 154 root root 12288 Jan 18 07:41 /etc/
$ stat -f /etc
  File: "/etc"
    ID: a18b6460f08a5036 Namelen: 255     Type: ext2/ext3
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 12868767   Free: 7633334    Available: 6973878
Inodes: Total: 3276800    Free: 3029863
$ ls -a /etc | wc
    292     292    2966

That says that my /etc resides on an ext[234] file system (actually
ext4, but the kernel folks made it rather hard for 'stat -f' to tell the
difference between the three versions).  It says that my file system was
formatted to allocate in pages (or "Fundamental block size") of 4k bytes
each.  So my /etc occupies 12288 bytes, or 3 pages.  Then I counted how
many actual entries there are, and 'wc' reports 292 lines.  Knowing what
I do about powers of 2, that means I could assume that 1 4k page will
allow me to create 128 files (or put another way, the directory only
needs 32 bytes per file to record its name and attributes, for the sizes
of names I have used), and because I have between 256 and 384 files, I
needed three pages in the directory to hold all 292 files.  But of
course, this is all guessing; I could create really long file names
(such as a file name longer than 32 bytes) to throw off all the math I
did above.  Ultimately, at the end of the day, I don't care how many
pages my directory required, as long as it is able to hold all the files
I created within it.

> What is their practical sense?I commented you the first time the different 
> result obtained in two "identicals" Ubuntu 14.04, this 159744 and 4096. Why 
> the file system "assign" 159744 to the directory in my laptop and only 4096 
> in other laptop? It is a "reserved" space, for example?

Most likely, it is because one system has more files in the directory
than the other, and those additional files required allocating
additional pages to the directory in order to track those file names.
Or maybe because the two systems are NOT identical, but are using
different filesystems, where each file system has different rules on how
much space will be occupied by a directory.

But the whole art of file systems is a very involved concept, so it is
probably sufficient to leave it to the file system experts (I am not
one), and to just remember that 'st_size' of a directory is usually not
the information you are looking for.

> 
> Otherwise, finally I had resolved my script with du.Best regards. 

I'm glad to hear that 'du' is indeed what you were looking for.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]