Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#8571 closed bug (invalid)

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

Reported by: janiczek Owned by: axeld
Priority: normal Milestone: R1
Component: File Systems/BFS Version: R1/Development
Keywords: disk usage bfs Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

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

Attachments (4)

get_info_du_sh.png (30.3 KB ) - added by janiczek 8 years ago.
"Get info" dialog and "du -sh" command
disk_usage_used.png (38.5 KB ) - added by janiczek 8 years ago.
Disk Usage utility - showing /boot
disk_usage_free.png (37.9 KB ) - added by janiczek 8 years ago.
Disk Usage utility - showing free space
after_checkfs.png (22.1 KB ) - added by janiczek 8 years ago.
State after checkfs

Download all attachments as: .zip

Change History (9)

by janiczek, 8 years ago

Attachment: get_info_du_sh.png added

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

by janiczek, 8 years ago

Attachment: disk_usage_used.png added

Disk Usage utility - showing /boot

by janiczek, 8 years ago

Attachment: disk_usage_free.png added

Disk Usage utility - showing free space

comment:1 by axeld, 8 years ago

Resolution: invalid
Status: newclosed

"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.

in reply to:  1 ; comment:2 by anevilyak, 8 years ago

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.

in reply to:  2 ; comment:3 by janiczek, 8 years ago

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)

in reply to:  3 ; comment:4 by anevilyak, 8 years ago

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?

Last edited 8 years ago by anevilyak (previous) (diff)

in reply to:  4 comment:5 by janiczek, 8 years ago

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.

Last edited 8 years ago by janiczek (previous) (diff)

by janiczek, 8 years ago

Attachment: after_checkfs.png added

State after checkfs

Note: See TracTickets for help on using tickets.