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:	Mon, 18 Jun 2012 13:42:14 -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 05:41:23PM +0000, Arnd Bergmann wrote:
> 
> * We cannot read from write-only large-unit context, so we have to
>   do one of these:
>    a) ensure we never drop any pages from page-cache between writing
>       them to the large context and closing that context
>    b) if we need to read some data that we have just written to the
>       large-unit context, close that context and open a new rw-context
>       without the large-unit flag set (or write in the default context)

If we ever a read on the inode in question, we close the large-unit
context.  That's the simplest thing to do, since we then don't need to
track which blocks had been written from the inode.  And in general,
if you have a random read/write workload, large-unit contexts probably
won't help you.  We mainly would need this when the workload is doing
large sequential writes, which is *easy* to optimize for.

> * All writes to the large-unit context have to be done in superpage
>   size, which means something between 8 and 32 kb typically, so more
>   than the underlying fs block size

Right, so we only enable the large-unit context when we are in
ext4_da_writepages() and we can do the first write in a way that meets
the requirements (i.e., the write starts aligned on the erase block,
and is a multiple of the superpage size).  The moment we need to do a
read (see above) or a write which doesn't meet the large-unit
restrictions, we close the large-unit context.

(This is why I asked the question about whether there are performance
penalties for opening and closing contexts.  If it requires flushing
the NCQ queues, ala the trim request, then we might need to be more
careful.)

> * We can only start the large unit at the start of an erase block. If
>   we unmount the drive and later continue writing, it has to continue
>   without the large-unit flag at first until we hit an erase block
>   boundary.

My assumption was that when you umount the drive, the file system
would close all of the contexts.

> * If we run out of contexts in the block device, we might have to
>   close a large-unit context before getting to the end of it.

Yep.

> My impression was always that the high-end storage folks try to make
> everything behave nicely whatever the access patterns are, and they
> can do it because an SSD controllers has vast amounts of cache (megabytes,
> not kilobytes) and processing power (e.g. 1Ghz ARMv5 instead of 50 Mhz
> 8051) to handle it, and they also make use of tagged command queuing to
> let the device have multiple outstanding requests.

Well, the high-end stoarge folks still would need to know if a set of
blocks being written are related.  The large-unit contexts might not
matter as much, but knowing that a set of writes *are* related is
something that would help them.

					- 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

Powered by blists - more mailing lists