[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120612181958.GB1803@thunk.org>
Date: Tue, 12 Jun 2012 14:19:58 -0400
From: Ted Ts'o <tytso@....edu>
To: Arnd Bergmann <arnd.bergmann@...aro.org>
Cc: 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
Subject: Re: [PATCH 2/3] ext4: Context support
On Tue, Jun 12, 2012 at 02:55:50PM +0000, Arnd Bergmann wrote:
>
> As I said, it's not a technical limitation, but a logical conclusion
> from trying to use the context ID for something useful. The only
> reason to use context ID in the first place is to reduce the amount
> of garbage collection in the device (improving performance and expected
> life of the device), so any context ID annotations we make should be
> directed at giving useful information to the device to actually do that.
... and a big part of that is knowing what is the downside if we give
incorrect information to the device. And what are the exact
implications of what it means to group a set of blocks into a
"context".
If it is fundamentally a promise that blocks in a context will be
overwritten or trimmed at the same time then is it counterproductive
to group blocks for overwrite-in-place database where the lifetimes of
the block are extremely different? Is that giving "wrong" information
going to significantly increase the write amplification factor?
It may be that the standard doesn't actually answer these questions
and even worse, SSD manufactures may be stupidly trying to keep this
stuff as a "trade securet" --- but we do need to know in order to
optimize performance on real hardware....
- 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