Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Df reports zero bytes free on my /dev/hda6. This is a 35 G ext3 partition which was almost full until yesterday. At one moment I moved something onto it from another partition. And after that df started reporting 0 bytes free. And no matter what I delete from it, there are still 0 bytes free. And the worst is that I can put things onto it without getting "out of space" error. I mention that I ran fsck and it didn't gave any errors. Weird, huh? Does anyone have any idea of what could be wrong? Thank you.
Yes. You were right. Moving some large video files out out of the partition solved the problem. Thank you. However, my logic does not see the reason for which df run as root doesn't report the free space including the reserved 5%.
The logic of keeping the reserved 5% secret is so that the standard user does not take the unavailable (reserved) space into consideration. You can see the total space with tune2fs (run as root). For example:
# df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdd1 404727 369777 18244 96% /tmp
# tune2fs -l /dev/sdd1
tune2fs 1.32 (09-Nov-2002)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 6c114425-117e-4026-90df-4068ac4b7212
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 102408
Block count: 417658
Reserved block count: 16706
Free blocks: 34950
Free inodes: 97512
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2008
Inode blocks per group: 251
Last mount time: Tue Dec 9 05:03:43 2003
Last write time: Tue Dec 9 05:03:43 2003
Mount count: 13
Maximum mount count: 29
Last checked: Sat Nov 29 05:23:33 2003
Check interval: 15552000 (6 months)
Next check after: Thu May 27 06:23:33 2004
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal UUID: <none>
Journal inode: 81
Journal device: 0x0000
First orphan inode: 19
Note that tune2fs reports 417658 blocks with 34950 free blocks of which 16706 are reserved. 34950 - 16706 = 18244 which is the amount free reported by df.
Note also that 417658 - 16706 = 400952, which happens to be less than the total blocks reported by df (404727 blocks). I am not sure where the difference (3775 blocks) is. I have to admit that I was expecting them to match. I suspect it lies either in the superblocks or the ext3 journal, and could be resolved by the used space reported by df in an empty filesystem after creation. THAT is just a guess, but hopefully this clarifies things just a bit and gives you another CLI tool for your kit.