linux-ext4 - Re: [PATCH 2/3] ext4: Context support

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]

Date:	Fri, 15 Jun 2012 09:25:40 +0000
From:	Arnd Bergmann <arnd.bergmann@...aro.org>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	"Ted Ts'o" <tytso@....edu>,
	Alex Lemberg <Alex.Lemberg@...disk.com>,
	HYOJIN JEONG <syr.jeong@...sung.com>,
	Saugata Das <saugata.das@...aro.org>,
	Artem Bityutskiy <dedekind1@...il.com>,
	Saugata Das <saugata.das@...ricsson.com>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mmc@...r.kernel.org, patches@...aro.org, venkat@...aro.org,
	"Luca Porzio (lporzio)" <lporzio@...ron.com>
Subject: Re: [PATCH 2/3] ext4: Context support

On Friday 15 June 2012, Andreas Dilger wrote:
> On 2012-06-14, at 3:55 PM, Arnd Bergmann wrote:
> > My feeling is that we would actually benefit much more from the
> > erase block alignment than from the context for the large files.
> > 
> > I think this is something we can do in the Linaro storage team.
> > We actually have plans to also put the erase block size in the swap
> > header, so we should be able to use the same code in mke2fs and mkswap,
> > and potentially others. What we discussed in the storage team meeting
> > today is that we start out by making ext4 aware of the erase block
> > size through the superblock and aligning extents for large files to
> > erase block boundaries.
> 
> Note that there are already the s_raid_stride and s_raid_stripe_width,
> used by the ext4 allocator to align the start and size of allocations
> on RAID systems.  The erase block size would be like s_raid_stride
> (the minimum amount of data to allocate and write contiguously).
> 
> I don't know that there is a benefit to having a separate erase block
> size, since in the end it means the same as s_raid_stride to the
> allocator - make sure allocations/writes are aligned and sized on
> multiples of this.

Good point. For flash drives, the specific optimizations we do might
be different from what we do on RAID, but they have enough in common
that we could use the same mechanism to detect them.

Is ext4 able to cope well with stride sizes between 512KB and 24MB?

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