On Fri, Apr 01, 2011 at 02:34:26PM -0700, Mingming Cao wrote:
> > > I was thinking along the line to provide finer granularity lock to allow
> > > concurrent direct IO to different offset/range, but to same offset, they
> > > have to be serialized. If it's undefined behavior, i.e. overlapping is
> > > allowed, then concurrent dio implementation is much easier. But not sure
> > > if any apps currently using DIO aware of the ordering has to be done at
> > > the application level.
> >
> > Oh dear God no. One of the major DIO use cases is to tell the
> > kernel, "I know I won't do that, so don't spend any effort protecting
> > me."
> >
> > Joel
> >
>
> Looks like so -
>
> So I think we could have a mode to turn on/off concurrent dio if the non
> heavy duty applications relies on filesystem to take care of the
> serialization.

I would prefer to leave this complexity out. If you must have
it, unsafe, concurrent DIO must be the default. Let the people who
really want it turn on serialized DIO.

Joel

--

"Get right to the heart of matters.
It's the heart that matters more."

http://www.jlbec.org/
jlbec@evilplan.org

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Fri, Apr 1, 2011 at 2:46 PM, Joel Becker <jlbec@evilplan.org> wrote:
> On Fri, Apr 01, 2011 at 09:30:04AM -0700, Amir Goldstein wrote:
>> when writing DIO to indirect mapped file holes, we fall back to buffered write
>> (so we won't expose stale data in the case of a crash) concurrent DIO reads
>> to that file (before data writeback) can expose stale data. right?
>> do you consider this case mixing buffered and DIO access?
>> do you consider that as a problem?
>
> * * * *I do not consider this 'mixing', nor do I consider it a problem.
> ocfs2 does exactly this for holes, unwritten extents, and CoW. *It does
> not violate the user's expectation that the data will be on disk when
> the write(2) returns.
> * * * *Falling back to buffered on read(2) is a different story; the
> caller wants the current state of the disk block, not five minutes ago.
> So we can't do that. *But we also don't need to.

the issue is with DIO read exposing uninitialized data on disk
is a security issue.
it's not about giving the read what is expects to see.

> * * * *O_DIRECT users that are worried about any possible space usage in
> the page cache have already pre-allocated their disk blocks and don't
> get here.
>
> Joel
>
> --
>
> "Under capitalism, man exploits man. *Under Communism, it's just
> * the opposite."
> * * * * * * * * * * * * * * * * - John Kenneth Galbraith
>
> * * * * * * * * * * * *http://www.jlbec.org/
> * * * * * * * * * * * *jlbec@evilplan.org
>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel