[ClusterLabs] Antw: Re: Notice: SLES11SP4 broke exportfs!

[Ulrich Windl]

>>> Dejan Muhamedagic <dejanmm at fastmail.fm> schrieb am 21.12.2015 um 11:40 in
Nachricht <20151221104011.GB9783 at walrus.homenet>:
> Hi,
> 
> On Fri, Dec 11, 2015 at 07:27:28PM +0100, Ulrich Windl wrote:
>> Hi!
>> 
>> After updating from SLES11SP3 (june version) to SLES11SP4 (todays version) 
> exportfs fails to get the export status. I have message like this in syslog:
>> 
>> Dec 11 19:22:09 h04 crmd[11128]:   notice: process_lrm_event: 
> rksaph04-prm_nfs_c11_mnt_exp_monitor_0:93 [ 
> /usr/lib/ocf/resource.d/heartbeat/exportfs: line 178: 4f838db1: value too 
> great for base (error token is "4f838db1")\n ]
> 
> The value of the fsid is unexpected. The code (and I) assumed
> that it would be decimal and that's mentioned in the fsid
> meta-data description.

Hi!

Really? crm(live)# ra info exportfs:

[...]
fsid* (string): Unique fsid within cluster or starting fsid for multiple exports
.
    The fsid option to pass to exportfs. This can be a unique positive
    integer, a UUID, or the special string "root" which is functionally
    identical to numeric fsid of 0.
    If multiple directories are being exported, then they are
    assigned ids sequentially starting with this fsid (fsid, fsid+1,
    fsid+2, ...). Obviously, in that case the fsid must be an
    integer.
    0 (root) identifies the export as the root of an NFSv4
    pseudofilesystem -- avoid this setting unless you understand its
    special status.
    This value will override any fsid provided via the options parameter.
[...]

Did you read "UUID" also? 

> 
>> Why is such broken code released? Here's the diff:
> 
> I suspect that every newly released code is broken in some way
> for some deployments.

The code clearly does not match the description, and it is broken.
I would also expect that "validate" would report values for fsid it cannot handle.
Furthermose I see no sense in trying to increment a fsid.

Maybe you can explain.

Regards,
Ulrich