Messages in this thread | | | Date | Sat, 4 Apr 2009 20:20:13 -0400 | From | Theodore Tso <> | Subject | Re: [GIT PULL] Ext3 latency fixes |
| |
On Sat, Apr 04, 2009 at 03:13:13PM -0700, Linus Torvalds wrote: > And yes, anticipatory seems to be quite noticeably better than cfq here. > With cfq I got a few two-second delays on 'ftruncate()' too (probably > because of your new serialization code?), and the longest fsync() delay > was over 7 seconds. That was definitely solidly in the "painful" category.
What is going on with in your "ftruncate()" case? The synchronization code I added will do call filemap_flush() on close if the file descriptor had been previously truncated down to zero, either because it was opened with O_TRUNCATE, or if ftruncate(fd, 0) was explicitly called. But it won't actually call fsync() or do anything special on the actual ftrucate() call; it just sets a flag indicating that the file in question should be flushed on close.
This is to make the right thing happen for applications which try to edit a file in place via:
fd = open("foo", O_RDWR); len = read(fd, buf, MAXBUF); <modify buf> ftruncate(fd, 0); write(fd, buf, len); close(fd);
Otherwise, given the lack of fsync(fd) in the above sequence, a crash may leave he file "foo" truncated or only partially written out.
- Ted
| |