Wrong free space reported

S

SIFE

I have trouble with free space left, if I run
Code: 
$ df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad6s1a    223G    200G    4.8G    98%    /
devfs          1.0K    1.0K      0B   100%    /dev
procfs         4.0K    4.0K      0B   100%    /proc
linprocfs      4.0K    4.0K      0B   100%    /usr/compat/linux/proc
/dev/fuse0       0B      0B      0B   100%    /usr/home/SIFE/.gvfs
Witch doesn't make scene,Avail column should display 23G as space left not 4.8G. I did some googling and I found that a bug, but I didn't find how to fix it.
 
This an FAQ, 8% of the space in an UFS filesystem is reserved for root account and is not usable by normal accounts, what you're seeing is normal. Nothing to "fix".
 
Hello,

Guys, I have ~500GB hdd and using it whole as single slice and partition on my data server (UFS2+S).

df -h shows me 451GB full size and 415GB free size, whereas used 0.

So have I paid those 36GB for stability and FS performance?

I wouldn't have to pay that price would I use NTFS or EXT3 being still confident in data consistency and without performance decrease, would I?

(FreeBSD8.3)

Thanks
 
The extra space is not gone, it's just a reserve. As mentioned above, you can change it with tunefs(8) if you think it's wise.

It's not a price, it's a default safety feature.

No idea whether there is an equivalent with NTFS or ext3, or how they perform when they get nearly full. Neither is usable as a stock FreeBSD filesystem, so it's not really a useful comparison. ZFS is the logical alternative to UFS, and it would be interesting to see how much free space is actually available on the same disk after formatting with ZFS.
 
Neither is usable as a stock FreeBSD filesystem, so it's not really a useful comparison.
Click to expand...
I didn't mean FreeBSD + NTFS/EXT3 but FreeBSD(UFS) | Windows(NTFS) | Linux (Ext3). I just need to keep data cheaply reliably and share it via SMB (home server not production ;-) ).

...and it would be interesting to see how much free space is actually available on the same disk after formatting with ZFS.
Click to expand...
ZFS, didn't think about it. Will read related reviews. Thanks

Also keep in mind that a 500GB harddrive is actually 465GiB
Click to expand...
You are right! Where is my extra 14GB of guaranteed space? I'll investigate that ;-)

NTFS reserves 10%.
Click to expand...
Didn't know that, but as per MS even more - 12,5%.
NTFS reserves 12.5 percent of the volume for exclusive use of the MFT until and unless the remainder of the volume is completely used up. Thus, space for files and directories is not allocated from this MFT zone until all other space is allocated first.
Click to expand...

It would be nice if UFS behaves alike.
 
gumkins said:
You are right! Where is my extra 14GB of guaranteed space? I'll investigate that ;-)
Click to expand...
There isn't any. Harddrive manufacturers must use the SI prefixes. So 1GB is 1.000.000.000 bytes, not 1.073.741.824.
 
I took that into account, 500GB = 500000000000/1024/1024/1024 = 465GiB. Not 451GiB!

Here is info from my server
Fdisk
Code: 
Disk name:      ad4                                    FDISK Partition Editor
DISK Geometry:  969021 cyls/16 heads/63 sectors = 976773168 sectors (476940MB)

Offset       Size(GB)        End     Name  PType       Desc  Subtype    Flags

         0          0         62        -     12     unused        0
        63        465  976773167    ad4s1      8    freebsd      165

Disklabel
Code: 
Disk: ad4       Partition name: ad4s1   Free: 0 blocks (0MB)

Part      Mount          Size Newfs   Part      Mount          Size Newfs
----      -----          ---- -----   ----      -----          ---- -----
ad4s1d    <none>        465GB *

df -h
Code: 
Filesystem     Size    Used   Avail Capacity  Mounted on
...
/dev/ad4s1d    451G    3.9G    411G     1%    /mnt/data

So does anybody know what's going on?
 
gumkins said:
I took that into account, 500GB = 500000000000/1024/1024/1024 = 465GiB. Not 451GiB!
Click to expand...
You forgot to subtract the 8% reserved space, leaving you with something like 428GiB. So you actually have more than I would have expected.
 
Eight percent reserved of the 451GBs on filesystem ad4s1d is roughly 36GBs and you have almost 4GBs in use, seems to match almost exactly.
 
Eight percent reserved of the 451GBs on filesystem ad4s1d is roughly 36GBs and you have almost 4GBs in use, seems to match almost exactly.
Click to expand...

That's what df shows as full disk size. But it is wrong as full size is 465.

465 - 8% = 427.8 GiB (or ~459GB).

But "df" shows me 411(free) + 3.9(used) = 414.9 GiB.

Still lacks of ~13GiB. And I still don't understand where 451G has come from.
 
gpart show
Code: 
=>       1  78165359  ad0  MBR  (37G)
         1        62       - free -  (31k)
        63  78165297    1  freebsd  [active]  (37G)

=>       0  78165297  ad0s1  BSD  (37G)
         0   2097152      1  freebsd-ufs  (1.0G)
   2097152   6207104      2  freebsd-swap  (3G)
   8304256  11491328      4  freebsd-ufs  (5.5G)
  19795584   2097152      5  freebsd-ufs  (1.0G)
  21892736  56272561      6  freebsd-ufs  (26G)

=>       63  976773105  ad4  MBR  (465G)
         63  976773105    1  freebsd  [active]  (465G)

=>        0  976773105  ad4s1  BSD  (465G)
          0  976773105      4  freebsd-ufs  (465G)
 
I saw that article before.

The only difference between situation described in it and my one that I had new just created FS.

I've just re-created slice and partition again and have the same figures.

df -h /mnt/data
Code: 
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad4s1d    451G    4.0k    415G     0%    /mnt/data

I've specified 0% minimum free space threshold and it released 8% space
tunefs -m 0 /dev/ad4s1d
Code: 
tunefs: minimum percentage of free space changes from 8% to 0%
tunefs: should optimize for space with minfree < 8%

But still up to 451GiB, not to 465GiB.
df -h /mnt/data
Code: 
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad4s1d    451G    4.0k    451G     0%    /mnt/data

Thus, still interesting where are those 14GiB are lost.
 
You must log in or register to reply here.
Back
Top