| 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: Mon, 29 Nov 2010 16:27:12 +0000 From: Florian Weimer <fweimer@....de> To: Bernd Schubert <bernd.schubert@...tmail.fm> Cc: "Ted Ts'o" <tytso@....edu>, Jonathan Nieder <jrnieder@...il.com>, linux-ext4@...r.kernel.org Subject: Re: Bug#605009: serious performance regression with ext4 * Bernd Schubert: > Wouldn't it make sense to modify ext4 or even the vfs to do that on close() > itself? Most applications expect the file to be on disk after a close anyway > and I also don't see a good reason why one should delay a disk write-back > after close any longer (well, there are exeption if the application is broken, > for example such as ha-logd used by pacemaker, which did for each line of logs > an open, seek, write, flush, close sequence..., but at least we have fixed > that in -hg now). If you use Oracle Berkeley DB in a process-based fashion, it is crucial for decent performance that the memory-mapped file containing the cache is not flushed to disk when the database environment is closed prior to process termination. Perhaps flushing could be delayed until the last open file handle is gone. In any case, it's a pretty drastic change, which should probably be tunable with a (generic) mount option. -- Florian Weimer <fweimer@....de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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