On Fri, Nov 01, 2013 at 09:12:37PM +0800, Zheng Liu wrote: > > Hmm.... it works for me. Run while r_64bit_big_expand is running: > > > > % ls -l tmp > > ... > > 24896 -rw-r--r--. 1 tytso tytso 2199023255552 Oct 31 23:17 e2fsprogs-tmp.pkOcCc > > ... > > $ ls -l /tmp > -rw-rw-r-- 1 wenqing wenqing 536870912 Nov 1 21:03 e2fsprogs-tmp.x8yzKP Well, I got this by running "./test_script r_64bit_big_expand" and then typing ^Z to stop the test mid-stream, and then looking in /tmp. But a simpler thing to do is to simply run the following commands: truncate -s 2T /tmp/foo.img mke2fs -t ext4 -F /tmp/foo.img ... and see if it works correctly. I'm wondering if the problem is that a file limit was set, although that would result in a core dump: % bash % ulimit -f 131072 % truncate -s 2T /tmp/foo.img File size limit exceeded (core dumped) % exit .... so that doesn't seem to be it. Anyway, the problem seems to be that trying to create a sparse 2T file during the test is what's causing the problem that you and Andreas are seeing. If this theory is question, the next question is what's causing the failure to write files whose i_size is greater than 2T. - Ted -- 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
