On Wed, Feb 11, 2015 at 12:47:26PM -0500, Trond Myklebust wrote: > On Wed, Feb 11, 2015 at 12:39 PM, Marc Eshel <eshel@xxxxxxxxxx> wrote: > > > > A good hint that we are dealing with a sparse file is the the number of > > blocks don't add up to the reported filesize > > Sure, but that still adds up to an unnecessary inefficiency on each > READ_PLUS call to that file. > > My point is that the best way for the client to process this > information (and for the server too) is to read the sparseness map in > once as a bulk operation on a very large chunk of the file, and then > to use that map as a guide for when it needs to call READ. I thought we agreed that the sparseness map made no sense because the information was immeadiately stale? Anyway, the client could build that map if it wanted to using SEEK. I'm not arguing that it would be efficient, but that it could be done with a cycle of looking for holes. -- 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
