David Lang, on 11/15/2012 07:07 AM wrote:
There's no such thing as "barrier". It is fully artificial abstraction. After
all, at the bottom of your stack, you will have to translate it either to cache
flush, or commands order enforcement, or both.
When people talk about barriers, they are talking about order enforcement.
Not correct. When people are talking about barriers, they are meaning different
things. For instance, Alan Cox few e-mails ago was meaning cache flush.
That's the problem with the barriers concept: barriers are ambiguous. There's no
barrier which can fit all requirements.
the hardware capabilities are not directly accessable from userspace (and they
probably shouldn't be)
The discussion is not about to directly provide storage hardware capabilities to
the user space. The discussion is to replace fully inadequate barriers
abstractions to a set of other, adequate abstractions.
For instance:
1. Cache flush primitives:
1.1. FUA
1.2. Non-immediate cache flush, i.e. don't return until all data hit non-volatile
media
1.3. Immediate cache flush, i.e. return ASAP after the cache sync started,
possibly before all data hit non-volatile media.
2. ORDERED attribute for requests. It provides the following behavior rules:
A. All requests without this attribute can be executed in parallel and be freely
reordered.
B. No ORDERED command can be completed before any previous not-ORDERED or ORDERED
command completed.
Those abstractions can naturally fit all storage capabilities. For instance:
- On simple WT cache hardware not supporting ordering commands, (1) translates
to NOP and (2) to queue draining.
- On full features HW, both (1) and (2) translates to the appropriate storage
capabilities.
On FTL storage (B) can be further optimized by doing data transfers for ORDERED
commands in parallel, but commit them in the requested order.
barriers keep getting mentioned because they are a easy concept to understand.
Well, concept of flat Earth and Sun rotating around it is also easy to understand.
So, why isn't it used?
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
