Messages in this thread |  | | Date | Thu, 8 Aug 1996 12:07:59 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: 5% reserved discrepancy (minor nitpick) |
| |
Hi,
On Tue, 6 Aug 1996 15:39:02 -0700 (PDT), Robert Woodcock <rcw@netcom.com> said:
> I made my fs with the mke2fs from Slackware 3 (0.5a), and I'm currently > running on kernel 2.0.0. I have not used tune2fs since then, so I still have > the default 5% set for root. A friend on #linux noticed that df wasn't quite > adding up (he's running on Redhat 3.0.3, exact same problem, then again, > same mke2fs version :)
> mercury:~$ df / > Filesystem 1024-blocks Used Available Capacity Mounted on > /dev/hda5 659003 527991 95835 85% / > mercury:~$ /sbin/fdisk -l > [snip] > Device Boot Begin Start End Blocks Id System > [snip] > /dev/hda5 261 261 609 703552+ 83 Linux native > [...]
> 527991+95835=623826 > 659003-623826=35177 /* tune2fs also gives this number */ > 35177*20=703540 /* 1/20 = 5% */ > ^^^^^^ > Shouldn't that turn out to 659000? Or is this the desired behavior?
It's all working fine. The reserved space --- 35177 blocks, in this case --- is exactly 1/20 of the entire filesystem, 703552 blocks. There are 659003 available blocks on the filesystem, of which 35177 are reserved only for root leaving 623826 available for normal users.
The "problem" is that tune2fs and mke2fs are calculating the reserved space as a fraction of the partition size, not as a fraction of the data blocks on the filesystem. Inode tables, bitmaps and filesystem descriptors all incur some overhead on the filesystem so the number of data blocks available will always be a bit less than the number of blocks on the partition, and you could argue that the reserved space should be calculated against the number of data blocks, not the size of the partition.
Cheers, Stephen. -- Stephen Tweedie <sct@dcs.ed.ac.uk> Department of Computer Science, Edinburgh University, Scotland.
|  |