I've got an external terabyte drive to store my scrap (actually I mean a partition on it, I've got some other partitions there). The FS used is ext3. Even after I delete some files there (so there are at least some hundreds mibs free), Nautilus shows zero free space there and does not allow to even create a directory. How to fix this?
I use Ubuntu 10.10 daily build, last updated ton the day before yesterday (Oct 03, 2010).
ext2/3/4 filesystems have a certain percentage of blocks reserved for a "privileged" user; a filesystem might appear as "almost full" yet only root can write to it. My guess is that you are hitting this limit.
By default 5% of the total filesystem size is reserved for the root
user. Both the reserved percentage and the "privileged" user can be
changed with the tune2fs command.
To change the percentage of reserved blocks to 1%, run (as root):
tune2fs -m 1 /dev/your_disk_partition_device
You can also set the reserved blocks percentage to 0, thus effectively disabling this feature on a certain partition.
To change the privileged user, run (as root):
tune2fs -u username /dev/your_disk_partition_device
More details on both options on the tune2fs man page.
Sounds like a dud disk to me (not releasing the space). Someone I was speaking to at the weekend was having the same problem with windows and a new 0.5TB HDD (I have no idea of the make I am afraid). Deleting files would remove them, however the space was not being released.
Is the Disk Utility reporting any SMART failure conditions?
You should try to delete more things just in case, things don't tend to always work with an almost full drive, try using baobab or another directory size visualizer to find out what can and should be deleted.
inodes
df -i /
tune2fs -l /dev/disk
tune2fs will tell you how many inodes were free at boot or mount time, df -i / will tell you how many inodes are free now. You can see if you are out of inodes and from how long ago the filesystem was mounted whether or not it happened suddenly.
Then you can do this to figure out where the inodes are:
find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n
That will tell you how many inodes are in each directory with whichever has the most will be at the bottom when output stops. The problem should be obvious as you'll most likely have one directory or two with millions of entries.
holla @geek_king
Processes can still occupy storage, even though the corresponding files have been deleted (filehandle is still open).
Find these with lsof -nP
