David Masover wrote: > > > And it's not just databases. Consider BitTorrent. The usual > BitTorrent way of doing things is to create a sparse file, then fill > it in randomly as you receive data. Only if you decide to allocate > the whole file right away, instead of making it sparse, you gain > nothing on Reiser4, since writes will be just as fragmented as if it > was sparse.
If you don't flush it before you fill it, then in reiser4 it does not matter if it starts out sparse. > > Personally, I'd rather leave it as sparse, but repack everything later. We have 3 levels of optimization: 1) at each modification, 2) at each flush, and 3) at each repack. Each of these operates on a different time scale, and all 3 are worthy of doing as right as we can. Now, the issue of where should airholes be? Why, that is the grand experiment that will start to happen in a few months. Nobody knows yet what defaults we should have, and whatever we choose, there will be some users who gain from explicit control of it. > it must not be as trivial as I think it is. The problem is that there was a list of must dos, and this was just one of them. If reiser4 goes in, then fsync is the only thing in front of the repacker. The list has reduced in size a bunch. > >> A much better approach in my opinion would be to have Reiser4 perform >> well in the majority of cases without the repacker, and sell the >> repacker to people who need that extra bit of performance. If I'm not >> mistaken this is actually Hans intent. > > > Hans? Yes, that's the idea. Only sysadmins of large corps are likely to buy. We throw in service and support as well for those who purchase it. If I was making money, I would not do this, but I am not. I am not really willing to work a day job for the rest of my life supporting guys in Russia, it is only ok to do as a temporary measure. I am getting tired.... > >> If Reiser4 does turn out to >> perform much worse over time, I would expect Hans would consider it a >> bug or design flaw and try to correct the problem however possible. > > I would want Reiser4 without a repacker to outperform all other filesystems. The problem with this fragmentation over time issue is that it is hard to tweak allocation, measure the effect, tweak again, etc. Not sure how to address it without a lot of work. Maybe we need to create some sort of condensed portage benchmark.... Hans Hans
