Re: [PATCH v4 0/3] NFSv4.2: Add support for the COPY operation

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

 



On Fri, Jul 29, 2016 at 03:40:00PM -0400, Anna Schumaker wrote:
> On 07/29/2016 02:59 PM, J. Bruce Fields wrote:
> > On Fri, May 13, 2016 at 04:58:06PM -0400, Anna Schumaker wrote:
> >> On 05/13/2016 04:31 PM, J. Bruce Fields wrote:
> >>> On Sun, May 01, 2016 at 10:37:33AM -0700, Christoph Hellwig wrote:
> >>>> I might sound like a broken record, but I'd feel much happier if this
> >>>> had extensive xfstests coverage.  Xfstests has over one hundred tests for
> >>>> file clones, and many of them should be easily adapatable.
> >>>
> >>> Anna, have you looked at this yet?
> >>
> >> Yep!  I just sent out what I came up with :)
> > 
> > Sorry for the lack of response.  For some reason I don't seem to have
> > the updated version in my mailboxes.  Do you have a more recent version?
> 
> I'm not sure, so I'll make sure my code still works and then resubmit!
> 
> > 
> >>> I don't see any obvious problem with the nfsd code, other than the
> >>> obvious issue with large synchronous copies tying up server threads and
> >>> leaving clients waiting--but maybe we should just see how people end up
> >>> using it and deal with the problems as they come up.
> > 
> > I'm still worrying about this, though.
> > 
> > As a simple stopgap, could we just set *some* maximum on the size of the
> > copy?  Or better yet on the time?--that'd let filesystems with
> > clone-like features copy the whole file without blocking an nfsd thread
> > indefinitely in the case of other filesystems.
> 
> Would there be a good way of figuring out the time a copy would take?

Can we set some sort of timer to signal our thread after a limit?  Then
hopefully the copy loop gets interrupted and we can return the amount
copied so far.  (And hopefully the client has actually set the
contiguous flag so it can continue where it left off.)

> Capping with an arbitrary size would definitely be simpler, so I'll
> look into adding that.

I'm not sure how to set the limit.  The downside (assuming the
client/application handle the short copy correctly) is that data can
stop flowing while we wait for the client to send us the next copy, but
I'm not sure how high the cap needs to be before that becomes
negligible.

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



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux