-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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>
JS> The, '-s' does not report anything in number of bytes, but in number of
JS> *units of 512 bytes*.
JS>
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>
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> passed.
JS>
JS>
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>
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
JS> $

That looks confusing to me.  Why '-s' should even be working with '-l' is
beyond me.

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...

$ bc
4741076 % 8192
6100
8192 - (4741076 % 8192)		<double check that I'm doing it right>
2092
(4741076 + 2092) % 8192
0
(4741076 + 2092) / 1024		<round up to the next disk block size>
4632
$

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>
JS> The last output should have been
JS>
JS> $ ls -lsh foo
JS>  2.0K -rw-------  1 jschauma  wheel  512K Aug  5 14:46 foo
JS> $
JS>
JS> to indicate that there are (rounded up) 2K units of 512 byte blocks.
JS>
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?]

				--*greywolf;
- --
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)

iD8DBQFBEosuPHvwcY2+w1kRAv2xAJ4/dlrN/sz6hY89s2kNqw8rrO5RiACdENij
f2z8n9tlAdhupZVKicOJoAQ=
=0Xpl
-----END PGP SIGNATURE-----