From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Monakhov Subject: Direct aio_write/truncate question Date: Sat, 24 Apr 2010 15:29:36 +0400 Message-ID: <87633hdr6n.fsf@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , jens.axboe@oracle.com To: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Return-path: Received: from mail-bw0-f219.google.com ([209.85.218.219]:54172 "EHLO mail-bw0-f219.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751967Ab0DXL3m (ORCPT ); Sat, 24 Apr 2010 07:29:42 -0400 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: My be my question appeared to obvious for someone, but still fd = open("a", O_DIRECT, ) fd2 = open("b", O_DIRECT, ) write(fd, buf ,size) /* allocate blocks for a file */ fsync(fd) /* Now, it is guaranteed that blocks are allocated.*/ /* Submit async rewrite request */ io_prep_pwrite(io, fd, io->u.c.buf, size, 0); io_submit(myctx, 1, io); /* Io is in flight after this */ /* Ok, truncate the file */ ftruncate(fd, 0) /* Reuse truncated block blocks for a new file */ write(fd2,buf ,size) /* old a's blocks belongs to b now. */ What protect us from aio request to rewrite content of new file? Or even corrupt fs because old blocks may be used as metadata now. Seems unmap_underlying_metadata() can not help us here because async io context does not dirty or locked any bh because they was already allocated. Fairly to say. I can not reproduce rewrite effect. I use ext4 with external journal, so where a io_barriers in fs_dev's blktrace log. Seems what rewrite effect no happens only because blklayer does not reorganized issued requests. But nothing is preventing this right?