[OpenAFS-devel] Re: [master] Change 536: (openafs) Add support for blocking readahead

Jason Edgecombe jason@rampaginggeek.com
Wed, 30 Sep 2009 20:48:56 -0400


Hi Matt,

It is not trivial to fix at all. Changing any part of a git commit will 
alter the sha1 hash. That hash is used as the primary key for the 
commit. Each subsequent commit contains the sha1 sum of the previous 
commit as a reference. The net effect of this is that changing a commit 
will make all other clones of the repository contain orphaned commits. 
In order to this to happen, the master repo must be changed and everyone 
with a clone must reapply any changes that aren't in the master repo to 
the new head. If you want to be really safe, a developer might  save the 
local changes, nuke the local git clone, download a new clean clone, and 
reapply the local changes.

Tagged commits have the same rules as commits, so changing a commit 
would invalidate the gpg-signed tag that just happened for 1.5.55.

Add to the fact that I'm not sure what would break if someone tried to 
commit to gerrit without having cleaned their repo after the change.

This is a drawback of using git. The takeaway from this is that anything 
that hits the main openafs git repo is set in stone.

Jason

Matt W. Benjamin wrote:
> Actually, isn't this sort of thing trivially fixable?
>
> Thanks,
>
> Matt
>
> ----- "Derrick Brashear" <shadow@gmail.com> wrote:
>
>   
>> so next time submit as -1 on the description, and it'll get fixed.
>> too
>> late now, and it wasn't obvious to me from the previous comments that
>> this was a blocker. we've certainly screwed up descriptives before
>> this one, and we will again.
>>
>> On Wed, Sep 30, 2009 at 2:07 AM, Matt W. Benjamin <matt@linuxbox.com>
>> wrote:
>>     
>>> As I commented, the first part of the commit description is
>>>       
>> inaccurate, and implies that openafs did not previously have "support
>> for the readpages system call" (sic)--when in fact, it did, as part of
>> cache bypass.  The work that I did included adding a readpages vmop
>> implementation, so this goes to attribution, which Simon has told me,
>> he thinks is Very Important.
>>     
>>> ----- Forwarded Message -----
>>> From: "Derrick Brashear" <shadow@dementia.org>
>>> To: "Simon Wilkinson" <sxw@inf.ed.ac.uk>
>>> Cc: "Derrick Brashear" <shadow@dementia.org>, "Matt Benjamin"
>>>       
>> <matt@linuxbox.com>, "Marc Dionne" <marc.c.dionne@gmail.com>
>>     
>>> Sent: Tuesday, September 29, 2009 3:12:27 PM GMT -05:00 US/Canada
>>>       
>> Eastern
>>     
>>> Subject: [master] Change 536: (openafs) Add support for blocking
>>>       
>> readahead
>>     
>>> Change 536 by Simon Wilkinson submitted to master:
>>>
>>> Add support for blocking readahead
>>>
>>> This patchset adds support for the readpages() system call, and
>>>       
>> enables
>>     
>>> readahead on Linux. At the moment each page read causes readpages
>>>       
>> to
>>     
>>> block, so the client won't see much benefit from readahead, beyond
>>>       
>> the
>>     
>>> reduction in call overhead.
>>> ---
>>> M src/afs/LINUX/osi_vfsops.c
>>> M src/afs/LINUX/osi_vnodeops.c
>>>
>>> Approvals:
>>>  Matt Benjamin: Looks good to me, but someone else must approve
>>>  Derrick Brashear: Verified; Looks good to me, approved
>>>
>>> --
>>> To view visit http://gerrit.openafs.org/536
>>> To unsubscribe, visit http://gerrit.openafs.org/settings
>>>
>>> Gerrit-MessageType: merged
>>> Gerrit-Project: openafs
>>> Gerrit-Branch: master
>>>
>>> --
>>>
>>> Matt Benjamin
>>>
>>> The Linux Box
>>> 206 South Fifth Ave. Suite 150
>>> Ann Arbor, MI  48104
>>>
>>> http://linuxbox.com
>>>
>>> tel. 734-761-4689
>>> fax. 734-769-8938
>>> cel. 734-216-5309
>>>
>>>       
>>
>> -- 
>> Derrick
>>     
>
>