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: <487B51DD.2080206@hp.com> Date: Mon, 14 Jul 2008 09:17:17 -0400 From: jim owens <jowens@...com> To: Pavel Machek <pavel@...e.cz> CC: linux-fsdevel@...r.kernel.org, Dave Chinner <david@...morbit.com>, Theodore Tso <tytso@....edu>, Arjan van de Ven <arjan@...radead.org>, Miklos Szeredi <miklos@...redi.hu>, hch@...radead.org, t-sato@...jp.nec.com, akpm@...ux-foundation.org, viro@...IV.linux.org.uk, linux-ext4@...r.kernel.org, xfs@....sgi.com, dm-devel@...hat.com, linux-kernel@...r.kernel.org, axboe@...nel.dk, mtk.manpages@...glemail.com Subject: Re: [PATCH 3/3] Add timeout feature Pavel Machek wrote: > If you also freeze data writes, at least snapshot is not worse than > _unexpected_ shutdown. True. But the key point is also that stopping file writes is __no better__ than an unexpected shutdown for applications. Once kernel people accept that it is identical to an unknown shutdown state, they realize that as you said... > And apps should already be ready for unexpected shutdowns (using fsync > etc). The people writing the code outside the kernel are the ones responsible for the logic of handling "we don't know what application writes made it to disk". Remember that immediately after fsync(), the next write can make the file inconsistent. For example, look at this simple sales processing database type sequence: write(sale_last_name_file, "Mackek" write(sale_first_name_file, "Pavel") fsync(sale_last_name_file) fsync(sale_first_name_file) ... write(sale_last_name_file, "Owens") write(sale_first_name_file, "Jim") fsync(sale_last_name_file) FREEZEFS [defined to NOT allow file data writes] So if we restart from that snapshot, the sales order thinks the customer is "Pavel Owens"... unless there is some mechanism such as seqence numbers that tie the files together. And if they have such a mechanism then it doesn't matter if we allow even more writes such as: write(sale_first_name_file, "Ted") There just is no way inside the kernel to know a freeze was triggered at a stable application point such that data before the freeze must be on disk and data after the freez must not go to disk. This issue is not unique to freeze, it is also present with filesystems that have snapshots and cow/versioning built in. jim -- 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