On Mon, Mar 17, 2014 at 11:11:30AM +1100, Dave Chinner wrote: > Yes, we've known about this since 2011. Right - that's a long > standing problem, and one I've never been able to isolate and so > reproduce with any luck. It can only be reproduced when you use mmap > and direct IO on the same file, and every time I've added debug to > find out where the tail block corruption was being introduced, the > data corruption goes away. It behaves just like a race condition.... See downthread. And I would be *very* surprised if it was a race - don't forget the msync() done before that write(). I think I know what's going on - O_DIRECT write starting a bit before EOF on a file with the last extent that can be grown. It fills a buffer_head with b_size extending quite a bit past the EOF; the blocks are really allocated. What causes the problem is that we have the flags set for the *first* block. IOW, buffer_new(bh) is false - the first block has already been allocated. And for direct-io.c it means "no zeroing the tail of the last block". _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
