Hi Zheng, I can confirm the bug exists on latest RHEL 6 x86_64 kernels (2.6.32-220). On current mainline kernels all writes are limited to one page under 2GB, which masks the problem. I have not checked if mainline 2.6.32 has this limit or not. It does not matter: the limit is just a band-aid to paper over filesystem bugs, and should not mean you don't fix filesystem bugs. I can confirm the one line patch to fs/ext4/file.c does fix the problem. I have test kernels based on 2.6.32-220.7.1.el6.x86_64 with only the patch applied, at http://www.helsinki.fi/~joorava/kernel/ if anyone else is interested in testing. I did some (limited) testing on ext4 with the patch. It fixes the problem: large writes work very well too. No problems popped up in testing. Tested-by: Jouko Orava <jouko.orava@xxxxxxxxxxx> I'd also like to point at the real bug here, in Jouni's original strace: writev(3, [{"\0\0\0\0\0\0\0\0", 8}, {"", 2147483648}], 2) = -2147483640 The syscall returns a negative value, which is not the actual number of bytes written (since it is 32-bit wrapped), and errno has not been changed. There is no way for userspace to handle this result correctly! There is no way anyone sane should just gloss over this saying "programmer fault, you're doing it wrong". This is a real bug, and deserves fixing sooner rather than later. Thanks, Jouko Orava -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
