Otto Moerbeek wrote:
On Sun, 15 Jan 2006, Daniel Ouellet wrote:
[snip lots of talk by a confused person]
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 524097 63 4.2BSD 2048 16384 328 # Cyl 0*- 519
b: 8388576 524160 swap # Cyl 520 - 8841
c: 78165360 0 unused 0 0 # Cyl 0 - 77544
d: 2097648 8912736 4.2BSD 2048 16384 328 # Cyl 8842 - 10922
e: 52429104 11010384 4.2BSD 2048 16384 328 # Cyl 10923 - 62935
f: 2097648 63439488 4.2BSD 2048 16384 328 # Cyl 62936 - 65016
g: 10486224 65537136 4.2BSD 2048 16384 328 # Cyl 65017 - 75419
h: 2132865 76023360 4.2BSD 2048 16384 328 # Cyl 75420 -
77535*
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 524097 63 4.2BSD 1024 8192 86 # Cyl 0*- 519
b: 8388576 524160 swap # Cyl 520 - 8841
c: 58633344 0 unused 0 0 # Cyl 0 - 58167
d: 1048320 8912736 4.2BSD 1024 8192 86 # Cyl 8842 - 9881
e: 27263376 9961056 4.2BSD 1024 8192 86 # Cyl 9882 - 36928
f: 2097648 37224432 4.2BSD 1024 8192 86 # Cyl 36929 - 39009
g: 9436896 39322080 4.2BSD 1024 8192 86 # Cyl 39010 - 48371
h: 9874368 48758976 4.2BSD 1024 8192 86 # Cyl 48372 - 58167
Since the bsize and fsize differ, it is expected that the used kbytes of the
file systems differ. Also, the inode table size will not be the same.
Not sure that I would agree fully with that, but I differ to your
judgment. Yes there will and should be difference in usage as if you
have a lots of small files, you are waisting more space if you fsize are
bigger, unless I don't understand that part. Would it mean that the df
-h would take the number of inode in use * the fsize to display the
results for human then?
You're comparing apples and oranges.
I don't disagree to some extend as you know better, but I still try to
understand it however. Shouldn't the df -h display the same results
however to human? I am not arguing, but rather try to understand it. If
it is design to be human converted, why a human would need to know or
consider the file size in use then to compare the results?
BTW, you don't say which version(s) you are running. That's bad. since
some bugs were fixed in the -h display. Run df without -h to see the
real numbers.
All run 3.8. Sorry about that.
the 4.6GB have 4870062 * 1024 = 4,986,943,488
www1# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 256814 41464 202510 17% /
/dev/wd0h 1048158 54 995698 0% /home
/dev/wd0d 1030550 2 979022 0% /tmp
/dev/wd0g 5159638 310910 4590748 6% /usr
/dev/wd0e 25799860 4870062 19639806 20% /var
/dev/wd0f 1030550 1546 977478 0% /var/qmail
the 8.1GB have 15967148 * 512 = 8,175,179,776
# df
Filesystem 512-blocks Used Avail Capacity Mounted on
/dev/wd0a 513628 65588 422360 13% /
/dev/wd0h 1861628 52 1768496 0% /home
/dev/wd0d 2061100 4 1958044 0% /tmp
/dev/wd0g 9904156 424544 8984408 5% /usr
/dev/wd0e 33022236 1537612 29833516 5% /var
/dev/wd1b 16412252 1937920 13653720 12% /var/mysql
/dev/wd0f 2061100 4 1958044 0% /var/qmail
/dev/wd1a 41280348 15967148 23249184 41% /var/www/sites
The funny part is that the first above /var include more files then the
/var/www/sites below and still display less space in use.
To check if the inode/block/fragment free numbers add up, you could
use dumpfs, but that is a hell of a lot of work.
-Otto
It's not a huge deal and the systems works well, I am just puzzle by the
results and want to understand it, that's all.
