as root, from command line, ran bleachbit --clean system.free_disk_space ...

Forums: 

Firstly, I noticed that, unlike when running as a normal user, the drive space immediately started showing in Caja as 0 bytes; when running as a normal user, the drive space gradually went down.

Second, once the command finished, there's now only about 700 MB that shows as free space on the drive; when run as a user, there was 5-10 GB that showed as free space.

What is going on??

#1 issue: some ways of running "sudo" switches the user context to the root account, so it seems in this case it is using the root's configuration file /root/.config/bleachbit.ini instead of your personal file. The root file is probably not configured for which paths to store the wipe file in, so it is doing nothing. You could try running the BleachBit GUI as root, copying the bleachbit.ini file to root's folder, or linking them.

#2 issue: you mean as root when BleachBit exits there is only 700MB of free space left, and the only option you used as root was system.free_disk_space?

---
Andrew, lead developer

I didn't use sudo; I used su -

I copied the same bleachbit.ini file to /root/.config/bleachbit before executing the command. It has the correct path, and I can see that it is creating the file there and then deleting it when it is done, just like it is supposed to.

Caja and df both report that there is only 700MB after the command was executed as root. gparted on the other hand shows 7.5GB unused (this is how much was available before running the command). df -i output seems normal, showing only 1% IUse. I ran the exact same command as the user several times for testing purposes without issues before trying as root. I have since run the command one additional time as root with the same result.

andrew, I would appreciate any thoughts you may have on why the space is not visible and how to restore it.

Hi Fred,

  1. Which version of BleachBit?
  2. Which version of Linux?
  3. Which file system (ext3, ext4, etc.)? You can check using the mount command.
  4. Have you tried rebooting?

---
Andrew, lead developer

BleachBit version 1.9.0 -- shoot, it looks like this version isn't officially released! :-(
Fedora 22
ext4
I have tried rebooting

BleachBit 1.9.0 does not have any changes that would cause this to be different than BleachBit 1.8. It should be OK for you to use.

Idea #1
In the directories listed in BleachBit preferences under Drives (or in bleachbit.ini under list/shred_drives), check for for large files that BleachBit created.

Idea #2
Does the Size reported by df match the size of the partition reported by gparted? If not, you may need to grow the partition. (This does not have anything to do with BleachBit, though.) See also Fedora “disk full”, df, du (gui) confirm but gparted shows the partition is big enough

---
Andrew, lead developer

In my testing, BleachBit has only ever created one file (or at least it has only had one file at a time); the file now longer shows in Caja or ls -a after BleachBit finished.

I saw the file in Caja while BleachBit was running. It disappeared when BleachBit finished.

df -h / df
Filesystem Size Used Avail Use% Mounted on
/dev/sdb2 144G 136G 1.1G 100% /run/media/Fred/Other Stuff
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb2 150608100 141803332 1131220 100% /run/media/Fred/Other Stuff

Notice that the "available" space if significantly less than Size minus Used. What makes the unused space unavailable?

gparted
Used: 137.65 GiB (94%)
Unused: 8.40 GiB (6%)
Size: 146.05 GiB

I don't think that issue on stackexchange is necessarily the same thing, as I'm having this problem on a non-LVM partition and not inside VirtualBox.

The problem is that the "Reserved block count" for the partition got set to 1914291 (5%) ...

fixing was a matter of running the following command:
tune2fs -m 0 /dev/sdb2

I just ran BleachBit again as root and the problem did not re-occur. Do you have any ideas about how this might have happened the first time? The "Reserved block count" was definitely increased during the time when BleachBit was running the first time as root -- I know this because I watched the available disk space shrink from about 7GB at the time to 0 bytes before going back up to about 700MB once BleachBit's temporary file was deleted.

I must have got confused somehow. Maybe I copied a multi-GB file to that partition before running BleachBit as root, and I failed to refresh Caja to see the reduced available space. That is the best explanation I can come up with.

I am glad you traced this to the Reserved Block Count. Based on Google searches, mkfs defaults to reserving 5%. BleachBit should not be changing it, and if it does, then please do let me know.

Example

dd if=/dev/zero of=/tmp/fs count=1 bs=10M
mkfs -t ext4 /tmp/fs
dumpe2fs /tmp/fs | grep -i count

Output
Block count: 10240
Reserved block count: 512

512/10240=5%

---
Andrew, lead developer