fsync (+ small mremap patch)
Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Fri, 9 Jul 1999 12:43:55 MET-1
Hi MIngo, Alan, Andrea, Linus and others,
two days ago I reported that fsync() does not work correctly (unfortunately,
no one replied) and real 2.3.10 has same problem :-(
After further investigation I found that if:
(1) first fsync() was on file with length X (>= 1 disk block)
(2) file was truncated so that file length rounded up to block size
is not multiple of page size (i.e. page has not all buffers;
for example
write(fd,buff,4096);fsync(fd);ftruncate(fd,4096-1024);fsync(fd);
(3) then second fsync() fails.
As I do not understand MM and new buffer code, I'm not able to fix it
(but I have whole weekend to get it to work... or to rebuild my root
filesystem with 4KB blocks), but code in mm/filemap.c - writeout_one_page
and waitfor_one_page does not make sense to me together with code
in ext2/truncate.c... Maybe someone (vmtruncate, ext2 itself) should
remove these released buffers from page's buffer ring? For some reason,
buffer is not marked uptodate... Maybe it's time to reinvent bitflags
(and holes...) instead of simple value ;-)
And, when I was walking through MM code, I think that following patch
should be applied to mm/mremap.c:move_page_tables fail case. At least
other users of zap_page_range pass length as third parameter...
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
--- linux/mm/mremap.c.orig Fri Jul 9 10:52:27 1999
+++ linux/mm/mremap.c Fri Jul 9 12:35:56 1999
@@ -118,7 +118,7 @@
flush_cache_range(mm, new_addr, new_addr + len);
while ((offset += PAGE_SIZE) < len)
move_one_page(mm, new_addr + offset, old_addr + offset);
- zap_page_range(mm, new_addr, new_addr + len);
+ zap_page_range(mm, new_addr, len);
flush_tlb_range(mm, new_addr, new_addr + len);
return -1;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/