qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [v9 Patch 6/6]Qemu: raw posix implementation of reopen


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [v9 Patch 6/6]Qemu: raw posix implementation of reopen functions
Date: Tue, 22 Nov 2011 11:54:23 +0000

On Tue, Nov 22, 2011 at 11:30 AM, supriya kannery <address@hidden> wrote:
> Stefan Hajnoczi wrote:
>>
>> On Tue, Nov 22, 2011 at 9:45 AM, supriya kannery <address@hidden>
>> wrote:
>>
>>>
>>> supriya kannery wrote:
>>>
>>>>
>>>> Stefan Hajnoczi wrote:
>>>>
>>>>>
>>>>> On Fri, Nov 11, 2011 at 6:48 AM, Supriya Kannery
>>>>> <address@hidden> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> +        }
>>>>>> +        if ((flags & BDRV_O_NOCACHE)) {
>>>>>> +            raw_rs->reopen_state.reopen_flags |= O_DIRECT;
>>>>>> +        } else {
>>>>>> +            raw_rs->reopen_state.reopen_flags &= ~O_DIRECT;
>>>>>> +        }
>>>>>> +        ret = fcntl_setfl(raw_rs->reopen_fd,
>>>>>> raw_rs->reopen_state.reopen_flags);
>>>>>>
>>>>>>
>>>>>
>>>>> I wonder if this works on Solaris, FreeBSD, etc?
>>>>>
>>>>> Perhaps there needs to be a fallback to the missing "else" case
>>>>> below...
>>>>>
>>>>>
>>>>>
>>>>
>>>> ok. Will look into whether this will work on Solaris, FreeBSD etc..
>>>>
>>>>
>>>
>>> This should work for all non-win Oses.
>>> I have tested only in x86.
>>>
>>> #ifndef _WIN32
>>> /* Sets a specific flag */
>>> int fcntl_setfl(int fd, int flag)
>>> {
>>>  int flags;
>>>
>>>  flags = fcntl(fd, F_GETFL);
>>>
>>
>> Are you sure POSIX guarantees that O_DIRECT can be changed with
>> F_SETFL?  I didn't find any statement in the specification.  It is
>> possible that this code compiles but does not actually work on
>> non-Linux OSes.  Did you run tests?
>>
>
> I don't have FreeBSD and Solaris systems to use.
> Referred the following man page links to verify that O_DIRECT in these
> OSes can be changed using fcntl.
> http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?fcntl+2
> http://man-wiki.net/index.php/2:fcntl
> If anybody with these systems can confirm, that would be very helpful.

Cool, thanks for sharing.  The safest would be to do a F_GETFL
afterwards and fall back to unsafe reopen if it didn't work.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]