Re: A question about NFS delay-write
Re: A question about NFS delay-write
- Subject: Re: A question about NFS delay-write
- From: Mike Mackovitch <email@hidden>
- Date: Tue, 3 Jan 2012 13:58:27 -0800
On Fri, Dec 23, 2011 at 06:12:03PM +0800, Sid Moore wrote:
> Hello.
>
> I have a quest about NFS delay-write. As you know, NFS client will try
> to merge as much writing request as possible to a nfsbuffer, writing
> it to NFS server when it is full of dirty pages if CacheIO. But dirty
> pages bitmap in a nfsbuf object are never explicitly set in
> nfs_vnop_write() flow. So, in delay-write case, pages involved in
> small grain writing IO was not set to be dirty. After
> nfs_buf_release(), I think Mach VM will regards them as valid and
> non-dirty pages. So, those pages would be dropped if memory shortage,
> rather than be pageout to NFS server.
>
> Am I correct? If so, I think it is a bug?
That's not quite correct.
The nfsbuf uses a single range to track the part of the buffer that contains
the range of the buffer that has been modified via a write(2) call.
The NFS client's delayed writing only applies to writes within a buffer
that do not extend to the end of the buffer. The buffer will be written
as soon as a write hits the end of the buffer - or if non-contiguous write
requests are made (since only one "dirty" range is stored).
The nfsbuf page bitmaps are only for maintaining the status of pages dirtied
via memory-mapped modifications. That's why the pages aren't marked dirty
in the write() path.
If a page is marked dirty then all of that page must be written to the server.
You do not want NFS to mark pages dirty when a write() touches part of the page,
because other clients may be writing to other parts of the page. Marking the page
dirty on the write() path would result in the cient writing the entire page which
would cause the other client's changes to the page to be lost.
The VM will not drop the pages with delayed write() data without first
asking the NFS file system if it is OK to do so.
HTH
--macko
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden