lkml.org 
[lkml]   [2012]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [sqlite] light weight write barriers

Nico Williams, on 11/13/2012 02:13 PM wrote:
> declaring groups of internally-unordered writes where the groups are
> ordered with respect to each other... is practically the same as
> barriers.

Which barriers? Barriers meaning cache flush or barriers meaning commands order,
or barriers meaning both?

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.

Are you going to invent 3 types of barriers?

> There's a lot to be said for simplicity... as long as the system is
> not so simple as to not work at all.
>
> My p.o.v. is that a filesystem write barrier is effectively the same
> as fsync() with the ability to return sooner (before writes hit stable
> storage) when the filesystem and hardware support on-disk layouts and
> primitives which can be used to order writes preceding and succeeding
> the barrier.

Your mistake is that you are considering barriers as something real, which can do
something real for you, while it is just a artificial abstraction apparently
invented by people with limited knowledge how storage works, hence having very
foggy vision how barriers supposed to be processed by it. A simple wrong answer.

Generally, you can invent any abstraction convenient for you, but farther your
abstractions from reality of your hardware => less you will get from it with
bigger effort.

There are no barriers in Linux and not going to be. Accept it. And start instead
thinking about offload capabilities your storage can offer to you.

Vlad



\
 
 \ /
  Last update: 2012-11-15 03:01    [W:0.110 / U:1.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site