Subject: Re: ls -lsh
To: Jan Schaumann <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 08/05/2004 12:31:54
-----BEGIN PGP SIGNED MESSAGE-----
Thus spake Jan Schaumann ("JS> ") sometime Today...
JS> I'm trying to think what the correct behaviour for 'ls -lsh' is. The
JS> manual page specifies that '-h' modifies the '-s' option to report sizes
JS> in bytes displayed in human readable format.
JS> The, '-s' does not report anything in number of bytes, but in number of
JS> *units of 512 bytes*.
JS> If we combine 'ls -lsh', then the '-s' column at the beginning is
JS> dropped completely, presumably b/c if we were to display the number of
JS> bytes displayed in a human readable form it would be the same as the
JS> 'size' column in human readable form.
JS> Now either we should mention that '-h' overrides '-s', or we should make
JS> '-s' report something in human readable format if both flags are
JS> Humanizing that value would mean -- as far as I understand it -- that if
JS> we had a file that occupies 1024 units of 512 bytes, then that number
JS> should be reported as 1.0K (or maybe 2.0K rounded up).
JS> $ dd if=/dev/zero of=/var/tmp/foo bs=512 count=1024
JS> $ ls -ls /var/tmp/foo
JS> 1040 -rw------- 1 jschauma wheel 524288 Aug 5 14:46 /var/tmp/foo
JS> $ ls -lsh /var/tmp/foo
JS> -rw------- 1 jschauma wheel 512K Aug 5 14:46 /var/tmp/foo
That looks confusing to me. Why '-s' should even be working with '-l' is
Secondly, ls should be (and I think it is) examining the BLOCKSIZE envariable.
...and indeed it does.
$ ls -lsh /netbsd
- -rwxr-xr-x 1 root wheel 4.5M Jul 31 17:20 /netbsd
$ ls -ls /netbsd # I keep BLOCKSIZE set to 1k to avoid nasty surprises
4640 -rwxr-xr-x 1 root wheel 4741076 Jul 31 17:20 /netbsd
$ BLOCKSIZE=2048 ls -ls /netbsd # 2k blocks
2320 -rwxr-xr-x 1 root wheel 4741076 Jul 31 17:20 /netbsd
$ BLOCKSIZE= ls -ls /netbsd # half-k blocks
9280 -rwxr-xr-x 1 root wheel 4741076 Jul 31 17:20 /netbsd
Having '-s' work with '-l' boggles me.
Also, doesnt -s report the number of blocks which are actually allocated
to the file, or something? Something isn't right with the -s option.
Assuming an 8k/1k filesystem, which my root fs seems to be:
$ df /
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd1a 65423 55102 7050 88% /
$ dumpfs /dev/rwd1a | egrep -e '[fb]size'
bsize 8192 shift 13 mask 0xffffe000
fsize 1024 shift 10 mask 0xfffffc00
sbsize 2048 cgsize 3072
Taking the size of /netbsd (4741076 bytes (whatever happened to a 2M kernel,
BTW...)), and rounding up to the next blocksize...
4741076 % 8192
8192 - (4741076 % 8192) <double check that I'm doing it right>
(4741076 + 2092) % 8192
(4741076 + 2092) / 1024 <round up to the next disk block size>
As you can see, ls -s reports 4640 1k blocks, even though the size
- -- rounded up and fully populated -- is 8 shy of that.
Something is slightly amiss.
JS> The last output should have been
JS> $ ls -lsh foo
JS> 2.0K -rw------- 1 jschauma wheel 512K Aug 5 14:46 foo
JS> to indicate that there are (rounded up) 2K units of 512 byte blocks.
JS> Does that make sense at all?
Um, not really, because would it not only be using *1k* units of 512-byte
blocks? (last I looked, 2048 * 512 == 1048576 == 1024k == 1M).
I would find such output to be confusing, especially considering that
I'm almost never interested in the number of 512-byte blocks that a file
takes up; if anything, I'd be interested in the number of (fs_bsize) blocks
I'm using, or "%d+%d", nblocks, nfrags.
JS> (FWIW, Linux ls(1) reports
JS> 516k -rw------- 1 jschauma cs 512k Aug 5 14:54 /var/tmp/foo
JS> whatever that's supposed to mean.)
Evidently reporting in 1k blocksizes, somehow accruing an extra 4k somewhere.
[the inode is in its own "space" and aren't disk inodes 128 bytes or
something like that? Or is my age showing again...? Anyway, where's that
extra 4k coming from?]
Theorem #1: There are several ways to create a quantum black hole.
- Butter a piece of bread and tie it, buttered side up, to a cat's back.
- Launder any number of matched pairs of socks.
- Divide by zero. Someone will disappear. It might be your lucky day.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----