On Sun, 15 Jan 2006, Daniel Ouellet wrote: > Otto Moerbeek wrote: > > On Sun, 15 Jan 2006, Daniel Ouellet wrote:
> > 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? I do not understand what you mean. Of course df does not do such calculation, because it does not mean anything. Inodes allocated does have little to do with total space in use. fsize is fragment size, which is something different than file size. > > 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? The human thing is only doing the conversion to megabytes and such. It does not compensate for space wasted due to blocks not being fully used and such. Now I agree that the difference you are seeing is larger than I would expect. I would run a ls -laR or du -k on the filesystems and diff the results to see if the contents are realy the same. My bet is that you'll discover some files that are not on the system with a smaller usage. It is also perfectly possible that files having holes (also called spare files) play a role: they take less space than their length, but depending on how you copy them, the copy does take the full amount of blocks. > > 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 above display used df -k, while the one below does not. Probably you've set some alias for df or so, or you are using the BLOCKSIZE env var. Why are you making things more difficult than needed for us (and yourself?). > > 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.
