| 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: <20081231070802.GE10725@disturbed> Date: Wed, 31 Dec 2008 18:08:02 +1100 From: Dave Chinner <david@...morbit.com> To: "Peter W. Morreale" <pmorreale@...ell.com> Cc: Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/2] pdflush fix and enhancement On Tue, Dec 30, 2008 at 09:11:04PM -0700, Peter W. Morreale wrote: > Actually, it seems to me that we need to look at a radically different > approach. What about making background writes a property of the super > block? (which implies the file system) Has that been discussed before? Sure - there was a recent discussion in the context of how broken the sync(2) syscall is. That is, some filesystems (e.g. XFS) have certain requirements to ensure sync actually works in all circumstances and the current methods that sync employs make it impossible to sync correctly. It's made worse by the fact that XFS already has internal methods to completely and cleanly sync the filesystem (i.e. the freeze code) but that can't be called in the sync() context because writeback is a property of the VFS and not the filesystem. It was discussed on linux-fsdevel. <rummage> http://marc.info/?l=linux-fsdevel&m=122535673232638&w=2 I simply haven't had time to dig into this far enough to come up with a patchset to fix the problem.... Cheers, Dave. -- Dave Chinner david@...morbit.com -- 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