You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
as writeback cache is always enabled, there still lacks proper invalidation cross jdfc. as long as all client programs follow the create-with-tmp-name -> write-content -> rename-to-formal-name procedure, which is reasonable paradigm in HPC context, there won't be too much trouble. but if any client has its os to prefetch the tmp-named intermediate file, the dirty cache pages tends to linger forever. this is possible if the os has a background search indexer running upon the JDFS mounted volume.
a solution from JDFS side may be to use a tmp dir at jdfs, hidden from all jdfc, to contain newly created files, and only move the file out to its formal pathname (visible to all jdfc) after the creating jdfc closed all handles to it. the creating jdfc should always see the file it created at formal path of course, or many programs will break for certain.
The text was updated successfully, but these errors were encountered:
complyue
changed the title
implement cross-client writeback cache invalidation
implement cross-client writeback cache coherence
Aug 15, 2019
as writeback cache is always enabled, there still lacks proper invalidation cross jdfc. as long as all client programs follow the
create-with-tmp-name -> write-content -> rename-to-formal-name
procedure, which is reasonable paradigm in HPC context, there won't be too much trouble. but if any client has its os to prefetch the tmp-named intermediate file, the dirty cache pages tends to linger forever. this is possible if the os has a background search indexer running upon the JDFS mounted volume.a solution from JDFS side may be to use a tmp dir at jdfs, hidden from all jdfc, to contain newly created files, and only move the file out to its formal pathname (visible to all jdfc) after the creating jdfc closed all handles to it. the creating jdfc should always see the file it created at formal path of course, or many programs will break for certain.
The text was updated successfully, but these errors were encountered: