Blobspace versus Unix FileSystem

Under Online 4.x, you can not have more than one blob per blob page in the blobspace. However, you can put more than one blob in a dbspace page. This have a real big impact on how much disk space you would allocate when storing blobs, and puts a practical limit on usefulness of blobspace. I have no idea what options are available under Online 5.x. Can anyone help us out ? We found out that when we decided to move one table's blob data from the blobspace (average data size was around 120 bytes) into tblspace, we saved around 30mb of disk space (18,000 blobs). However, I am concerned about performance impact storing text or binary blobs in tblspace will have on Online engine. Do any one know ? In addition, during Informix archiving process, the blobspace is locked against any updates, but this does not present a major problem because we coded the 4gl application to check for update error, and will retry automatically, and will eventually prompt user for decision on whether to continue trying. We will keep this code intact, even if newer engines no longer imposes this restriction during archiving. On our platform, the Informix page is 2k bytes long, and we can only specify multiples of the Informix page size for blobspace allocation. Which means that we can only allocate 2k, 4k, 6k, or 8k.. but not 512, or even 1024 bytes. Does this restriction exist in Online 5.x ? Our blob data size averages around 10k, with a small percentage approaching 300k or more in size. However, we allocate several thousand blobs, and I feel that we would save a significant amount of disk space by switching to unix filesystem, unless newer engines will let us store more than one blob per blobpage. We are now re-evaluating the issues, and considering the possibility of storing blobs in the Unix 512 byte block filesystem in order to reduce wasted space overhead. In addition, we are also going to have to set up a way to split out several thousand blobs into separate subdirectories to avoid creating huge flat directory. I would like to hear about any pros and cons about this approach. The biggest con is that inodes is a finite resource. We plan to store more than one blob in an archive, possibly an compressed one, but keep number of files in an archive reasonably low. Are there any other approaches that could work well ? Any thoughts or insights about this subject ? Many thanks ! -- `~' (o o) o-----------------------oOo--(_)--oOo------------------------o |Paul T. Pryor Integrated Microcomputer System Services, Inc| |ACIRS III+ Project (703) 756-8350 Voice/TDD| |ptp@fallschurch-acirs2.army.mil 192.86.95.3| o------------------------------------------------------------o