On 10/31/2011 04:29 PM, Trond Myklebust wrote: >> In files-type reads in a "condense" layout. You should be careful >> because in striping it is common place to have eof on some DSs because >> of file holes even though there are more bits higher on in the file >> at other DSs. You should check to return back only the answer from the >> highest logical read DS. (Or I'm wrong in my interpretation?) > > In the close-to-open cache consistency, O_DIRECT database, or file > locking cases, then either the data has been committed, the file size > extended and the DSes updated, I meant in the case all that as happened (Just opened the file) but any particular DS can return EOF. Example: I have 3 DSs, with stripe unit of say 1K for example. The file has been written to 0K..1K and 2K..3K. In dense layout file-size on DS2 is zero, right? because it was never written too. So if the client is reading 0K..3K (All file), Will it get eof from DS2? > or our client must know that the server > has incomplete information because it is holding cached writes or > layoutcommits that extend the file. In either case, the meaning of the > eofs should be obvious. > I hope that is taken care of, surly? > Benny's old pet project of making 'tail -f' work on a log file that is > being extended by someone else is, OTOH, subject to screwiness. However > that case can be screwy on ordinary read-through-MDS too. > Ye that one was me too. I still think file length can easily be extended only on commit/layout_commit and not on any random write. So the above can work. I think there is all that is needed within the protocol for servers that *want* to support this. With any compliant client. (Ask me if you don't know how, it involves keeping a shadow length per client up until commit, actually with pnfs it is easier) Thanks Boaz -- 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
