Re: Ext3 File System "Too many files" with snort

[Hans Reiser <reiser@namesys.com>]

jmerkey@comcast.net wrote:

>>jmerkey@comcast.net writes:
>>
>>    
>>
>>>I may alter the on disk structures to increase this to something larger, say 
>>>      
>>>
>>16,000,000,
>>    
>>
>>>which would break ext3 on other systems.  I will look at the code for this 
>>>      
>>>
>to 
>  
>
>>see if this is 
>>    
>>
>>>even possible without the FS meta data growing so huge, it renders 
>>>      
>>>
>performance 
>  
>
>>poor.
>>    
>>
>>>These types of limits should probably be done away with with an 
>>>      
>>>
>architectural 
>  
>
>>change, 
>>
>>It's not only ext3 - one reason this limit is there because
>>in the old stat st_nlink was 16bit only. Now that stat64 is there
>>and glibc uses it by default it could be increased to 32bit, 
>>but you would need to think what to do with old applications that 
>>stat the directory. For files >2GB old stat returns an errno, 
>>maybe this would need to be done for such directories too.
>>
>>    
>>
>
>Andi,  
>
>Sounds like this is correct.    I will look at statfs().  I am very familiar 
>with this section of linux 
>with the VFS.  We should make this value 32 bit.  One solution would be to 
>instrument a 
>versioning field in the superblock so we can write the smarts into ext3/2/reiser  
>to handle
>different on-disk structures.  when a supoerblock gets read, it could detect 
>waht type of 
>on disk structures are instrumented.  
>  
>
Just use reiser4 which has disk format plugins.  reiserfs v3 should stay 
stable and undisturbed.

>Jeff  
>  
>
>>-Andi
>>
>>    
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  
>