On 04/24/2010 02:30 PM, Greg Freemyer wrote:
On Sat, Apr 24, 2010 at 1:04 PM, Ric Wheeler<rwheeler@xxxxxxxxxx> wrote:
<snip>
Let's summarize.
1. Everyone agrees that doing larger discard instead of little discards is a
good thing.
2. Some devices care about this more than others (various types of SSD's and
arrays have different designs and performance with discards). Some devices
do small discards well, others don't.
3. How you get to those bigger discards in our implementation - using a
series of single range requests, using vectored requests, tracking extents
that can be combined in an rbtree or not - is something that we are working
on. Using rbtrees versus a bitmap efficiency is about DRAM consumption, not
performance of the resulting discard on the target.
4. Devices (some devices) can export their preferences in a standard way
(look in /sys/block/....).
If you want to influence the code, please do try the various options on
devices you have at hand and report results. That is what we are doing (we
includes Lukas, Eric, Jeff and others on this thread) will real devices from
vendors that have given us access. We are talking to them directly and
trying out different work loads but certainly welcome real world results and
suggestions.
Thanks!
Ric
Ric,
Is it also agreed by all that the current ext4 kernel implementation
of calling discard is a poor solution for most hardware / block layers
stacks / workloads and therefore is not worth retaining nor performing
further benchmarks?
I've not seen anyone arguing to keep the current kernel implementation
and I for one accept the previously posted benchmarks that show it is
not adding any value relative to the traditional non-discard case.
Therefore benchmarks between the current hdparm/wiper.sh userspace
implementation and a proposed new kernel implementation would be the
most beneficial?
I have yet to see any of those benchmarks posted.
Greg
Greg,
I don't like the user space wiper.sh approach in general, but running
wiper.sh is entirely your choice.
Most users prefer having the file system and the IO stack take care of
this for them, but again, entirely configurable.
The benchmarks we have done are often done on hardware that is under NDA
so we cannot publish results across the board.
Feel free to run on hardware that you buy and share the results.
Thanks!
Ric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
