<p>We will bw working on background file sync and atleast give it as a configurable option.</p>
<p>Avati</p>
<p><blockquote>On Jan 16, 2009 3:41 AM, "Keith Freedman" <<a href="mailto:freedman@freeformit.com">freedman@freeformit.com</a>> wrote:<br><br><p><font color="#500050">At 03:22 AM 1/16/2009, Krishna Srinivas wrote:
>In the latest AFR code, the healing code is in looku...</font></p>this behavior is extremely handy from the perspective of data<br>
integrity, however, it's disastrous from the perspective of IO<br>
performance from an applications point of view.<br>
<br>
the idea that an application should have to wait while file<br>
completely unrelated to it's needs are being auto-healed is an<br>
unnecessary one. There's got to be a way to handle this. The<br>
replication should happen in the background, and gluster should be<br>
smart enough to first auto-heal the file in question return control<br>
back to the requesting process and then continue healing in the background.<br>
<br>
in the case of a directory, the listing of the directory can be<br>
returned without actually copying over all the files therein. This<br>
should be a relatively quick operation.<br>
<br>
Lets take an example case of a repository for large video<br>
files. each one being 1GB.<br>
I have a server down for a few hours, during which time 300 of these<br>
files have been updated.<br>
<br>
now all I need to know is which ones changed recently (say, ls -alrtu<br>
| tail -5) . I block waiting for 300GB of data to be transferred<br>
when I only need a directory listing?<br>
similarly, if I get a request for just one of those files, I have to<br>
wait for 300GB of data to move around before I can get access to the<br>
only 1GB that matters at that time?<br>
<br>
If this is only temporary until the new healing methodology<br>
previously discussed on the list is in place, I suppose it's<br>
liveable, but if this is the way it's going to continue to work, I<br>
can't imagine it being useful in any practical real-world situations<br>
with either large directories or large files with a normal level of<br>
file updates/modifications.<br>
<font color="#888888"><br>
Keith<br>
</font><p><font color="#500050">
>Krishna
>
>On Thu, Jan 15, 2009 at 9:35 AM, Keith Freedman
><<a href="mailto:freedman@freeformit.com">freedman@freeformit.com</a>> wrote:
> > ...</font></p></blockquote></p>