Next let's talk about how [UNKNOWN] uses
the memory's available in the clients for
cooperatively caching the files and reducing the
stress on the management of data files. In
[UNKNOWN] as supposed to traditional Unix file
system, they also worry about the coherence
of files. I mentioned earlier that in
Unix file system, the file server assumes that
it is serving each client independently, and therefore it
doesn't worry about sharing a file, if a particular
file happens to be access by multiple users at
the same time, the server doesn't worry about the coherence
of that file. But on the other hand in
XFS the file system worries about cache coherence and
I have already introduced the idea of cache coherence
in the context of multi processes and distributed shared memory.
So you are familiar with the terminology single writer,
multiple reader meaning that a particular file. We have,
at any point of time, only a single writer.
There cannot be multiple writers to the same file,
but it can have multiple readers at the same
time. And the unit of cache coherence that XFS
maintains is at the level of file blocks, not
an entire file. But at the level of individual
file blocks. So if you look at, a
manager for a file, the guy that is responsible
for the metadata management for the file. It
has information about the files for which it is
the manager. Let's say it has a file f1 for which it has a mana, it is
a manager. Then the metadata in the memory of
this manager will have information about the current state
of that file. For instance, this particular entry says that a file f1 managed by
this manager is being read concurrently by two
different clients, c1 and c2. So there are
two different clients, c1 and c2, and they have copies of this file that they
have retrieved from this manager at some point
of time, which means that the client caches,
c1 and c2, contain the contents of this
file. Now for simplicity, I'm showing this as
a file, but in fact the granularity at
which the coherence and information about files is
kept is at a file block level. So at a block level the manager says a particular
block of a file is in the cache of client C1 and in the cache of
client C2. And yet I'm using the word cache to mean that it is in the memory.
Of these clients. So the semantics that is observed
for cache coherence, a single writer, multiple readers. So if client c3
makes a request to the manager for writing to
this file, f1, and again, I have to mentioned
that, the request is going to be at the granularity
of a file block, but for simplicity, I'm showing
it as a write request for this file f1.
But you understand that the granularity at which this request
is being made is for writing a particular block
of that file. So the manager gets this write request.
It looks up the metadata for that particular file.
And it sees that this file is now currently read-shared
by two different clients, c1 and c2. This
guy wants to write to the file. That results
in a conflict, a read/write conflict, and what the
manager is going to do is basically say, well, if
somebody wants to write to that file I
have to tell the guys that currently have the
file. They cannot have it anymore. So just as
in the case of cash coherence in a multi-processor.
This manage is going to send an invalidation message for the file F1 to C1. And
to C2, and they are going to acknowledge
to the manager saying that yes, we have invalidated
our local copies of the files, and once
the manager gets that indication back from the clients,
at that point the manager can tell the
client C3 that Okay, now you have got dibs
on writing to this file. That's the protocol that
is being observed in [UNKNOWN]. To keep the copies
of the files consistent so at the end of
this exchange C3 will have the right to, right
to this particular file. Now how long does it
have that privilege? Well the write request when it
is granted the client gets the token And the
manager, at any point of time, can revoke the token
that was given to C3. And this in particular
will happen when a future read for the same file
comes to the manager. At that point, the manager will
go to C3 and say, I'm revoking the token from
you. You cannot write to that file anymore. You can
read it because the request that I got is only
a read request and therefore you can keep the file,
but you cannot write to it anymore. If you want
to write it again, then you have to make
a request again. This is the protocol that is observed.
And of course, if a particular client is writing to
a file, and another client also wants to write to
the same file, at that point the manager once
again is going to invoke the token, invalidate the file
at this client, pull back the contents of the file,
and then distribute it to a future requester who wants
to write to the same file. That's how cache coherence works. And using
the fact that copies of the file is existing in multiple
clients excepts as exploits that fact to do cooperative caching.
What that means is that if a client is currently
having a copy of the file, let's say, after this interchange.
C3 has a copy of the file. There is also writing to A future read request comes.
When it comes, that read request can be satisfied by getting the
contents of the file from the cache of C3. And that is what cooperative
caching is all about, where instead of going to the disk to retrieve the file
>> We can actual get the file content from the cache of one of the clients
that happens to have a copy of the file.