"Get info" and volume space bar show wrong amount of free space

[janiczek]

The dialog "Get info" on a hard disk shows far less free space than there actually is; the same goes for the volume space bar on the icon. DiskUsage application also seems to be affected (screenshots below).

du -sh shows (at least to me) correct amount of cca 3 GB used.

I'm running VMware Fusion with 8GB IDE hard disk, formatted by the DriveSetup application to Be File System. Maybe that could be source of the error?

@ hrev44144

[janiczek]

"Get info" dialog and "du -sh" command

[janiczek]

Disk Usage utility - showing /boot

[janiczek]

Disk Usage utility - showing free space

[axeld]

"du" only considers the size of the files, not the space they actually use up; I believe there is an option to make it show the actual used up space (like waste for the block size used, attributes, etc.).

Furthermore, a file system itself uses up space for things you don't see. In the case of BFS, this includes the indices, and the log area among other things. Tracker's "Get Info" will show you what the file system reports as free which is 100% accurate, actually.

[anevilyak]

Replying to axeld:

Furthermore, a file system itself uses up space for things you don't see. In the case of BFS, this includes the indices, and the log area among other things. Tracker's "Get Info" will show you what the file system reports as free which is 100% accurate, actually.

A discrepancy of ~3GB seems like too much for just block waste though. Would perhaps be interesting to see the output of checkfs -c /boot, I seem to recall some instances in the past where a freshly built image had issues like this for some reason, though I don't recall the cause.

[janiczek]

Replying to anevilyak:

Replying to axeld:

Furthermore, a file system itself uses up space for things you don't see. In the case of BFS, this includes the indices, and the log area among other things. Tracker's "Get Info" will show you what the file system reports as free which is 100% accurate, actually.

A discrepancy of ~3GB seems like too much for just block waste though. Would perhaps be interesting to see the output of checkfs -c /boot, I seem to recall some instances in the past where a freshly built image had issues like this for some reason, though I don't recall the cause.

~/Desktop> checkfs -c /boot
        102564 nodes checked,
        0 blocks not allocated,
        0 blocks already set,
        2096069 blocks could be freed

        files           88820
        directories     13510
        attributes      123
        attr. dirs      96
        indices         15

        direct block runs               100894 (2.71 GiB)
        indirect block runs             176 (in 5 array blocks, 10.19 MiB)
        double indirect block runs      0 (in 0 array blocks, 0 bytes)

[anevilyak]

Replying to janiczek:

~/Desktop> checkfs -c /boot

[...]

        2096069 blocks could be freed

That would explain it, running checkfs without -c should clear those. The more interesting question would be how it got into that state though, was that installation created via the build system, or installed from a CD/USB stick, or some other means?

[janiczek]

Replying to anevilyak:

Replying to janiczek:

~/Desktop> checkfs -c /boot

[...]

2096069 blocks could be freed

}}}

That would explain it, running checkfs without -c should clear those. The more interesting question would be how it got into that state though, was that installation created via the build system, or installed from a CD/USB stick, or some other means?

If I recall correctly:

• created the VM with R1 Alpha 3 VMDK (had 2GB HDD)
• created new 8GB HDD using VMware
• initialized as Be File System with the Drive Setup app
• made bootable
• installed Haiku with the Installer app
• changed boot priority to the new HDD
• deleted the old HDD

EDIT: thank you, anevilyak :) checkfs worked.

[janiczek]

State after checkfs