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: <20090318131215.GA11965@atrey.karlin.mff.cuni.cz> Date: Wed, 18 Mar 2009 14:12:15 +0100 From: Jan Kara <jack@...e.cz> To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com> Cc: Theodore Ts'o <tytso@....edu>, Ext4 Developers List <linux-ext4@...r.kernel.org> Subject: Re: [PATCH] ext4: Add support for data=alloc_on_commit mode > On Mon, Mar 16, 2009 at 11:19:58PM -0400, Theodore Ts'o wrote: > > Add an ext3 bug-for-bug compatible analogue for data=ordered mode. In > > this mode, we force all delayed allocation blocks involved with the > > to-be-commited transaction to be allocated, and then flushed out to > > disk before the transaction is commited. > > > > Wouldn't this cause a deadlock ? We want to commit a transaction because > we don't have enough journal space (via journal_start) and now that would cause block > allocation which would do another journal_start() Yes, that's exactly what I think. We cannot start a transaction while committing another transaction. Also you must put the block allocation into the transaction you're going to commit because of data consistency guarantees. So if you want to do "alloc on commit" you have to reserve enough credits to the running transaction at the "block reservation" time and then use them for allocation at commit time. But this gets complex because the number of needed credits is hard to estimate (we don't know how many bitmaps / group descriptors we're going to modify). I'm not yet sure how to solve this problem... Honza -- Jan Kara <jack@...e.cz> SuSE CR Labs -- 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