> > The truncate will free blocks and require block allocation on subsequent > writes. That might be something you could look into trying to avoid > (e.g., keeping files around and reusing space), but that depends on your > application design. This one is a bit hard. We have a journal-like structure for the modifications issued to the data store, which dominates most of our write workloads (including this one that I am discussing here). We could keep they around by renaming them outside of user visibility and then renaming them back, but that would mean that we are now using twice as much space. Perhaps we could use a pool that can at least guarantee one or two allocations from a pre-existing file. I am assuming here that renaming the file won't block. If it does, we are better off not doing so. > Inodes chunks are allocated and freed dynamically by > default as well. The 'ikeep' mount option keeps inode chunks around > indefinitely (even if individual inodes are all freed) if you wanted to > avoid inode chunk reallocation and know you have a fairly stable working > set of inodes. I believe we do have a fairly stable inode working set, even though that depends a bit on what's considered stable. For our journal-like structure, we will keep them around until we are sure the information is safe and them delete them - creating new ones as we receive more data. But that's always bounded in size. Am I correct to understand that ikeep being passed, new allocations would just reuse space from the empty chunks on disk? > Per-inode extent size hints might be another option to > increase the size of allocations and perhaps reduce the number of them. > That's absolutely greatastic. Our files for that journal are all more or less the same size. That's a great candidate for a hint. > Brian Thanks again, Brian _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
