Messages in this thread | | | From | jmerkey@comcast ... | Subject | Re: Ext3 File System "Too many files" with snort | Date | Fri, 09 Jul 2004 18:30:45 +0000 |
| |
> 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.
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/
| |