xfs
[Top] [All Lists]

Re: streaming media and realtime subvolume

To: Eric Sandeen <sandeen@xxxxxxx>
Subject: Re: streaming media and realtime subvolume
From: George Georgalis <georgw@xxxxxxxxx>
Date: Thu, 7 Nov 2002 14:16:05 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <1036695208.13877.21.camel@xxxxxxxxxxxxxxxxxxxxxx>
References: <20021107151729.GA7085@trot> <1036683254.13907.4.camel@xxxxxxxxxxxxxxxxxxxxxx> <20021107173730.GB8321@trot> <1036690729.13877.14.camel@xxxxxxxxxxxxxxxxxxxxxx> <20021107182517.GD8321@trot> <1036695208.13877.21.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.28i
On Thu, Nov 07, 2002 at 12:53:28PM -0600, Eric Sandeen wrote:
>On Thu, 2002-11-07 at 12:25, George Georgalis wrote:
>> On Thu, Nov 07, 2002 at 11:38:49AM -0600, Eric Sandeen wrote:
>> >On Thu, 2002-11-07 at 11:37, George Georgalis wrote:
>> >> Can you give examples of 'direct i/o'? do you mean like dd? from which I
>> >> can pipe stdout to my media player?
>> >
>> >No, like O_DIRECT, as in:
>> >
>> >fd = open("tempfile_direct", O_CREAT|O_RDWR|O_DIRECT, 0666);
>> >
>> >It bypasses the buffer cache.
>> 
>> Well, that sounds good. :) <trying to be gracious> can't we just mount a
>> partition that way </>, I'm guessing no.
>
>Nope, if nothing else, because the I/O has other requirements on it as
>well (alignment & size) so you can't just say "I'd like to do O_DIRECT
>please" and have everything happen magically.
>
>> Humm, I see your syntax as a little different then my GNU/Linux OPEN(2)
>> man page, is that because my man page is not patched with the xfs kernel
>> or should I be using the other flags?
>
>Not sure what you mean...
>
>>        int open(const char *pathname, int flags, mode_t mode);
>
>That's the open() I show above.

I didn't include the important part of the man page, sorry. This follows:

    The parameter flags is one of O_RDONLY, O_WRONLY or O_RDWR which
    request opening the file read-only, write-only or read/write,
    respectively, bitwise-or'd with zero or more of the following:

and 'the following' includes paragraphs on O_CREAT, O_EXCL, O_NOCTTY,
O_TRUNC, O_APPEND, O_NONBLOCK or O_NDELAY, O_SYNC, O_NOFOLLOW,
O_DIRECTORY and O_LARGEFILE -- but no 'O_DIRECT'

maybe O_DIRECT is

    O_NONBLOCK or O_NDELAY
           When possible, the file is opened in non-blocking mode.
           Neither the open nor any subsequent operations on the file
           descriptor which is returned will cause the calling process
           to wait. For the handling of FIFOs (named pipes), see also
           fifo(4). This mode need not have any effect on files other
           than FIFOs.

here? but that doesn't sound quite right...

I have the feeling the effort of a realtime subvolume, and custom C I/O
programs might be overdoing it for this application, but I appreciate
the info.

// George


-- 
GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229 
Security Services, Web, Mail,            mailto:george@xxxxxxxxx 
File, Print, DB and DNS Servers.       http://www.galis.org/george 


<Prev in Thread] Current Thread [Next in Thread>