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:	Sat, 16 Jun 2012 09:49:23 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Arnd Bergmann <arnd.bergmann@...aro.org>
Cc:	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 Sat, Jun 16, 2012 at 07:26:07AM +0000, Arnd Bergmann wrote:
> > Oh, that's cool.  And I don't think that's hard to do.  We could just
> > keep a flag in the in-core inode indicating whether it is in "large
> > unit" mode.  If it is in large unit mode, we can make the fs writeback
> > function make sure that we adhere to the restrictions of the large
> > unit mode, and if at any point we need to do something that might
> > violate the constraints, the file system would simply close the
> > context.
> 
> Really? I actually had expected this to be a major issue, to the
> point that I thought we would only ever do large contexts in
> special emmc-optimized file sytems.

Yeah, it's easy, for file systems (like ext4) which have delayed
allocation.  It's always faster to write in large contiguous chunks,
so we do a lot of work to make sure we can make that happen.  Take a
look of a blktrace of ext4 when writing large set of files; most of
the I/O will be in contiguous, large chunks.  So it's just a matter of
telling the block device layer when we are about to do that large
write.  We could probably do some tuning to make the chunks be larger
and adjust some parameters in the block allocation, but that's easy.

One thing which is going to be tricky is that ext4 currently uses a
buddy allocator, so it will work well for erase blocks of two.  You
mentioned some devices might have erase block sizes of 3*2**N, so that
might require reworking the block allocator some, if we need to align
writes on erase block boundaries.

> > Well, I'm interested in getting something upstream, which is useful
> > not just for the consumer-grade eMMC devices in handsets, but which
> > might also be extensible to SSD's, and all the way up to PCIe-attached
> > flash devices that might be used in large data centers.
> > 
> 
> I am not aware of any actual SSD technology that would take advantage
> of it, but at least the upcoming UFS standard that is supposed to
> replace eMMC should do it, and it's somewhere inbetween an eMMC and
> an SSD in many ways.

I'm not aware that anything has been announced, but this is one of
those things which the high end folks have *got* to be thinking about.
The issues involved aren't only just for eMMC, you know...   :-)

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