nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

linux 32000 files limitation

paul_lahitte

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 directory: /data/opt/alf_data/lucene-indexes/workspace/SpacesStore/e51ff042-3628-11dd-b952-2b903bc78fd4        at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:175)        at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:227)
        at org.alfresco.repo.search.impl.lucene.index.IndexInfo$Merger.mergeIndexes(IndexInfo.java:2943)
        at org.alfresco.repo.search.impl.lucene.index.IndexInfo$Merger.run(IndexInfo.java:2448)        at java.lang.Thread.run(Thread.java:619)
ERROR [org.alfresco.repo.search.impl.lucene.index.IndexInfo] Failed to merge indexes
java.io.IOException: Cannot create directory: /data/opt/alf_data/lucene-indexes/workspace/SpacesStore/e55b2483-3628-11dd-b952-2b903bc78fd4
        at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:175

Does any one know how to increase this number ??

Thank's

Find more posts tagged with

Comments

pmonks

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

paul_lahitte

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

paul_lahitte

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 !!

pmonks

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

paul_lahitte

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

pmonks

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

paul_lahitte

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 …

paul_lahitte

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

pmonks

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

paul_lahitte

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

jjf

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?

tman

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

karlovitz

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.

karlovitz

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

andy

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

andy

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

jjf

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.

jjf

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)?

louise

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?

louise

A shell script to test limitation (script results more than 100.000 on OSX 10.5):

#!/bin/bash
#
# Simple node limit test script by LouiSe@louise.hu
#
# Known Linux limitation:
#  - Ext2, Ext3: 32000
#  - ReiserFS: 64K
#
TESTDIR="test"
LIMIT=100000
a=1

mkdir ${TESTDIR}

while [ "$a" -le $LIMIT ]
do
    echo "mkdir ${TESTDIR}/$a"
    mkdir "${TESTDIR}/$a"
    let "a+=1"
done‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

andy

Hi

There should not be this many directories.

Have you got any custom code?
What configuration changes have you made?

If there seems to be any kind of hang then you need to obtain a stack trace.

Andy

jjf

We had a batch job which added thousands of users to the Alfresco store using addAuthority, addPerson, etc. An index was created for every call to these methods. We switched to packaging these calls as one transaction job. This seems to only create one index and is much more efficient.

dwilson

We had a batch job which added thousands of users to the Alfresco store using addAuthority, addPerson, etc. An index was created for every call to these methods. We switched to packaging these calls as one transaction job. This seems to only create one index and is much more efficient.

This thread is frightening indeed- along with the others like it. It makes my stomach sink at the thought that my repository might soon hit the inode limit in Linux, and days of production server downtime followed by potential tomcat start-up failure is the only way to fix it.

To Alfresco Engineers - based on jjf's result quoted above are there some session/transaction guidelines we need to be following with our code? I also have (php) code that batch imports thousands of pieces of content, should I only be saving the session at the end of the entire script to avoid the inode limitation? Is this problem only related to the user store? Has this problem been reproduced and fixed/noted in newer releases?

Thanks for the help!
-Dave

etzapata

Hi All,

Does anyone managed to fix this? I have huge content (around 380GB) and encounters some errors so I was thinking that reindexing would fix the problem but full reindex (per alfresco.log) did not continue. It stops (or seems to stop) at 60% and never continue even until the next 2 days.

When I looked at catalina.out it says:
08:11:24,237 INFO [node.index.FullRecoveryComponent] 100 % complete.
08:11:24,244 INFO [node.index.FullRecoveryComponent] Index recovery completed.

[WARNING] Unknown Ptg 2a (42) at cell (350,2)

Could my problem be the same as what is being discussed in this thread?

I would be very grateful for any inputs anyone can share.

Thank you very much.

EriC z.

p.s. I would like to delete a huge single file (3.6GB in size) directly in alf_data/contentstore. Is this okay without affecting anything? I'm sure the DB will not be in sync vs. contentstore but is it fixed somehow with reindex and totally delete the entry in DB?