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://zresearch.com/pipermail/gluster-users/attachments/20090116/5f3f375e/attachment.htm
