Re: stable page writes: wait_on_page_writeback and packet signing

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

 



On Wed, Mar 9, 2011 at 7:30 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> On Wed, 9 Mar 2011 18:33:20 -0600
> Steve French <smfrench@xxxxxxxxx> wrote:
>
>> On Wed, Mar 9, 2011 at 5:54 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>> > On Wed, 9 Mar 2011 16:01:30 -0600
>> > Steve French <smfrench@xxxxxxxxx> wrote:
>> >
>> >>
>> >> Except we don't need to wait that long with the page locked
>> >> ie for a response from the cifs server (such as Samba or Windows
>> >> or NetApp), just need to wait for it to get on the wire.
>> >> Waiting for us to get the server response would
>> >> take 10 or 100 times longer.   In any case we can't resend
>> >> the same request to the server (the signature changes on the
>> >> resend since the sequence number is incremented on every
>> >> request/response so we have to recalc the checksum anyway) and
>> >> cifs requests can't get lost (as with nfs over udp).  Keeping
>> >> a page locked for 10milliseconds seems like a bad idea - but
>> >> it is a little more complicated to implement (for the cifs case)
>> >> so that we end page writeback (for the non-WB_SYNC)
>> >> as quickly as reasonably possible so we don't kill perf.
>> >>
>> >
>> > The problem here is that the socket layer doesn't have a mechanism
>> > to notify us of a TCP ACK. So, we have to wait for the next-best thing
>> > -- a response from the server.
>>
>> But ... we can stop writeback as soon as kernel_sendmsg returns - once
>> we return from kernel_sendmsg the buffers can (and often will) be
>> freed so we know those pages could not still be used by tcp  (below
>> cifs) once kernel_sendmsg returns.  We can minimize the delay further
>> by making sure we set TCP_NODELAY on the socket (we probably ought to
>> make that the default instead of an option).
>>
>
> That's not correct. A return from kernel_sendmsg just means that the
> data has been buffered up, not that it has been sent and acked. We
> shouldn't use that as an indicator to mean that the pages no longer
> need to be stable.

We can't free the page from the cache until the server responds that
it has written the data (otherwise if the server crashes we have no
way to resend the dirty page), but I don't see any reason to block redirtying
a page as long as we don't break the signing mechanism.  We can allow writes to
a page once the page has been buffered (kernel_sendmsg is complete).
Although cifs has stricter (stricter than open to close) guarantees than nfs
in some case, we could hang on to pages longer as nfs does until the server
returns the equivalent of fsync.



-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux