On Thu, Sep 13, 2012 at 04:34:55PM +0200, Jan Kara wrote: > On Thu 13-09-12 20:57:26, Zheng Liu wrote: > > 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? > Hum, on my test machine with 3.6-rc1 it does not... Maybe for your > desktop you need a larger sleep before running truncate so that readers > have time to start up? Also I suppose you have ext4 mounted with > dioread_nolock mount option? Yes, it can be reproduced after increasing sleep time. Thanks. 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
