| 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: <4856BD70.4080000@redhat.com> Date: Mon, 16 Jun 2008 14:22:24 -0500 From: Eric Sandeen <sandeen@...hat.com> To: Jan Kara <jack@...e.cz> CC: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>, cmm@...ibm.com, tytso@....edu, linux-ext4@...r.kernel.org, adilger@....com Subject: Re: [RFC] ext4: Semantics of delalloc,data=ordered Jan Kara wrote: >>> Imagine you have a file with blocks 1 and 3 allocated and block 2 is a >>> hole. You write blocks 1-3. Block 2 isn't allocated because of delalloc. >>> Now if inode is already in the current transaction's list, during commit >>> writes to blocks 1 and 3 will land on disk but write to block 2 will >>> happen only after pdflush finds it. >> And that should be fine with data=ordered mode right ?. Because since >> block 2 is not yet allocated we don't have associated meta-data. So >> even if we crash we have meta-data pointing to 1 and 3 and not 2. The >> problem is only when we write the meta-data pointing to block 2 and not >> block 2 itself ?. > Yes, it is correct. I may be just surprising (we didn't do things like > this in data=ordered mode before). Will it even be surprising? "fill-in-hole; crash;" today may give you the same thing, right? It's just that with delalloc it might be a bigger window in time for this to happen? -Eric -- 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