9

I was compiling a custom kernel, and I wanted to test the size of the image file. These are the results:

ls -la | grep vmlinux
-rwxr-xr-x   1 root   root   8167158 May 21 12:14 vmlinux

du -h vmlinux
3.8M    vmlinux

size vmlinux
   text    data     bss     dec     hex filename
2221248  676148  544768 3442164  3485f4 vmlinux

Since all of them show different sizes, which one is closest to the actual image size? Why are they different?

Manuel Allenspach
  • 12,467
  • 14
  • 54
  • 76
chettyharish
  • 1,704
  • 7
  • 27
  • 41
  • 1
    what does `stat vmlinux` print? – Pavel May 21 '14 at 16:34
  • `ls` is reporting the on-disk size, which has nothing to do with what `size` is reporting. `du` is reporting the SAME number, just converted into megabytes instead of bytes. @pavel: `ls` uses stat() internally. there's no difference between the two, other than HOW the info's presented. – Marc B May 21 '14 at 16:37
  • 2
    how is 8167158 equal to 3.8M ?? – chettyharish May 21 '14 at 17:59

3 Answers3

13

They are all correct, they just show different sizes.

  • ls shows size of the file (when you open and read it, that's how many bytes you will get)
  • du shows actual disk usage which can be smaller than the file size due to holes
  • size shows the size of the runtime image of an object/executable which is not directly related to the size of the file (bss uses no bytes in the file no matter how large, the file may contain debugging information that is not part of the runtime image, etc.)

If you want to know how much RAM/ROM an executable will take excluding dynamic memory allocation, size gives you the information you need.

Andreas Bombe
  • 2,450
  • 13
  • 20
  • 2
    `size` gives good information for a regular binary. I think you would want to look at a map file for the linux kernel. For example, *.init* sections are dropped after the first process starts to run, etc. There may be *unwind* tables, etc which `size` may or may not deal with. – artless noise May 22 '14 at 22:30
0

Two definition need to be understood

1 runtime vs storetime (this is why size differs)

2 file depth vs directory (this is why du differs)

Look at the below example:

[root@localhost test]# ls -l
total 36
-rw-r--r-- 1 root root   712 May 12 19:50 a.c
-rw-r--r-- 1 root root  3561 May 12 19:42 a.h
-rwxr-xr-x 1 root root 71624 May 12 19:50 a.out
-rw-r--r-- 1 root root  1403 May  8 00:15 b.c
-rw-r--r-- 1 root root  1403 May  8 00:15 c.c
[root@localhost test]# du -abch --max-depth=1
1.4K    ./b.c
1.4K    ./c.c
3.5K    ./a.h
712     ./a.c
70K     ./a.out
81K     .
81K     total
[root@localhost test]# ls -l
total 36
-rw-r--r-- 1 root root   712 May 12 19:50 a.c
-rw-r--r-- 1 root root  3561 May 12 19:42 a.h
-rwxr-xr-x 1 root root 71624 May 12 19:50 a.out
-rw-r--r-- 1 root root  1403 May  8 00:15 b.c
-rw-r--r-- 1 root root  1403 May  8 00:15 c.c
[root@localhost test]# size a.out
   text    data     bss     dec     hex filename
   3655     640      16    4311    10d7 a.out

If using size not on executable, OS will report an error.

LinconFive
  • 1,718
  • 1
  • 19
  • 24
0

Empirically differences happen most often for sparse files and for compressed files and can go in both directions.

  • du < ls

Sparse files contain metadata about space needed for an application, which ls reads and applies for its result, while du doesn't. For example:

truncate -s 1m test.dat

creates a sparse file consisting entirely of nulls without disk usage, ie. du shows 0 and ls shows 1M.

  • du > ls

On the other hand du can indicate, as in your case, files which might occupy a lot of space on disk (ie. they spread among lots of blocks), but not all blocks are filled, i.e. their bytesize (measured by ls) is smaller than du (looking at occupied blocks). I observed this rather prominently e.g. for some python pickle files.

Rriskit
  • 495
  • 4
  • 15