linux-ext4 - Re: Updated ext4/jbd2 patches based on 2.6.19-rc1

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: <20061006064856.GK22010@schatzie.adilger.int>
Date:	Fri, 6 Oct 2006 00:48:56 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Dave Kleikamp <shaggy@...tin.ibm.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Updated ext4/jbd2 patches based on 2.6.19-rc1

On Oct 05, 2006  23:10 -0700, Andrew Morton wrote:
> On Thu, 5 Oct 2006 23:58:29 -0600
> Andreas Dilger <adilger@...sterfs.com> wrote:
> > but the patches have not been changed for ext4 (which should really
> > default to using extents on a filesystem with the INCOMPAT_EXTENT feature
> > set unless told otherwise).  That is a necessity for filesystems larger
> > than 2^32 blocks, since there is no way to create old block-mapped files
> > past that limit.
> 
> That's news to me.  So we only use 48-bit block numbers for extents and
> not for old-style indirect blocks?

Correct.  The block-mapped {d,t,}indirect blocks chewed up enough space
as it was (0.1% of the file size) without doubling the block pointers.
Things like truncate hurt pretty badly because of that, as does the
increased IO load to read them and memory pressure due to keeping them
in RAM.

> How much performance improvement do they get, btw?  CPU or IO? I'm not
> noticing any difference.

As mentioned in my other email, the big performance win will come from
the multi-block allocation (mballoc) and delayed allocation (delalloc)
from Alex.

The mballoc patch allows a 1MB write to get a 1MB-aligned and contiguous
chunk of disk, instead of the next 256 blocks that might be free.
Having 1MB alignment is good for 10% or more on some RAID systems to
avoid writing partial stripes (which also requires a read).

Delalloc allows the filesystem to actually submit 1MB writes at once
without doing the block allocation in prepare_write().  Better for
picking free space, and avoids needless extent tree insertion/rebalancing.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, 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