[Gluster-devel] Re: write-behind mtime glitch

[Brent A Nelson]

Cool beans, I'll do that for now.

Many thanks,

Brent

On Wed, 25 Apr 2007, Anand Avati wrote:

> Brent,
>  a  simpler solution for your mtime issue would be to set the
> aggregate-size to 0, so that every write is instantly written behind
> (and not held back for aggregatino). the performance difference
> brtween write-behind v/s write-behind+aggregatoin is very marginal for
> most practical purposes. hope that helps,
>
> avati
>
> On Wed, Apr 18, 2007 at 09:10:59AM -0700, Anand Avati wrote:
>> Brent,
>>   the write-behind mtime issue has more than one reason. the direct_io
>> related 'fix' got my system to work correctly with "cp -a", beause in
>> my binutils version of 'cp', the utimes() call is *after* the close(),
>> and the direct_io fix (which caused correct flush()ing) worked for me.
>> but you (and krishna) seem to have a newer version of binutils where
>> utimes() is called *before* the close(). utimes happens on the path
>> while write-behind is working over fd's. the right fix would be to
>> flush the 'held back' data during utimes() by relating the fd and the
>> path. for this 'relating' we need some enhancements in our code base
>> (which will be coming in as part of the 'supporting f**** calls'
>> task). Until then the 'cp -a' will continue to have the mtimes issue :(
>>
>> the observation you have mentioned below confirms the theory since at
>> every 'aggregate-size' boundry a flush() is forced by write-behind
>> itself.
>> regards,
>> avati
>>
>> On Tue, Apr 17, 2007 at 04:56:05PM -0400, Brent A Nelson wrote:
>>> I found an additional clue to the write-behind mtime issue.  Some more
>>> copies again showed that zero-length files were getting proper mtime.
>>> Non-empty files again had an mtime associated with the copy EXCEPT for
>>> these two files:
>>>
>>> -rw-r--r-- 1 root root 131072 2006-07-11 08:48
>>> /backup/usr0/share/samba/lowcase.dat
>>> -rw-r--r-- 1 root root 131072 2006-07-11 08:48
>>> /backup/usr0/share/samba/upcase.dat
>>>
>>> Well, my write-behind has "option aggregate-size 131072"! I'm guessing
>>> that's not a coincidence...
>>>
>>> Thanks,
>>>
>>> Brent
>>>
>>> On Fri, 13 Apr 2007, Brent A Nelson wrote:
>>>
>>>> On Wed, 11 Apr 2007, Krishna Srinivas wrote:
>>>>
>>>>> Also regarding write-behind+mtime bug, can you check out the
>>>>> latest code and see if rsync or "cp -a" still sees the problem?
>>>>> Avati made has some changes.
>>>>>
>>>>
>>>> write-behind still has an mtime bug.  I "cp -a"'ed a /usr directory and
>>>> all non-empty files had file creation time/date for their mtime rather
>>>> than the original mtime.  Directories have the correct mtime, and
>>>> zero-length files have the correct mtime on both underlying filesystems,
>>>> however, so this is working.  But whenever it writes actual data, it seems
>>>> like it must be doing this after the mtime is set, changing the mtime, or
>>>> the mtime is never getting set.
>>>>
>>>> Thanks,
>>>>
>>>> Brent
>>>>
>>>
>>
>> --
>> ultimate_answer_t
>> deep_thought (void)
>> {
>>   sleep (years2secs (7500000));
>>   return 42;
>> }
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>
> -- 
> ultimate_answer_t
> deep_thought (void)
> {
>  sleep (years2secs (7500000));
>  return 42;
> }
>