NetBSD-Users archive

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

Re: ls(1) displays wrong file sizes



jgw%freeshell.org@localhost writes:
- Noticed this the other day; if I run 'du -h <random dir>' and compare
- the files sizes to those reported by 'ls -sh1' they don't match. For
- example:
- 
- # ls -sh1 PROJECTS/LISP/code/*.lsp
- 4.2K PROJECTS/LISP/code/fsvm.lsp
- 205B PROJECTS/LISP/code/hello.lsp
- 1.7K PROJECTS/LISP/code/recursion.lsp
- 1.1K PROJECTS/LISP/code/test.lsp
- 4.5K PROJECTS/LISP/code/tictactoe
- 
- # du -h PROJECTS/LISP/code/*.lsp
- 6.0K    PROJECTS/LISP/code/fsvm.lsp
- 2.0K    PROJECTS/LISP/code/hello.lsp
- 2.0K    PROJECTS/LISP/code/recursion.lsp
- 2.0K    PROJECTS/LISP/code/test.lsp
- 6.0K    PROJECTS/LISP/code/tictactoe.lsp
- 
- Not only do they not match, they don't seem to be off by any set amount
- or ratio.  I don't have BLOCKSIZE set and my filesystem is the default
- FFS.  Some system specifics below:

[...]

- # dumpfs -s / | head -n 9
- file system: /dev/rwd0a
[...]
- bsize 16384 shift 14  mask  0xffffc000
- fsize 2048  shift 11  mask  0xfffff800
- 
- Is this a known issue/bug or is there something I've overlooked?

Someting you've overlooked.  du(1) tells you the sum of the size
of the filesystem blocks occupied, while ls -s is telling you the
number of 512 byte units used. (and actually, it looks like the -h
flag is really acting like -l with "humanization" applied.)

1.7KB would be 2.0KB on the filesystem (you have 2K
fragments on the filesystem), 205B is still going to occupy one
fragment, so it's going to show up as 2.0KB in du, etc..

--
Eric Schnoebelen                eric%cirr.com@localhost         
http://www.cirr.com
      "There are four boxes to be used in defense of liberty:
       soap, ballot, jury, and ammo. Please use in that order."
                                                  -Ed Howdershelt (Author)


Home | Main Index | Thread Index | Old Index