Skip to content

Missing open flag (O_DIRECT) #48

Description

@mr-hands

Hi guys, I'm in a desperate need for O_DIRECT flag. Could you add it?

Activity

  1. glguy commented on Oct 7, 2015

    @glguy
    Member

    O_DIRECT is specific to Linux and additionally appears to be deprecated in favor of using raw(8).

    If you're in desperate need you can bind to open(2) and pass the flag in yourself using the FFI.

  2. mr-hands commented on Oct 7, 2015

    @mr-hands
    Author

    Err... Exactly the other way around: https://lkml.org/lkml/2007/2/16/431.

  3. glguy commented on Oct 7, 2015

    @glguy
    Member

    Keep searching. They changed their minds after that.

    On Wed, Oct 7, 2015, 1:10 AM mr-hands [email protected] wrote:

    Err... Exactly the other way around: https://lkml.org/lkml/2007/2/16/431.

    —
    Reply to this email directly or view it on GitHub
    #48 (comment).

  4. mr-hands commented on Oct 7, 2015

    @mr-hands
    Author

    Well:

    config RAW_DRIVER
    tristate "RAW driver (/dev/raw/rawN)"
    depends on BLOCK
    help
    The raw driver permits block devices to be bound to /dev/raw/rawN.
    Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
    See the raw(8) manpage for more details.

          Applications should preferably open the device (eg /dev/hda1)
          with the O_DIRECT flag.
    

    This is from the latest master. Could you provide some links that O_DIRECT is deprecated?

  5. glguy commented on Oct 7, 2015

    @glguy
    Member

    I misread the entry in the man page. In any case this is both Linux
    specific and is it's something you need urgently today you will get the
    best results with the ffi. (I'm not the maintainer, so I'm not claiming to
    be ruling on the outcome of this ticket.)

    On Wed, Oct 7, 2015, 7:38 AM mr-hands [email protected] wrote:

    Well:

    config RAW_DRIVER
    tristate "RAW driver (/dev/raw/rawN)"
    depends on BLOCK
    help
    The raw driver permits block devices to be bound to /dev/raw/rawN.
    Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
    See the raw(8) manpage for more details.

      Applications should preferably open the device (eg /dev/hda1)
      with the O_DIRECT flag.
    

    This is from the latest master. Could you provide some links that O_DIRECT
    is deprecated?

    —
    Reply to this email directly or view it on GitHub
    #48 (comment).

  6. argiopetech commented on Oct 7, 2015

    @argiopetech
    Contributor

    My FreeBSD 10.1 system has O_DIRECT in the man page. I've never personally used it on FreeBSD, but I'll assume the man page is accurate.

    This said, this is an ongoing issue (see #6). I echo Gregory Collins' sentiments from that issue: "The old design is dirty, but we're stuck with it for the moment. I'll be happy to accept a pull request adding the new flags. It will require a major version bump."

    I will add that this is yet another flag (see the handling of RTLD_NEXT for another) which requires _GNU_SOURCE on certain Linux platforms (e.g., SuSe). We will not enable the _GNU_SOURCE flag, so any provided fix must be able to work around this issue without changing the general structure of the OpenFileFlags (thereby breaking backward compatibility) or breaking pattern matching in a cross-platform setting (by e.g., changing the data structure with an #ifdef).

    Alternatives include using the FFI (thanks for fielding this one, @glguy), modifying a copy of unix for local use, or using the raw command line utility to work around the issue.

    For the record, I will not get to this in the near future. This, of course, should not rule out pull requests. If and when I do make a change here, it will probably be as a set of major changes which will break backward compatibility and require multiple active versions (similar to the base update of a few years back).

    I'll leave this issue open for the rest of the day for general conversation (if desired). Please direct any further technical discussion pertinent to adding O_DIRECT to #6.

  7. hasufell commented on May 1, 2016

    @hasufell
    Member

    not part of posix, so should not be added, see http://www.unix.com/man-page/posix/3p/open/

  8. hasufell commented on Jul 10, 2022

    @hasufell
    Member

    I guess no one is pushing for this anymore, so let's close as wontfix. If anyone wants to revive the discussion, open a new ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions