When Does Another NFS Client See a Changed Model File?

Follow the close/open boundary

The Linux NFS client manual describes sequential sharing: client A opens, writes and closes a file before client B opens it. In its NFSv3 explanation, the client checks with the server on open even when cached attributes are fresh; close writes pending changes back and can report write errors.

That is the useful mechanism behind the handoff. A close supplies a writeback boundary and the later open supplies a checking boundary. Neither event describes every read during an overlapping writer's activity.

Keep this Linux client explanation attached to its documented scope. For a proposed system, the client implementation, negotiated NFS version and applicable caching behavior must be identified. The NFSv4.1 qualifications below matter before extending the sequential claim to another implementation.

References: [N1]

Two clients, one file, two access schedules

Consider fictional clients A and B using one server-side model file. Stipulate two content generations, G0 and G1, of the same length. A replaces the contents of that same file object with G1; the pathname's target is not replaced. The stipulated Linux NFSv3 clients provide the manual's close-to-open behavior, use buffered file I/O and have no additional application serialization. There is one writer, no failure or later update, and no application-private model copy supplying B's reads. These are example assumptions, not observations or an application update method.

In the sequential schedule, B has previously read G0 and closed its file. A then writes all of G1 and successfully completes its close. Only afterward does B freshly open and read the file. For clients providing the documented close-to-open behavior, this is the schedule intended to make A's changes available to B. A claim supported by this case should retain those assumptions.

In the overlapping schedule, B opens and reads G0, then keeps its file open while A writes G1 and closes. B continues reading through that existing open file. The manual identifies opportunities for stale cached data; A's close alone does not establish B's next-open check. The sequential argument therefore cannot certify B's subsequent reads as G1.

This does not predict that B must return G0, must return mixed contents or must change after a particular delay. Those would require evidence for the actual implementation and access pattern. The example exposes a missing premise: evidence from the first schedule cannot establish the second. Equal file lengths were stipulated precisely so a length comparison cannot distinguish the generations.

References: [N1]

Separate attributes, data and file identity

An attribute cache holds metadata; a data cache holds file contents. The Linux manual distinguishes their coherence. A recently obtained timestamp is not itself a read of the file's bytes.

NFSv3 modifying operations can return before-and-after attributes as weak cache consistency information. RFC 1813 explains that these help a client recognize intervening changes and manage cached data, while explicitly stopping short of strict server-client consistency. WCC is not evidence that every other reader has consumed the update.

Keep the identity question separate as well. The example fixes one server-side object. A proposal that changes which object a pathname names needs its own identity explanation. RFC 8881 treats file identity separately from data validation. Matching the pathname in two reports cannot establish matching content observations, even when both reports concern the intended object.

References: [N1][R3][R4]

NFSv4.1 qualifies the validation path

RFC 8881, August 2020, requires revalidation without an OPEN delegation at least for opens denying write access; deny-none opens may also revalidate. The protocol therefore does not promise revalidation at every ordinary open.

Validation compares the server’s change attribute with the cached value; a difference invalidates cached data and attributes. Modification-time granularity can miss updates. This is why matching displayed times cannot certify one generation.

Delegations are optional and recallable. Eligible opens can avoid server validation messages; conflicting access requires recall. A write delegation can defer close-time writeback until recall, subject to its limits. This is coordinated caching, not a continuously refreshed application view.

The RFC's locking rules also depend on protection matching the accessed byte ranges. An unspecified statement that a product uses locks leaves the relevant application coordination unexplained.

References: [R4]

Ask for evidence covering the intended reader

A supplier's demonstration should describe the reader whose behavior matters. Does it freshly open the file after the writer's successful close, or retain an open file while updates occur? Does it request file bytes again, or reuse a previously loaded model? Which content generation is the claim about? These questions define the purchase without prescribing a cache or locking change.

For the fictional case, a report that B freshly opened and consumed G1 would support that identified sequential observation. It would leave the overlapping case unanswered. Conversely, one observation of G0 through B's retained open file would describe that observation; it would not establish a universal stale-data interval.

Ask the appointed storage and application providers to connect their claim to the actual clients, protocol version, sharing assumptions and evidence identifying the bytes consumed. A directory listing or a matching timestamp answers less than a statement identifying the reader's content generation. If a provider promises a visibility interval, request evidence for that interval under the intended schedule; no interval follows from the close-to-open label alone.

Keep visibility separate from a complete model release

Seeing G1 in one file does not establish that optimizer state, model shards and associated metadata belong to the same completed release. One file's handoff supplies no evidence that a set of files was published atomically.

Nor should a visibility claim replace the stated durability requirement. RFC 8881 separately requires server stable-storage commitment before the nondelegated write CLOSE. Application checkpoint completeness and the contents of a recovery copy remain separate questions, covered by the related checkpoint-versus-snapshot article.

References: [R4]

Connect a separate physical cabling requirement

If the selected storage service also needs physical connections installed or documented, Leviathan's Structured Cabling & Fiber Installation service is relevant to that agreed work. Use its project inquiry with the approved endpoints, routes, specified assemblies, materials responsibilities and required connection records.

The storage and application providers retain responsibility for file visibility, software configuration and application acceptance. A physical connection record does not establish either access schedule's content result.

References: [L1]