riderplus wrote:
>
> I wanted to find out how much free space I have on my HDD, so I issued:
>
>
> Code:
> --------------------
> df -h
> --------------------
>
Try df -H with a capital H
df -H
–
Version 3.10.2
openSUSE 13.1 (Bottle) (x86_64) 64-bit
Kernel Linux 3.11.6-4-desktop
Where are my penguins :- https://features.opensuse.org/316767
>
> Since BTRFS file system is experimental, I am not so familiar with it,
> so I have no idea why the partitions seem to be bigger
Not experimental. But as btrfs stores old copies of files as snapshots, and those copies use space
that doesn’t show in all commands, well, it would explain the discrepancy.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))
In my case, they add up for NTFS and FAT file systems, but not for ext2 or ext4.
I’m pretty sure that this is unix tradition. Used + Avail should add up to 100%, but a file system can actually be filled to about 105%. Non-root processes cannot write over 100%, but root can continue until it is really full. The idea is supposed to be to keep some space unused so that sector allocation can be done in a way that minimizes fragmentation problems.
On 12/29/2013 08:16 AM, nrickert wrote:
>
> riderplus;2612227 Wrote:
>> FWIW, 7.9G added to 9.4G is not 19G (on sda1). Also, 73G added to 15G is
>> not 92G…am I being silly?
>
> In my case, they add up for NTFS and FAT file systems, but not for ext2
> or ext4.
>
> I’m pretty sure that this is unix tradition. Used + Avail should add up
> to 100%, but a file system can actually be filled to about 105%.
> Non-root processes cannot write over 100%, but root can continue until
> it is really full. The idea is supposed to be to keep some space unused
> so that sector allocation can be done in a way that minimizes
> fragmentation problems.
Close. A vanilla mkfs for extX file systems reserves 5% of the disk space for
exclusive use by root. With this reserve, the system can still boot even if the
disk has been filled by non-root users. That gives the user a chance to recover
from a runaway condition without needing to find and boot a rescue disk. That 5%
accounts for most, if not all, of your “missing” disk.
If you want to reduce the amount of the reserved space, ‘man mkfs.ext4’ will
tell you how to do it.
On 2013-12-30 05:36, Tyler K wrote:
>
> robin_listas;2612376 Wrote:
>>
>> (19-7.9-9.4)/19 = 0.89
>> That’s more than 5% lost, it is 11%. a remedial math class awaits you rotfl!
Would you care to explain…?
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))
On 2013-12-30 16:16, Tyler K wrote:
>
> 19G total
> 7.9G used
> 9.4G reported available
> leaves a discrepancy of 1.7G
> 1.7G / 19G = 0.089… IOW, 8.9%
Well, that’s the exact figure I gave, with the decimals misplaced, because of how my calculator
presented them (a machine I seldom use nowdays, that’s my excuse).
In any case, 8.9% is way more than the 5% reserved for root.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))
On 12/30/2013 4:03 PM, Carlos E. R. wrote:
> On 2013-12-30 16:16, Tyler K wrote:
>>
>> 19G total
>> 7.9G used
>> 9.4G reported available
>> leaves a discrepancy of 1.7G
>> 1.7G / 19G = 0.089… IOW, 8.9%
>
> Well, that’s the exact figure I gave, with the decimals misplaced, because of how my calculator presented them (a
> machine I seldom use nowdays, that’s my excuse).
>
> In any case, 8.9% is way more than the 5% reserved for root.
>
If you examine the rounding error of the calculation you will find that it may account for a fair amount of this. v=19G
has clearly rounded to an integer value and so the rounding error is ±0.5. 7.9G and 9.4G are clearly rounded to the
nearest tenth and so have an error of ±.05G. The error in the calculation of u=19-7.9-9.4 is bounded by the sum of the
errors, or .5+.05+.05=0.6. Using differentials to estimate the error in the quotient u/v, one has |d(u/v)|
<=(v|du|+u|dv|)/v^2 = [19(.6)+(1.7)(.5)]/19^2 = .0339. Thus the true value of 8.9 lies somewhere between 0.089±.0339
or .1229 and .0551. i.e. 12.3% and 5.5%.
It is not exactly clear just how df rounds values. According to “info coreutils aqdf invocationaq”
(http://www.gnu.org/software/coreutils/manual/html_node/df-invocation.html), “Non-integer quantities are rounded up to
the next higher unit.” How this applies to 7.9 and 9.4 is not clear. If we assume the error for 19G is bounded by 0
and -1.0 while for 7.9 and 9.4 the error is bounded by 0 and -0.1; then using these errors and not passing to absolute
value (we know the sign of the error) the error is bounded by 0 and -0.037. Thus .089 could be as small as .052 or 5.2%
–
P.V.
“We’re all in this together, I’m pulling for you” Red Green
>> In any case, 8.9% is way more than the 5% reserved for root.
>>
> If you examine the rounding error of the calculation you will find that it may account for a fair
> amount of this. v=19G has clearly rounded to an integer value and so the rounding error is ±0.5.
> 7.9G and 9.4G are clearly rounded to the nearest tenth and so have an error of ±.05G. The error in
> the calculation of u=19-7.9-9.4 is bounded by the sum of the errors, or .5+.05+.05=0.6. Using
> differentials to estimate the error in the quotient u/v, one has |d(u/v)| <=(v|du|+u|dv|)/v^2 =
> [19(.6)+(1.7)(.5)]/19^2 = .0339. Thus the true value of 8.9 lies somewhere between 0.089±.0339 or
> .1229 and .0551. i.e. 12.3% and 5.5%.
Hum.
Well, you could use ‘df’ without the -h, and you get 1k block outputs instead, way more accurate.
That would clarify our doubts in that respect.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))
On 2013-12-31 05:06, Fraser Bell wrote:
>
> robin_listas;2612589 Wrote:
>>
>> Well, that’s the exact figure I gave, with the decimals misplaced,
>> because of how my calculator
>> presented them (a machine I seldom use nowdays, that’s my excuse).
>>
>
> Mebbe the calculator did that on purpose to get back at you for ignoring
> it all this time…
>
>
Yeah.
She does run out of batteries now and then, and they are the button type, meaning I have to go to
special shops to buy them again. I bought “her” about 1986…
If I had to buy a new one I would be totally flabbergasted.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))
