On Tue, 21 Oct 2008, steve@xxxxxxxxxxx
> Once thats done, the dlm/glock is dropped (again notification is via
> the dlm) and if Node A has outstanding requests queued up, it
> re-requests the glock. This is a slightly simplified explanation
> but, I hope it gives the general drift.
Yes, thanks.
> So to return to the original subject, in order to allow all
> this locking to occur with no lock ordering problems, we have
> to define a suitable ordering of page locks vs. glocks, and the
> ordering that we use is that glocks must come before page locks. The
> full ordering of locks in GFS2 is in Documentation/filesystems/gfs2-glocks.txt
>
> As a result of that, the VFS needs reads (and page_mkwrite) to
> retry when !PageUptodate() in case the returned page has been
> invalidated at any time when the page lock has been dropped.
Since this commit PG_uptodate isn't cleared on invalidate:
commit 84209e02de48d72289650cc5a7ae8dd18223620f
Author: Miklos Szeredi <mszeredi@xxxxxxx>
Date: Fri Aug 1 20:28:47 2008 +0200
mm: dont clear PG_uptodate on truncate/invalidate
Testing for !page->mapping, however, is a reliable way to detect both
truncation and invalidation.
So the page can have the following states:
!PG_uptodate -> page has not been read
PG_uptodate && page->mapping -> page has been read and is valid
PG_uptodate && !page->mapping -> page has been read but no longer valid
So PG_uptodate does not reflect the validity of the data, only whether
the data was ever made up-to-date.
Does this make sense? Should it be documented somewhere?
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
