linux-ext4 - Re: [PATCH, RFC] jbd2: Add commit time into the commit block

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] [thread-next>] [day] [month] [year] [list]

Message-id: <20080316151617.GA3542@webber.adilger.int>
Date:	Sun, 16 Mar 2008 23:16:17 +0800
From:	Andreas Dilger <adilger@....com>
To:	Theodore Tso <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH, RFC] jbd2: Add commit time into the commit block

On Mar 15, 2008  23:10 -0400, Theodore Ts'o wrote:
> On Sun, Mar 16, 2008 at 09:26:02AM +0800, Andreas Dilger wrote:
> > Note that we'd still be a lot further ahead undelete- and performance-wise
> > if we avoided overwriting the indirect blocks in the first place...  As
> > it is, this is only really useful if you pull the plug after the delete.
> > No harm in doing it, but won't help you recover as much as you could.
> 
> Yeah, I looked at that at one point, but I never had time to try to
> code it up.  The concept would is that we only need to zero out the
> block pointers if we end up dirtying enough bitmap blocks that we've
> run out of space in the journal and so we need to close the
> transaction.  Of course, the problem is that we need to either (a)
> figure out in advance exactly how many bitmap blocks we need to dirty
> (which means we have to read all the indirect blocks twice to figure
> it out for ext3; this is easier for ext4) so we know whether it will
> fit in one transaction,

While it's true it is a two-pass algorithm, I think it can actually
improve overall performance.  One major win is that we don't have
to write out indirect blocks, saving about 32/33 (IIRC) of the IO
needed for the current truncate.  The second win is that we can do
async prefetching of all the (d)indirect blocks from the {dt}indirect
blocks in forward order instead of the current block-at-a-time reads.
Finally, on the second pass the blocks will normally be in RAM already
so not nearly so slow.

> (b) if we try to do it in a single pass, we
> need to allow enough safety margin so that when we *do* decide we
> can't make it fit, we still do have enough space in the journal to
> zero out the blocks in the indirect blocks and in the inode.

We'd still have to truncate from the end in this case...

> I guess the third alternative, (c), is that we don't update *any* of
> the superblock or block group descriptors until the very end of the
> transaction, and don't update any of the blocks.  So we just update
> the bitmap blocks first, and then in a second pass update all of the
> blockgroup descriptors and superblock.  This would require assuring
> that the update of all of the block group descriptors, superblock, and
> removing the inode from the orphan linked list, can all fit in a
> single transaction. If not, this scheme wouldn't work at all.

I'm not sure I understand this.  Wouldn't this possibly lead to those
blocks being re-allocated after a crash?

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
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