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? Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
