SCIENTIFIC-LINUX-DEVEL Archives

December 2011

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Pat Riehecky <[log in to unmask]>
Reply To:
Pat Riehecky <[log in to unmask]>
Date:
Thu, 8 Dec 2011 16:31:28 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (175 lines)
On 12/08/2011 09:07 AM, Stephan Wiesand wrote:
> On Dec 7, 2011, at 21:08 , Connie Sieh wrote:
>
>> On Wed, 7 Dec 2011, Stephan Wiesand wrote:
>>
>>> Hi Developers,
>>>
>>> openafs should be updated with 6.2. Unfortunately, it's not so easy to decide to what:
>>>
>>> 1.6.1 may not be released in time for 6.2
>>>
>>> 1.6.0 has a number of known problems (but none that aren't in our current build as well)
>>>
>>>
>>> What we're currently testing here is 1.6.0 with two very simple patches:
>>>
>>> 1) Disables idledead timeouts on clients. This change is what the developers propose for 1.6.1, see https://lists.openafs.org/pipermail/openafs-devel/2011-November/018583.html .
>>> 2) Disables NAT Pings on clients. Those are a new feature with 1.6. The feature is useful, but currently it has a bug making the clients ping much more aggressively than they're supposed to. This becomes a problem when the number of 1.6 clients in a cell grows. See https://lists.openafs.org/pipermail/openafs-info/2011-December/037191.html .
>>>
>>> This is what I'd propose for SL 6.2 right now.
>>>
>>> In addition, we should - IMHO - add a few fixes for serious issues from the stable-1.6.x git tree. That's what I'll try here next. But Troy used to be rather conservative accepting such changes, and he was probably right.
>> Please list what you propose for these issues and their fixes.
> These are the ones I think should really go in (excluding many that are relatively simple patches that fix real bugs, and trivial patches like documentation updates and corrected log messages):
>
> 2011-09-13 ihandle: Fix IH_REALLYCLOSE for positional I/O
> affects: DAFS - possible data loss, seen in the wild
> complexity: high
> risk: normal
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=f4dd94edf7384dee912a09354f500d08421f94d4
> http://gerrit.openafs.org/#change,5404
> https://rt.central.org/rt/Ticket/Display.html?id=130215
>
> 2011-10-26 viced: Do not swallow errors on StoreData recovery
> affects: fileserver - may miss errors storing data
> complexity: low
> risk: low
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=d1711efd73b8dea177672eeb477a23d4a83b95b7
> http://gerrit.openafs.org/#change,5711
>
> 2011-10-26 LINUX: Revert group changes on keyring failure
> affects: client - may accumulate PAGs over time, causing performance problems
> complexity: normal
> risk: normal
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=d6c5cde26e35498e7eb7cde02b30ed94d26b37e6
> http://gerrit.openafs.org/#change,5712
>
> 2011-10-26 volser: Remove ExtractVolId
> affects: volserver - may fail to handle large volume ids
> complexity: low
> risk: low
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=080e4a736ba95d4dcb4167a1a8f8accab8a928b0
> http://gerrit.openafs.org/#change,5720
>
> 2011-11-02 libafs: Set tvcp->callback before BulkStatus
> affects: client - may incorrectly assume it holds callbacks for certain files
> complexity: normal
> risk: normal
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=f6168a849cbb5bde34cec11e02df54481fc5d3ca
> http://gerrit.openafs.org/#change,2548
>
> 2011-11-02 vol: Handle large volume IDs in VLockFile
> affects: vol commands and server - may fail on large volume ids
> complexity: moderate
> risk: moderate
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=5823fda443115d3aae966d09141f5de4199f5741
> http://gerrit.openafs.org/#change,5758
>
> 2011-11-02 afs: Avoid memory leak on recursive write flock
> affects: client - memory leak when locking a file already locked
> complexity: low
> risk: normal
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=741bea05a3a5d170d47ca9df590f84ab02a7baad
> http://gerrit.openafs.org/#change,5765
>
> 2011-11-02 afs: Retry unlock after afs_StoreAllSegments
> affects: client - may panic when unlocking files
> complexity: moderate
> risk: normal
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=c096127f73348a470e0e478b31c3fe132304b009
> http://gerrit.openafs.org/#change,5766
> https://rt.central.org/rt/Ticket/Display.html?id=125446
>
> 2011-11-09 rx: Don't clear the receive queue when out of packets
> affects: any - client-server connections may hang
> complexity: low
> risk: normal
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=4ff4ec8ac94a75385d919f9031abaec31aca9b26
> http://gerrit.openafs.org/#change,5820
>
> 2011-11-20 viced: avoid bogus handle in rename
> affects: fileserver - may crash
> complexity: low
> risk: normal
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=f718feb826926a67f428b482a580d03c788dfabf
> http://gerrit.openafs.org/#change,6081
> https://rt.central.org/rt/Ticket/Display.html?id=130215
>
> 2011-11-20 klog.krb5: enforce DES for rxkad
> affects: klog.krb5 - fails with recent heimdal servers
> complexity: high
> risk: very low
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=8150bbbf0dbc6732860214180735ba509902f417
> http://gerrit.openafs.org/#change,6087
> https://rt.central.org/rt/Ticket/Display.html?id=130278
>
> 2011-11-22 Linux: make sure backing_dev_info is zeroed
> affects: client - may oops the kernel
> complexity: very low
> risk: very low
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=032736bc052d3fb1a1d4f033a47e844d7f4ea05a
> http://gerrit.openafs.org/#change,6104
>
> 2011-11-28 dafs: avoid null deref getting volume header
> affects: DAFS - may segfault
> complexity: low
> risk: normal
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=9865698ee0d81d371b8846a1145a46f691de8388
> http://gerrit.openafs.org/#change,6122
>
> 2011-11-28 Unix CM: Fix PutVolume in afs_BlackListOnce
> affects: client - uses volume data after dropping the reference to it
> complexity: very low
> risk: low
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=a8160e462821d718df0bd00f1642dbc1bc9bc7a8
> http://gerrit.openafs.org/#change,6124
>
> 2011-12-01 viced: disable accelerated copyonwrite
> affects: fileserver - possible data loss, seen in the wild
> complexity: normal
> risk: normal
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=c73b66447cb84cf1f07775b9f93b745050e4972c
> http://gerrit.openafs.org/#change,6160
> https://rt.central.org/rt/Ticket/Display.html?id=130295
>
> 2011-12-01 remove CopyOnWrite2 and unused vars
> affects: fileserver - removes a static function now unused due to 6160
> complexity: trivial
> risk: none
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=4e05bc3b5cd50354bcade3c38c0ec97713b148c8
> http://gerrit.openafs.org/#change,6161
>
>
>

My newness to this (and many other) aspects of the project is going to 
come forward on this matter.  So anything I say here consider it at its 
strongest provisional at at the weakest a sign of my ignorance.

I will confess the number of patches there makes me somewhat nervous.... 
Things with low complexity and low risk are one thing, but the items 
marked high are another matter.  And I've always preferred not to 
deviate from upstream releases.  Patches that are accepted in the tree 
will probably remain there, but what if thing move a bit before release.

 From a 'fewer patches is better' standpoint, if the bugs fixed here are 
already present on SL6.1, adding patches for a fix - while an excellent 
idea, could put us in a weird spot.  I like the idea of fixing things, 
but I'm not sure that having an SL specific build is the best of ideas.

When they release 1.6.1 we will almost certainly package it and put it 
in wherever makes best sense at the time.  This is a longer view and 
doesn't address some of the performance related issues (like the ping 
one you mentioned).

All this is to say, "hmmmm I like fixes, but I really don't like forking 
off even when we are forking off to get things that will eventually be 
included."

Pat

-- 
Pat Riehecky
Scientific Linux Developer

ATOM RSS1 RSS2