Daniel Phillips <phill...@phunq.net> writes: > If Ext3 is the problem, then this is highly topical for us. We hope > to implement a largely non-blocking commit model for Tux3 and have > discussed the strategy for doing this. I expect we will run into some > surprises when we actually start running with atomic commit, and shortly > after, start working on the layered cache model. Also, our initial > fsync will just be a sync, roughly speaking, which is sure to cause > latency problems, so we will need a finer grained model there.
Yes, it's like sync. In my understanding although, fsync() of ext3 tries to flush the transaction for the inode, it will flushes all transactions until that transaction. And data=ordered will try to flush datas before related metadata transactions. So, after all, fsync() will flushes many datas unrelated to that fsync(). Thanks. -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp> _______________________________________________ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
