linux-ext4 - ext4, AIO and new files?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <da2267130907081959y1d79e4f1na9d7828141a18f95@mail.gmail.com>
Date:	Wed, 8 Jul 2009 20:59:23 -0600
From:	Jason Gunthorpe <jgunthorpe@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: ext4, AIO and new files?

Hi All.

I saw an many years old thread on this topic and recently ran into the
same problem. I'm wondering if anything has changed since - or someone
had some smart thoughts on this?

In short, if you do:

fd = open("foo",O_DIRECT|O_TRUNC_O|CREAT,0666);
fallocate(fd,0,xxx);
io_submit(.. IO_CMD_PWRITE ..);

io_submit blocks on ext4. (It also blocks on ext3, but fallocate fails
there so that is not entirely surprising..)

On xfs io_submit runs asynchronously with the same sequence. There is
a change in the performance characteristic: -30% with a 32k iosize
compared to re-writing already existing blocks - but it performs well
with larger iosizes

I am working on a network file copy application, so this is the common
(well. only) workload.

I haven't yet got access to the good storage to test on, but I'm
concerned that io_submit blocking means that there is going to be
limited, or no, concurrency at the SCSI level? I understand the
problem is that ext4 needs to note the block is now actually used and
no longer 'zero' but I guess I don't entirely follow why that wrecks
AIO?

Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html