The only limitation I can think of in DSpace itself is the size of the unique identifier by which a bitstream is retrieved. In DSpace 6, that's a UUID, which is a 128-bit number. In v5 and earlier it was a Java 'int', which is *only* 32 bits signed (so, can identify 2 billion bitstreams).
The OS filesystem that holds the bitstreams will have its own limits. Contemporary filesystem designs have limits on the order of exabytes, and billions to quintillions of files. You may need to do some tuning of your assetstore filesystem(s) to even approach those limits, though. I think it most likely that you'll first hit limits of filesystem *performance*, and particularly of backup performance. And the answer to many performance questions is "keep measuring regularly and react to signs of significant deterioration." I find backup of large services particularly worrisome. We need ways to do backup smarter, not just faster. That's true of everything, not just DSpace. -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
