[Gluster-users] Replication for missing file

[Anand Avati]

We will bw working on background file sync and atleast give it as a
configurable option.

Avati

On Jan 16, 2009 3:41 AM, "Keith Freedman" <freedman at freeformit.com> wrote:

At 03:22 AM 1/16/2009, Krishna Srinivas wrote: >In the latest AFR code, the
healing code is in looku...
this behavior is extremely handy from the perspective of data
integrity, however, it's disastrous from the perspective of IO
performance from an applications point of view.

the idea that an application should have to wait while file
completely unrelated to it's needs are being auto-healed is an
unnecessary one.  There's got to be a way to handle this.  The
replication should happen in the background, and gluster should be
smart enough to first auto-heal the file in question return control
back to the requesting process and then continue healing in the background.

in the case of a directory, the listing of the directory can be
returned without actually copying over all the files therein.  This
should be a relatively quick operation.

Lets take an example case of a repository for large video
files.  each one being 1GB.
I have a server down for a few hours, during which time 300 of these
files have been updated.

now all I need to know is which ones changed recently (say, ls -alrtu
| tail -5) .  I block waiting for 300GB of data to be transferred
when I only need a directory listing?
similarly, if I get a request for just one of those files, I have to
wait for 300GB of data to move around before I can get access to the
only 1GB that matters at that time?

If this is only temporary until the new healing methodology
previously discussed on the list is in place, I suppose it's
liveable, but if this is the way it's going to continue to work, I
can't imagine it being useful in any practical real-world situations
with either large directories or large files with a normal level of
file updates/modifications.

Keith

>Krishna > >On Thu, Jan 15, 2009 at 9:35 AM, Keith Freedman ><
freedman at freeformit.com> wrote: > > ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090116/5f3f375e/attachment.html>