/ full?

Patrick Miller pert at tas-kc.com
Tue Dec 3 04:09:00 CST 2002


I am not sure what causes it, but I have lost space (never been able to 
free some space) after the file system says it is too full to write to. 
Since you said this it did declare it full perhaps someone knows another 
trick. Usually its only a small amount that does not add up, not a large 
bit of missing bytes.  

Jim Herrmann wrote:

>I have a 4096 block size.  If what Steven is saying is true, that would 
>certainly be a reason for going to reiserfs.  However, what you are saying, 
>Hal, is that du is the tool to determine if a drive is full.  Now, du 
>indicates that I'm only using about 2.4G of space on my 5.3G / partition, and 
>df says I'm using 5.2G.  When I go to install a new RPM, it says there's no 
>room at the inn.  Acutally it says /usr, but it's the holidays.  :-)  So, 
>that space IS being used by something.  I have rebooted just to make sure 
>that no processes are holding any files.  Now, is there some sort of deamon 
>that is supposed to be running to clean up deleted inodes?  I've never heard 
>of this before, but that is certainly no proof that it doesn't exist.
>
>I'm thinking this has got to be something to do with /usr.  The last time I 
>installed, I had something like a 500M / partition and a 3G /usr partition, 
>and I didn't have any trouble.  It's possible that there's a bug in MDK9 that 
>doesn't clean up lost data blocks, but that seems extremely remote.  Could it 
>be bad blocks?  How do I check for that?
>
>I'm about ready to do a clean install of everything but /home.  I'm not seeing 
>a clear path to redemption here.  Any other ideas?
>
>Thanks to everyone for your time in considering this quandry.
>
>Jim
>
>On Monday 02 December 2002 12:49 pm, Hal Duston wrote:
>  
>
>>On Wed, 17 Jan 2001, Steven Elling wrote:
>>    
>>
>>>On Monday 02 December 2002 00:20, Jim Herrmann wrote:
>>>      
>>>
>>>>Man, I'm learning some great commands here, but I still don't see why
>>>>DU and DF don't match up.
>>>>        
>>>>
>>>I think the reason they don't match is because du asks the kernel for the
>>>size of each file and df asks the kernel how many blocks are being used
>>>by all the files on the file system.
>>>
>>>By default when mke2fs is used to create a file system the block size is
>>>set to 4096 typically.  So as far as the space being used on the file
>>>system is concerned, a 1 byte file will use up 4096 bytes on the file
>>>system.  If you have 1024 1-byte files, all the files will take up
>>>4194304 bytes (4 Meg) on the file system.  This would explain why df
>>>always shows more space being used as compared to du.
>>>      
>>>
>>No.  `du' reports blocks in use as well.
>>
>>$ mkdir x
>>$ cd x
>>$ for i in a b c d e f g h i j k l m n o p q r s t u v w x y z
>>$ do echo > $i
>>$ done
>>$ du -k .
>>105     .
>>$ du -b .
>>107520  .
>>$ du -h .
>>105K    .
>>
>>The most likely culprit is files that have been removed from the
>>filesystem, but are still held open by some process.  `du' reports blocks
>>used by each and every object that is reachable with a valid filename.
>>`df' reports blocks in used by the filesystem.  That may include files
>>that are still in use, but have been removed from the filesystem.
>>
>>My mechanisim to chase down file-system usage is "du -kx | sort -nr".  -k
>>for kilobytes, -x for one-file-system, -n for numeric sort, and -r for
>>reverse.
>>
>>Hal
>>    
>>
>
>
>
>  
>

-- 
--
Patrick Miller -- Telephone Answerette Systems Inc.
IS/Telecom Tech. -- EVE Soon to be Infinity 
Kansas City, MO 
Ofc 816-753-7332 -- Cell 816-210-4077




More information about the Kclug mailing list