On Wed, Jan 28, 2015 at 03:42:53PM -0500, Anna.Schumaker@xxxxxxxxxx wrote: > From: Anna Schumaker <Anna.Schumaker@xxxxxxxxxx> > > These patches add server support for the NFS v4.2 operation READ_PLUS. > > I noticed a race condition in the 3rd patch when I start needing vfs_llseek() > to determine if I should encode the next segment as either data or a hole. It > is possible that the file could change on us between each of the seek calls, > so we don't know if we are actually at a hole or data segment. I don't want to > add new locks to the NFS server for this case, so instead I've decided to > encode any "quantum data" segments as if they were actually data. > > I tested these patches using xfstests, specificially generic/075, generic/091, > generic/112, generic/127, generic/210, and generic/263. Additionally, three > new tests are run once READ_PLUS support has been added: generic/213, > generic/214, and generic/228. Why do theses test start working when you use READ_PLUS? They should only depend on ALLOCATE support, and maybe SEEK if we're trying to figure out information about mappings somehow. -- 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