The following issue was noticed while running some Peer-2-Peer benchmarks on NVMe SSD (EXT4 fs). The first write after file create is very slow. The cause for this is that for the first time the code doesn't take the direct P2P path and instead falls back to software copy. The function get_more_block() sets 'create' to 0 after comparing 'unsigned long fs_startblk = 0' with 'long long (i_size_read(dio->inode) - 1) >> i_blkbits = 0x0xfffffffffffff'. I understand this previous change 'direct-io: fix direct write stale data exposure from concurrent buffered read' was introduced to handle a corner case for sparse file. I am not too familiar with sparse file. Please let me know if this change would break it Harish Kasiviswanathan (1): direct-io: Fix unsigned comparison overflow fs/direct-io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.7.4
