<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18783">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>Hi All...</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>We are developing a custom translator to log modifications
to files<BR>(including creation, update and deletion) into database.
</FONT><FONT face=Arial>This log is<BR>later used by several processes to
perform asynchronous operations</FONT></DIV>
<DIV><FONT face=Arial>such as indexing recently modified files and updating
an off-site </FONT></DIV>
<DIV><FONT face=Arial>backup for disaster recovery.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Once <FONT face=Arial>this is completed we plan to share
the translator with the </FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT face=Arial>community if anyone is interested in
it.</FONT></FONT><FONT face=Arial></DIV><FONT size=2></FONT>
<DIV><BR><STRONG>Our Current Approach:</STRONG></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV>By reviewing the Gluster and FUSE source code and documentation,
we<BR>concluded that the following FOPs should be monitored for this
purpose: </DIV>
<DIV>open, create, mknod, truncate, ftruncate, writev, flush, release, unlink
and<BR>rename.<BR><BR>We would like to insert one record per each file
modification, hence we<BR>need a mechanism to aggregate multiple operations such
as open, writev<BR>and flush over one file-descriptor into a single
update.<BR><BR>For performance sake and preventing dirty reads, we would like to
do<BR>a database row insertion in the callback of the very last action that
is<BR>performed. By other means, during write we just set flags as modified
</DIV>
<DIV>in file descriptor context and perform the insert in the very last
action.<BR><BR>The major issue is that (as most of the docs and FAQ indicated)
there<BR>is no reliable mechanism to decide which FOP action is the last one.
</DIV>
<DIV>We monitored file system interaction via trace module and noticed<BR>that
the flush action is called several times and release is never invoked<BR>in many
cases.<BR><BR>This issue forced us to log the very first flush which is quite
problematic </DIV>
<DIV>for a number of reasons including the fact that we </FONT><FONT
face=Arial>can never be sure the</FONT></DIV>
<DIV><FONT face=Arial>operation is finished before triggering any of
our asynchronous operations</FONT></DIV>
<DIV><FONT face=Arial>and we are slowing down the initial write because we are
waiting on the</FONT></DIV>
<DIV><FONT face=Arial>log action to complete.</FONT></DIV><FONT face=Arial><FONT
size=2></FONT>
<DIV><BR> </DIV>
<DIV><STRONG>Question:</STRONG><BR>Does anyone have a better solution for
this issue? Perhaps there should </DIV>
<DIV>be a mechanism to notify us of the closing of a file, otherwise an open
file </DIV>
<DIV>descriptor will remain forever. </DIV>
<DIV> </DIV>
<DIV>We would really love to find any other reliable method that allows us to
</DIV>
<DIV>track these operations at a higher level.<BR><BR>We would greatly
appreciate any new approach that can overcome these </DIV>
<DIV>deficiencies.<BR><BR>Thanks in Advance<BR></DIV></FONT>
<DIV><FONT face=Arial>- Drew Morris</FONT></DIV></BODY></HTML>