Is UNSTABLE ever sent in client writes?

Is UNSTABLE ever sent in client writes?

[Constantine Peresypkin]

Tried with various mount options (sync, async)
Looked into source code.
It seems like it will never be sent, client always assumes server can
do FILE_SYNC, and server cannot respond with anything else, if
implemented correctly.
But what we can do if the server is inherently unable to do FILE_SYNC
(eventual consistency, write reorder, etc.)?

Re: Is UNSTABLE ever sent in client writes?

[Benjamin Coddington]

On Thu, 1 Oct 2015, Constantine Peresypkin wrote:

> Tried with various mount options (sync, async)
> Looked into source code.
> It seems like it will never be sent, client always assumes server can
> do FILE_SYNC, and server cannot respond with anything else, if
> implemented correctly.
> But what we can do if the server is inherently unable to do FILE_SYNC
> (eventual consistency, write reorder, etc.)?

Hi Constantine, my linux client does unstable writes all the time.
nfs_pgio_rpcsetup() default stable arg is NFS_UNSTABLE..

Try doing a write larger than your mount's wsize parameter.

Ben

Re: Is UNSTABLE ever sent in client writes?

[Constantine Peresypkin]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

The question is: can I force it to always use unstable? Or how can I debug
why FILE_SYNC is always sent in my case?
On Oct 1, 2015 12:32 PM, "Benjamin Coddington" <bcodding@redhat.com> wrote:

> On Thu, 1 Oct 2015, Constantine Peresypkin wrote:
>
> > Tried with various mount options (sync, async)
> > Looked into source code.
> > It seems like it will never be sent, client always assumes server can
> > do FILE_SYNC, and server cannot respond with anything else, if
> > implemented correctly.
> > But what we can do if the server is inherently unable to do FILE_SYNC
> > (eventual consistency, write reorder, etc.)?
>
> Hi Constantine, my linux client does unstable writes all the time.
> nfs_pgio_rpcsetup() default stable arg is NFS_UNSTABLE..
>
> Try doing a write larger than your mount's wsize parameter.
>
> Ben
>

[-- Attachment #2: Type: text/html, Size: 1141 bytes --]

Re: Is UNSTABLE ever sent in client writes?

[Benjamin Coddington]

On Thu, 1 Oct 2015, Constantine Peresypkin wrote:

>
> The question is: can I force it to always use unstable? Or how can I debug why FILE_SYNC is always sent in my case?

No, I don't believe you can.  You can use systemtap, or turn up the nfs
debugging.

I don't think FILE_SYNC will always be sent.  It depends upon how you are
doing IO.  What are you using to test?

Try something like this on a mount with wsize=4096.  It should get you four
unstable writes, and eventually a COMMIT:

#define TPATH "/mnt/fedora/tmp/"
#define SIZE 4096*4
#define CHARS "I love when strings are 32 chars"

int main(void *argc) {
    int pos, filp_foo;
    void *foo_addr;

    unlink(TPATH "foo");
    filp_foo = open(TPATH "foo", O_RDWR|O_CREAT, S_IWUSR|S_IRUSR|S_IRGRP|S_IROTH);
    ftruncate(filp_foo, SIZE);
    foo_addr = mmap(NULL, SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, filp_foo, 0);
    for (pos = 0; pos < SIZE; pos += strlen(CHARS))
        strcpy(foo_addr + pos, CHARS);
    close(filp_foo);
}

Ben


>
> On Oct 1, 2015 12:32 PM, "Benjamin Coddington" <bcodding@redhat.com> wrote:
>       On Thu, 1 Oct 2015, Constantine Peresypkin wrote:
>
>       > Tried with various mount options (sync, async)
>       > Looked into source code.
>       > It seems like it will never be sent, client always assumes server can
>       > do FILE_SYNC, and server cannot respond with anything else, if
>       > implemented correctly.
>       > But what we can do if the server is inherently unable to do FILE_SYNC
>       > (eventual consistency, write reorder, etc.)?
>
>       Hi Constantine, my linux client does unstable writes all the time.
>       nfs_pgio_rpcsetup() default stable arg is NFS_UNSTABLE..
>
>       Try doing a write larger than your mount's wsize parameter.
>
>       Ben
>
>
>

Re: Is UNSTABLE ever sent in client writes?

[Constantine Peresypkin]

Doesn't help much.
As far as I can see from the code, there are only two places where
write_pageio_init() is called, and it's called either with
FLUSH_STABLE or FLUSH_COND_STABLE
Therefore I have no idea how exactly any unstable write will be submitted.

On Thu, Oct 1, 2015 at 12:55 PM, Benjamin Coddington
<bcodding@redhat.com> wrote:
> On Thu, 1 Oct 2015, Constantine Peresypkin wrote:
>
>>
>> The question is: can I force it to always use unstable? Or how can I debug why FILE_SYNC is always sent in my case?
>
> No, I don't believe you can.  You can use systemtap, or turn up the nfs
> debugging.
>
> I don't think FILE_SYNC will always be sent.  It depends upon how you are
> doing IO.  What are you using to test?
>
> Try something like this on a mount with wsize=4096.  It should get you four
> unstable writes, and eventually a COMMIT:
>
> #define TPATH "/mnt/fedora/tmp/"
> #define SIZE 4096*4
> #define CHARS "I love when strings are 32 chars"
>
> int main(void *argc) {
>     int pos, filp_foo;
>     void *foo_addr;
>
>     unlink(TPATH "foo");
>     filp_foo = open(TPATH "foo", O_RDWR|O_CREAT, S_IWUSR|S_IRUSR|S_IRGRP|S_IROTH);
>     ftruncate(filp_foo, SIZE);
>     foo_addr = mmap(NULL, SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, filp_foo, 0);
>     for (pos = 0; pos < SIZE; pos += strlen(CHARS))
>         strcpy(foo_addr + pos, CHARS);
>     close(filp_foo);
> }
>
> Ben
>
>
>>
>> On Oct 1, 2015 12:32 PM, "Benjamin Coddington" <bcodding@redhat.com> wrote:
>>       On Thu, 1 Oct 2015, Constantine Peresypkin wrote:
>>
>>       > Tried with various mount options (sync, async)
>>       > Looked into source code.
>>       > It seems like it will never be sent, client always assumes server can
>>       > do FILE_SYNC, and server cannot respond with anything else, if
>>       > implemented correctly.
>>       > But what we can do if the server is inherently unable to do FILE_SYNC
>>       > (eventual consistency, write reorder, etc.)?
>>
>>       Hi Constantine, my linux client does unstable writes all the time.
>>       nfs_pgio_rpcsetup() default stable arg is NFS_UNSTABLE..
>>
>>       Try doing a write larger than your mount's wsize parameter.
>>
>>       Ben
>>
>>
>>