On Thu, Sep 13, 2012 at 02:07:36PM +0200, Jan Kara wrote: > Hello, > > On Thu 13-09-12 18:41:36, Zheng Liu wrote: > > Could you please provide more detailed workload to convince me? I > > am thinking about whether we really need to disable dioread_nolock > > feature in here. In our benchmarks, we don't see this problem. > I just did: > > # Create file > dd if=/dev/zero of=/mnt/file bs=1M count=30 > sync > # Start 10 DIO dio readers in parallel reading the file in a loop > for (( i = 0; i < 10; i++ )); do > while true; do > dd if=/mnt/file bs=4k iflag=direct of=/dev/null > done & > done > sleep 1 > > # Try to truncate the file - never finishes. > truncate -s 16 /mnt/file > > It is pretty easy to hit this. Besides being a DOS attack vector (but I > won't be too concerned about this - there are plenty of ways how local > process can screw you) I can easily imagine some application to get bitten > by this. Hi Jan, Thanks for your explanation, but in my desktop I cannot reproduce this problem. The size of `file' is 16. Am I missing something? Regards, Zheng -- 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
