| 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
| ||
|
Message-ID: <87bprka9sg.fsf@newton.gmurray.org.uk> Date: Sun, 29 Mar 2009 11:43:59 +0100 From: Graham Murray <graham@...rray.org.uk> To: linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Zero length files - an alternative approach? Just a thought on the ongoing discussion of dataloss with ext4 vs ext3. Taking the common scenario: Read oldfile create newfile file write newfile data close newfile rename newfile to oldfile When using this scenario, the application writer wants to ensure that either the old or new content are present. With delayed allocation, this can lead to zero length files. Most of the suggestions on how to address this have involved syncing the data either before the rename or making the rename sync the data. What about, instead of 'bringing forward' the allocation and flushing of the data, would it be possible to instead delay the rename until after the blocks for newfile have been allocated and the data buffers flushed? This would keep the performance benefits of delayed allocation etc and also satisfy the applications developers' apparent dislike of using fsync(). It would give better performance that syncing the data at rename time (either using fsync() or automatically) and satisfy the requirements that either the old or new content is present. I am not a filesystem developer, so do not know how feasible this would be. -- 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
Powered by blists - more mailing lists