linux-ext4 - Re: [RFC] ext4: Semantics of delalloc,data=ordered

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080616194549.GG31567@duck.suse.cz>
Date:	Mon, 16 Jun 2008 21:45:49 +0200
From:	Jan Kara <jack@...e.cz>
To:	Eric Sandeen <sandeen@...hat.com>
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

On Mon 16-06-08 14:22:24, Eric Sandeen wrote:
> 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?
  Thinking more about it, yes, it could happen even with current ordered
mode. If the crash happens between writeback of data buffers and commit of
transaction, block in the middle would remain to be a hole.
  OK, so we just make the window larger. You are starting to convince me
that 1) is really the better choice ;).

									Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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