| 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
| ||
|
Date: Thu, 5 Aug 2010 12:17:45 -0400 From: Ted Ts'o <tytso@....edu> To: Avi Kivity <avi@...hat.com> Cc: Christoph Hellwig <hch@...radead.org>, Ric Wheeler <rwheeler@...hat.com>, Mingming Cao <cmm@...ibm.com>, djwong@...ibm.com, linux-ext4 <linux-ext4@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org>, Keith Mannthey <kmannth@...ibm.com>, Mingming Cao <mcao@...ibm.com> Subject: Re: [RFC] ext4: Don't send extra barrier during fsync if there are no dirty pages. On Thu, Aug 05, 2010 at 05:20:12AM +0300, Avi Kivity wrote: > > Why not? To be clear, I'm talking about an io_submit() with > multiple IO_CMD_FSYNC requests, with a kernel implementation that is > able to batch these requests. IO_CMD_FSYNC doesn't exist right now, but sure, it means we don't have to add a new syscall. I find the aio interface to be horribly complicated, and it would mean that programs would have to link against libaio, which again isn't my favorite set of interfaces. All of that being said, I do agree that adding a new IO_CMD_FSYNC, IO_CMD_FSYNCDATA, IO_CMD_FSYNC_NOBARRIER, and IOCMD_FSYNC_DATA_NOBARRIER would be the simplist thing to do from a kernel implementation perspective. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists