topic Re: linux 32000 files limitation in Alfresco Archive

linux 32000 files limitation

paul_lahitte — Mon, 09 Jun 2008 14:52:17 GMT

I am using alfresco community on redhat linux and lucenes-indexes/workspace/SpacesStore is containing 32001 directories. The systems refuses creating new dir "too many links" and then Alfresco is not starting while it is trying to create anew directory.the log:java.io.IOException: Cannot create dire

Re: linux 32000 files limitation

pmonks — Mon, 09 Jun 2008 22:01:47 GMT

I believe this is a filesystem limit that can't easily be changed. That said, Lucene should not be creating so many directories since Alfresco includes a background job that periodically merges the Lucene index fragments together. Would it be possible to do a full reindex and watch to see if the problem persists?

A full reindex can be performed by:

Setting index.recovery.mode=FULL in custom-repository.properties

Restart Alfresco

Note that reindexing will take a while if you have a lot of content, so if this is a production system it's best to schedule this for a maintenance window.

Cheers,
Peter

Re: linux 32000 files limitation

paul_lahitte — Tue, 10 Jun 2008 02:41:05 GMT

I did'nt mention I am running community 2.1 running I did a full index recovery .
It look's like it is done smoothly (sorry it's french):
23:23:24,747 INFO [node.index.FullIndexRecoveryComponent] RÃ©cupÃ©ration de lindex dÃ©butÃ©e : {0} transactions.
23:27:42,557 INFO [node.index.FullIndexRecoveryComponent]    10 % achevÃ©.
23:34:29,295 INFO [node.index.FullIndexRecoveryComponent]    20 % achevÃ©.
23:44:26,847 INFO [node.index.FullIndexRecoveryComponent]    30 % achevÃ©.
23:54:44,340 INFO [node.index.FullIndexRecoveryComponent]    40 % achevÃ©.
00:05:02,756 INFO [node.index.FullIndexRecoveryComponent]    50 % achevÃ©.
00:16:06,846 INFO [node.index.FullIndexRecoveryComponent]    60 % achevÃ©.
00:27:30,280 INFO [node.index.FullIndexRecoveryComponent]    70 % achevÃ©.
00:38:05,534 INFO [node.index.FullIndexRecoveryComponent]    80 % achevÃ©.
00:47:27,022 INFO [node.index.FullIndexRecoveryComponent]    90 % achevÃ©.
00:59:55,407 INFO [node.index.FullIndexRecoveryComponent]    100 % achevÃ©.
00:59:55,411 INFO [node.index.FullIndexRecoveryComponent] RÃ©cupÃ©ration de l'index achevÃ©e. (index restore done)

Then I try to restart Alfresco but her I got an error:
alfresco would'nt stop !

# ./alfresco.sh stop
Using CATALINA_BASE:   /opt/alfresco/tomcat
Using CATALINA_HOME:   /opt/alfresco/tomcat
Using CATALINA_TMPDIR: /opt/alfresco/tomcat/temp
Using JRE_HOME:       /data/jdk1.6.0_03
CompilerOracle: exclude org/apache/lucene/index/IndexReader$1 doBody
CompilerOracle: exclude org/alfresco/repo/search/impl/lucene/index/IndexInfo$Merger mergeIndexes
CompilerOracle: exclude org/alfresco/repo/search/impl/lucene/index/IndexInfo$Merger mergeDeletions
10 juin 2008 04:30:41 org.apache.catalina.startup.Catalina stopServer
GRAVE: Catalina.stop:
java.net.ConnectException: Connection refused
   at java.net.PlainSocketImpl.socketConnect(Native Method)
   at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
   at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
   at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
   at java.net.Socket.connect(Socket.java:519)
   at java.net.Socket.connect(Socket.java:469)
   at java.net.Socket.<init>(Socket.java:366)
   at java.net.Socket.<init>(Socket.java:180)
   at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:395)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:344)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:435)

and the java process is still running .

root      5270     1 97 Jun09 pts/2    05:04:27 /data/jdk1.6.0_03/bin/java -Xms1024m -Xmx1024m -server -Dfile.encoding=UTF8 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/opt/alfresco/tomcat/conf/logging.properties -Djava.endorsed.dirs=/opt/alfresco/tomcat/common/endorsed -classpath :/opt/alfresco/tomcat/bin/bootstrap.jar:/opt/alfresco/tomcat/bin/commons-logging-api.jar -Dcatalina.base=/opt/alfresco/tomcat -Dcatalina.home=/opt/alfresco/tomcat -Djava.io.tmpdir=/opt/alfresco/tomcat/temp org.apache.catalina.startup.Bootstrap start

Do you think reindexing is done or not ?. When I look in the lucene-indexes it look's like it is very very small compared to what it was but too small to be tue.

lightWeightVersionStore:
total 12
drwxr-xr-x 2 root root 4096 jun 10 02:03 4b661ffa-366a-11dd-b803-4bb39d114b58
-rw-r–r– 1 root root 106 jun 10 02:03 IndexInfo
-rw-r–r– 1 root root 106 jun 10 02:03 IndexInfoBackup

SpacesStore:
total 8
-rw-r–r– 1 root root 20 jun 9 23:12 IndexInfo
-rw-r–r– 1 root root 20 jun 9 23:12 IndexInfoBackup

Re: linux 32000 files limitation

paul_lahitte — Tue, 10 Jun 2008 10:39:13 GMT

I does not work , I tried on the huge directory workspace/SpacesStores but it fails since alfresco tries to create directories.
I am reloading a full backup database+alfresco content but there are already 31830 directories in lucene workspace/SpacesStores.
I will try first to rebuild indexes (if less than 170 directories are to be created by alfresco ) and if this fails I will try to rebuild indexes in an empty dir .

Do I really need lucene-Indexes to have a running sytem ? What if I try starting with index.recovery.mode=NONE or AUTO ?
Help would be appreciated since my production system is beeing down for 20H00 now !!

Re: linux 32000 files limitation

pmonks — Tue, 10 Jun 2008 16:39:39 GMT

I don't think a restore is necessary, since it's only the indexes that are problematic (and the indexes are a derived asset - they can be rebuilt from scratch at any time). But if you do wish to restore, I'd encourage you to take another backup (see http://wiki.alfresco.com/wiki/Backup_and_Restore) before hand, just in case your backup set is corrupted or whatever.

I would also recommend doing a slightly modified version of the full reindex (regardless of whether you restore or not) to see if that helps:

Stop Alfresco

Set index.recovery.mode=FULL in custom-repository.properties

Move the lucene-indexes directory out of the way (rename, move or delete the lucene-indexes directory)

Restart Alfresco

Note that the progress report you see during startup only reports on the synchronous (metadata indexing) part of the reindex process. The asynchronous part (full text indexing) happens concurrently after the system has started, and depending on how much content you have could take quite a while (full text indexing involves extracting text from all of your documents, which is both an I/O and CPU intensive operation).

In other words, after Alfresco has started you should wait for CPU and I/O usage to settle down (ie. until the asynchronous portion of the reindex process has completed) before attempting to stop Alfresco again - otherwise you'll be back to square one again (invalid indexes).

Cheers,
Peter

Re: linux 32000 files limitation

paul_lahitte — Tue, 10 Jun 2008 21:50:33 GMT

Thank's alot for your precious answers. I am right now doing it. But I have 2 questions
After the synchronous part of the process is the directory lucene-index supposed to get bigger ? (on my system the size hasen't change since the end of the synchronous part ).
Is alfresco unavailable (via the web client) until the end of the whole index rebuilt ? (3 hours after the synchronous part of the process I can see open files in the index directory and a java process consuming CPU but still cant get access to the login page

Paul

Re: linux 32000 files limitation

pmonks — Tue, 10 Jun 2008 21:57:05 GMT

After the synchronous part of the process is the directory lucene-index supposed to get bigger ?

While the asynchronous indexing is occurring, yes the indexes should grow. Once the asynchronous portion of the reindex has completed it should stabilise, with slow growth as new content is added to the repository.

Is alfresco unavailable (via the web client) until the end of the whole index rebuilt ?

No - it should be available the entire time (albeit with full text searches not returning any of the content that hasn't been full text indexed yet).

What exactly happens when the login page is requested? Do you see anything unusual in the alfresco.log?

Cheers,
Peter

Re: linux 32000 files limitation

paul_lahitte — Tue, 10 Jun 2008 22:56:35 GMT

Nothing in the catalina.out after the end of the synchronous part:

tail -f catalina.out
10 juin 2008 19:33:37 org.apache.catalina.core.StandardService start
INFO: DÃƒÂ©marrage du service Catalina10 juin 2008 19:33:37 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.2310 juin 2008 19:33:37 org.apache.catalina.core.StandardHost start
INFO: XML validation disabled10 juin 2008 19:33:37 org.apache.catalina.startup.HostConfig deployWAR
INFO: DÃƒÂ©ploiement de l'archive alfresco.war de l'application web19:33:52,252 WARN [remoting.rmi.RmiRegistryFactoryBean] Could not detect RMI re
gistry - creating new one19:33:53,686 WARN [alfresco.util.OpenOfficeConnectionTester] A connection to Op
enOffice could not be established.
19:33:55,298 INFO [domain.schema.SchemaBootstrap] Schema managed by database di
alect org.hibernate.dialect.MySQLInnoDBDialect.
19:33:59,898 INFO [domain.schema.SchemaBootstrap] Aucune modification na ÃƒÂ©tÃƒÂ©
apportÃƒÂ©e au schÃƒÂ©ma.
19:34:02,799 INFO [node.index.FullIndexRecoveryComponent] RÃƒÂ©cupÃƒÂ©ration de lin
dex dÃƒÂ©butÃƒÂ©e : {0} transactions.
19:47:01,948 INFO [node.index.FullIndexRecoveryComponent]    20 % achevÃ©.
19:57:50,672 INFO [node.index.FullIndexRecoveryComponent]    30 % achevÃ©.
20:08:54,842 INFO [node.index.FullIndexRecoveryComponent]    40 % achevÃ©.
20:18:59,557 INFO [node.index.FullIndexRecoveryComponent]    50 % achevÃ©.
20:30:34,372 INFO [node.index.FullIndexRecoveryComponent]    60 % achevÃ©.
20:41:58,095 INFO [node.index.FullIndexRecoveryComponent]    70 % achevÃ©.
20:53:31,487 INFO [node.index.FullIndexRecoveryComponent]    80 % achevÃ©.
21:03:36,333 INFO [node.index.FullIndexRecoveryComponent]    90 % achevÃ©.
21:16:59,832 INFO [node.index.FullIndexRecoveryComponent]    100 % achevÃ©.
21:16:59,835 INFO [node.index.FullIndexRecoveryComponent] RÃ©cupÃ©ration de l'index achevÃ©e.

The java process is still running and files are still open but the size of the lucene-indexes are unchanged since the end of the synchronous part.

ava      5790      root 183u      REG      253,2        193   35882278 /data/opt/alf_data/lucene-indexes/system/system/IndexInfo
java      5790      root 188u      REG      253,2        193   35882279 /data/opt/alf_data/lucene-indexes/system/system/IndexInfoBackup
java      5790      root 189r      REG      253,2       2772   35882281 /data/opt/alf_data/lucene-indexes/system/system/69b57a6e-3713-11dd-a558-0f01f70fbb44/_0.cfs
java      5790      root 190u      REG      253,2        106   35882286 /data/opt/alf_data/lucene-indexes/user/alfrescoUserStore/IndexInfo
java      5790      root 191u      REG      253,2        106   35882287 /data/opt/alf_data/lucene-indexes/user/alfrescoUserStore/IndexInfoBackup
java      5790      root 192u      REG      253,2        106   35882290 /data/opt/alf_data/lucene-indexes/workspace/lightWeightVersionStore/IndexInfo
java      5790      root 193u      REG      253,2        106   35882291 /data/opt/alf_data/lucene-indexes/workspace/lightWeightVersionStore/IndexInfoBackup
java      5790      root 194u      REG      253,2          0   35882295 /data/opt/alf_data/lucene-indexes/archive/SpacesStore/IndexInfo
java      5790      root 195u      REG      253,2          0   35882296 /data/opt/alf_data/lucene-indexes/archive/SpacesStore/IndexInfoBackup
java      5790      root 196u      REG      253,2          0   35882298 /data/opt/alf_data/lucene-indexes/workspace/SpacesStore/IndexInfo
java      5790      root 197u      REG      253,2          0   35882299 /data/opt/alf_data/lucene-indexes/workspace/SpacesStore/IndexInfoBackup

Client web is timing out when trying to connect …

Re: linux 32000 files limitation

paul_lahitte — Tue, 10 Jun 2008 23:23:44 GMT

Do you know if there is a way to disable this feature to allow my users access their documents ?
The server is not available since 2 days and it is getting critical for us ?

cheers
paul

Re: linux 32000 files limitation

pmonks — Tue, 10 Jun 2008 23:27:15 GMT

Have you taken a thread dump after the login page times out, and looked for liveness issues? It sounds like something is deadlocked and a common source of deadlocks is a database connection pool that's too small.

Cheers,
Peter

Re: linux 32000 files limitation

paul_lahitte — Wed, 11 Jun 2008 09:09:31 GMT

I left the process running all night (I was quite depressed and tired and went to bed).
In the morning the procees java was stopped and the log was full of warnings .

I restarted Alfresco with index.recovery.mode=VALIDATE and it started !!!
Now my lucene-indexes directory is containing only 37 directories and is 1.2 Gb sized (sounds better!).

I still have lots of warnings and errors related to lucene in the log file but at least peolpe can connect and work …

Part of catalina.out


at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:210)
   at $Proxy9.index(Unknown Source)
   at org.alfresco.repo.search.impl.lucene.fts.FTSIndexerJob.execute(FTSIndexerJob.java:52)
   at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
   … 1 more
Caused by: java.lang.UnsupportedOperationException: The content never exists
   at org.alfresco.repo.content.EmptyContentReader.getDirectReadableChannel(EmptyContentReader.java:59)
   at org.alfresco.repo.content.AbstractContentReader.getReadableChannel(AbstractContentReader.java:226)
   at org.alfresco.repo.content.AbstractContentReader.getContentInputStream(AbstractContentReader.java:330)
   … 17 more
[WARNING] Unknown Ptg 1c (28)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 3c (60)
[WARNING] Unknown Ptg 14 (20) at cell (15,26)
09:31:18,983 ERROR [quartz.core.JobRunShell] Job DEFAULT.ftsIndexerJobDetail threw an unhandled Exception: 
org.alfresco.service.cmr.repository.ContentIOException: Failed to open stream onto channel: 
   accessor: ContentAccessor[ contentUrl=store://2008/6/11/9/31/61bba49c-3788-11dd-b926-13890b8e687a.bin, mimetype=null, size=0, encoding=UTF-8, locale=fr_FR]
   at org.alfresco.repo.content.AbstractContentReader.getContentInputStream(AbstractContentReader.java:337)
   at org.alfresco.repo.search.impl.lucene.ADMLuceneIndexerImpl.indexProperty(ADMLuceneIndexerImpl.java:858)
   at org.alfresco.repo.search.impl.lucene.ADMLuceneIndexerImpl.createDocuments(ADMLuceneIndexerImpl.java:542)
   at org.alfresco.repo.search.impl.lucene.ADMLuceneIndexerImpl.updateFullTextSearch(ADMLuceneIndexerImpl.java:1248)
   at org.alfresco.repo.search.impl.lucene.fts.FullTextSearchIndexerImpl.index(FullTextSearchIndexerImpl.java:188)
   at sun.reflect.GeneratedMethodAccessor382.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:281)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:187)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:154)
   at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:107)
   at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
   at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:210)
   at $Proxy9.index(Unknown Source)
   at org.alfresco.repo.search.impl.lucene.fts.FTSIndexerJob.execute(FTSIndexerJob.java:52)
   at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
   at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:529)
Caused by: java.lang.UnsupportedOperationException: The content never exists
   at org.alfresco.repo.content.EmptyContentReader.getDirectReadableChannel(EmptyContentReader.java:59)
   at org.alfresco.repo.content.AbstractContentReader.getReadableChannel(AbstractContentReader.java:226)
   at org.alfresco.repo.content.AbstractContentReader.getContentInputStream(AbstractContentReader.java:330)
   … 17 more

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Any clues ?
Thank's again for your help .

Paul

Re: linux 32000 files limitation

jjf — Mon, 23 Jun 2008 16:20:30 GMT

We have encountered the same issue (the index folder has hit its limitation). I do believe the merging process is working, however, it is merging at a rate slower than our content updates. So, over the course of time, it will always fill with indexes and lock up the system. Is there any workaround besides clearing the indexes and doing a full index? Is there a way to stop the full text index from running?

Re: linux 32000 files limitation

tman — Tue, 01 Jul 2008 04:37:14 GMT

Same problem here: after reindexing, lucene creates another 32000 directories, and it hangs again. Another reindexing is needed.
Is there any method of overpassing this limitation and this ongoing manual reindexing?

Thanks

Re: linux 32000 files limitation

karlovitz — Wed, 02 Jul 2008 14:59:22 GMT

This question is 2 fold, we are currently building an alfresco implementation out for a client. I am relatively new to alfresco so I am trying to learn all I can before making bad decisions. This 32000 file limitation scares me as we will be storing a large number of assets. Is there a way around this? Should we re index on a regular basis?

This brings me to my next question, I am currently experiencing a performance problem when searching on our assets. Takes anywhere from 20 - 30 seconds to return a basic lucene text query. My first step was to rebuild the indexes passing in recovery_mode=FULL, although the log file says that the indexing is complete, tomcat didn't move on to start up.

08:55:31,310 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent] 90 % complete.
09:04:30,916 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent] 100 % complete.
09:04:30,932 INFO [org.alfresco.repo.node.index.FullIndexRecoveryComponent] Index recovery completed.

I have waited about an hour now for the cpu to settle down and tomcat to finish the start up process, however I am getting impatient. I saw that a previous poster stated that once the indexing is complete an asynchronys process will kick off to do the rest of the job and tomcat will continue. This, however is not what is happening. Does anyone have any ideas.

Re: linux 32000 files limitation

karlovitz — Wed, 02 Jul 2008 17:57:17 GMT

One other note is that while running this rebuild my sqlserver has consumed over 850 meg of memory and is climbing while tomcat is hovering around 600 meg. I am only rebuilding 14,000 transactions. Any ideas would be very helpful.

Steve

Re: linux 32000 files limitation

andy — Fri, 08 Aug 2008 14:14:58 GMT

Hi

Is this a simple Alfrecso install? If not what have you changed?
Was anything reported in the Alfresco logs?
Have you got any custom code?

Andy

Re: linux 32000 files limitation

andy — Fri, 22 Aug 2008 09:15:02 GMT

Hi

Please include the exact version of Alfresco.
Were there any exceptions related to index merging in the logs?
It is possible for the background merge to die and not recover on some versions of the product.
However, there will always be something in the log when this happens.

The back ground full text serach index can output errors from the convertors.
Some docuements can not convert and in some cases there is missing content etc etc.
Nothing has gone wrong.

You can search for the offending files using nitf and ninc (as described on the search wiki page)

Andy

Re: linux 32000 files limitation

jjf — Tue, 30 Sep 2008 13:26:20 GMT

Andy,

Thanks for the response. It is a basic "out-of-the-box" setup using Community Release 2.0. We have also tried this using the 2.1 release in our DEV env. From what I can tell, over time, transactions in the system will always cause indexes to increase. At some point, the indexes will hit 32,000 files and cause the system to become unstable.

I've checked the logs and, as far as I can tell, the merging isn't reporting any errors. Is there a different logging level I need to use to see errors with the merge process? If I monitor the index directory, I see the folder count going up and down which seems to me like the merging is occuring. However, over time (weeks/months), the index folders always increases.

Please let me know if I can give you any more information.

Re: linux 32000 files limitation

jjf — Tue, 30 Sep 2008 16:05:04 GMT

One thing we noticed is we wrote some customer code which adds/removes users to Alfresco via a batch. It's just a Java Quartz job which runs and calls personSvc.createPerson(), authSvc.createAuthentication(), and authoritySvc.addAuthority() (also remove/delete methods too). This code seemed to be creating one index per user. So if we had 32,000 users, there would be problems. We disabled the batch so that this wouldn't happen. Is this the expected behavior (one index per user transaction)?

Re: linux 32000 files limitation

louise — Fri, 03 Oct 2008 10:18:56 GMT

Some background:

Since ext3 aims to be backwards compatible with the earlier ext2, many of the on-disk structures are similar to those of ext2. Because of that, ext3 lacks a number of features of more recent designs, such as extents, dynamic allocation of inodes, and block suballocation. There is a limit of 31998 sub-directories per one directory, stemming from its limit of 32000 links per inode.

The maximum number of inodes (and hence the maximum number of files and directories) is set when the file system is created. If V is the volume size in bytes, then the default number of inodes is given by V/213 (or the number of blocks, whichever is less), and the minimum by V/223. The default was deemed sufficient for most applications. The max number of subdirectories in one directory is fixed to 32000.

ReiserFS is still limited by the 16 bit link count for directories, so you can't have more than around 65,000 subdirectories with the same parent. BTW: This limitation even exists in the "Mother of all network attached file systems", ONTAP on NetApp Filers.

The solution would be (or MUST be) a better Lucene indexing algorithm, not the limit change in filesystem. How we can store more than 32000 users in Alfresco authorization?