Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replace O_DIRECT by fadvise() #62

Open
nraynaud opened this issue Aug 15, 2018 · 3 comments
Open

replace O_DIRECT by fadvise() #62

nraynaud opened this issue Aug 15, 2018 · 3 comments

Comments

@nraynaud
Copy link

Hi all,
I am working on ZFS SR support, and I am constantly butting on O_DIRECT which is not supported by ZFS (the symptom is EINVAL on open()).

This time, it's XAPI calling vhd-tool with --direct hard-coded

And through vhd-tool it comes here. I suspect the intent of --direct is to avoid filling the disk cache in this instance. Both operations are simple in-order complete read and in-order complete write.

I think those cases could be covered by posix_fadvise() and fsync().

I am ready to create a patch, but I would like to know where you think I should make the change before I get to work.

Thanks,
Nicolas.

@lindig
Copy link
Collaborator

lindig commented Aug 16, 2018

I am not familiar with file I/O enough to understand why O_DIRECT is desirable in the first place. But I want to caution that we need to be careful to discover when certain options are available only on some file systems. We had a problem of trying to use SEEK_DATA in lseek(2) which is not supported on all file system.

@djs55
Copy link
Member

djs55 commented Aug 16, 2018

IIRC the original rationale for O_DIRECT was to avoid filling up the disk cache as you suggest. The thinking was that the data being streamed wouldn't be read more than once, so there was no point evicting other cache entries just to cache it.

@nraynaud
Copy link
Author

Thanks for your input, after googling a bit, I understand why you dropped the ball on posix and used O_DIRECT, there is basically no reasonable solution to the problem in linux.

I think I will make my changes in vhd-tool, only on the streaming operations, and evict the cache with POSIX_FADV_DONTNEED.
My thinking is that when writing a vhd file from the network nobody had a pre-existing need for a cache on a file that was not yet there, it's mostly for importing new VMs. For the read operation they are mostly sequential and nobody really need a random cache either, they are mostly exporting snapshots to the network.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants