> Stop right there. If you are doing lots of appending writes, and you > dont want to lose no more than 5 seconds, why do you have 15 files? > Why send your appending writes into a single file and then later on, > disaggregate out the logs when you need to read them? There are 15 files because those are different entities. There might be less of them, some of them can be removed. There is no reason to place those files close to each other since those are just metadata related to mpeg stream and in fact it is best to put stream and metadata close to each other. If I wanted to localize those small files, I would just put them on a different partition. Anyway, if I have to implement a file system inside a file, why do I need top layer file system? : ) > With 15 files, > no matter what you are doing, you will be forcing the heads to seek > all over the place, and since the 4k blocks won't be full when you > sync them, you're wasting write cycles and disk bandwidth. Yes, seeks are unavoidable, but that's something I have to account in worst case scenario anyway. Huh, yes. Another advantage of ext4 is that I can control writeback on a specific file range. I sync only complete pages and ext4 is happy to commit whatever was synced. Generic solution would be to cache pages in app and submit only complete ones. Disadvantage of generic solution is that data cached by app is invisible to others. Regards, Andrey. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
