linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Constantine Peresypkin <pconstantine@gmail.com>
To: Benjamin Coddington <bcodding@redhat.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Is UNSTABLE ever sent in client writes?
Date: Thu, 1 Oct 2015 14:12:30 -0500	[thread overview]
Message-ID: <CAOEg9LoHqwKdn7NfHWRh_asAkL9f_22X1udwHRn0+xPX_eKhng@mail.gmail.com> (raw)
In-Reply-To: <alpine.OSX.2.19.9992.1510011338400.5275@planck.local>

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
>>
>>
>>

      reply	other threads:[~2015-10-01 19:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01 16:55 Is UNSTABLE ever sent in client writes? Constantine Peresypkin
2015-10-01 17:32 ` Benjamin Coddington
2015-10-01 17:37   ` Constantine Peresypkin
2015-10-01 17:55     ` Benjamin Coddington
2015-10-01 19:12       ` Constantine Peresypkin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOEg9LoHqwKdn7NfHWRh_asAkL9f_22X1udwHRn0+xPX_eKhng@mail.gmail.com \
    --to=pconstantine@gmail.com \
    --cc=bcodding@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).