Re: [PATCH 1/2] Read /etc/exports.d/*.export as extra export files

[Steve Dickson <SteveD@redhat.com>]

On 03/05/2011 11:54 AM, Masatake YAMATO wrote:
> On Fri, 04 Mar 2011 11:21:54 -0500, Steve Dickson <SteveD@redhat.com> wrote
>>
>>
>> On 03/04/2011 01:10 AM, Masatake YAMATO wrote:
>>> Hi,
>>>
>>> thank you for replying.
>> Again.. my apologies for taking so long... 
>>
>>>
>>>> On 03/03/2011 09:01 AM, Masatake YAMATO wrote:
>>>>> No comment?
>>>> Sorry about that... I was traveling for the couple weeks... 
>>>>
>>>> Would you happen to have an example script on how 
>>>> this new feature would be used? I just want to run 
>>>> some quick tests...
>>>>
>>>> tia,
>>>>
>>>> steved.
>>>
>>> Could you try following one?
>>>
>>> # cd /tmp
>>> # mkdir /tmp/alpha
>>> # mkdir /tmp/beta
>>> # mkdir /etc/exports.d
>>> # mkdir /etc/exports.d
>>> # echo '/tmp/alpha *(ro)' > /etc/exports.d/alpha.export
>>> # echo '/tmp/beta *(ro)'  > /etc/exports.d/beta.export
>>> # /etc/init.d nfs restart
>>>
>>> After above setting up, when you do `exportfs', following lines 
>>> may be included in the output:
>>>
>>>     /tmp/alpha	 <world>
>>>     /tmp/beta        <world>
>> Question... Where is the race? Meaning who is reading the exports
>> file while its being modified?
> 
> Sorry, I don't understand well. Are you talking about race condition
> introduced with my patch?
I thought you were doing this because some one trying to read
the exports as they were being updated... but after reading 
your entire email I see I was mistaken... 

> 
>> The reason I ask is exporting (or re-exporting) pretty serial:
>>
>> exportfs read /etc/exports
>> exportfs writes the new exports to /var/lib/nfs/etab
>> mountd notices etab has changed and rereads its.
>> mountd flush the kernel cache cause the kernel to do upcalls to get the new exports.
> 
> With my patch doesn't change match this sequence:
> 
> (S1) exportfs read /etc/exports
> (S2) exportfs read /etc/exports.d/*.export 
> (S3) exportfs writes the new exports to /var/lib/nfs/etab
> (S4) mountd notices etab has changed and rereads its.
> (S5) mountd flush the kernel cache cause the kernel to do upcalls to get the new exports.
> 
> I've added (Sn) to make discussion easier. I've just added S2 stage.
>  
>> So since exportfs command not a daemon I don't see why 
>>    cp exports.new /etc/exports && exportfs -arv
>>
>> isn't all that is needed.  What am I missing?
> 
> Consider the case when an user wants to add following entry to /etc/exports:
> 
> 	 '/tmp/alpha *(ro)'
> 
> How one will do? Without my patch I image following sequence (sequence 1).
> 
>     cp /etc/exports exports.new
>     echo '/tmp/alpha *(ro)' >> exports.new
>     cp exports.new /etc/exports && exportfs -arv    
> 
> With my patch this sequence becomes simplified as (sequence 1'):
> 
>      echo '/tmp/alpha *(ro)' > /etc/exports.d/alpha.export
>      exportfs -arv    
> 
> When duplicated entries must be considered the sequence 1 may become
> more complex.
> 
> 
> Next, consider removing the export entry from /etc/exports.
> Without my patch I image following sequence (sequence 2).
> 
>     cp /etc/exports exports.old
>     grep -v '/tmp/alpha *(ro)' < exports.old > /etc/exports
>     exportfs -arv        
> 
> With my patch this sequence becomes simplified as (sequence 2'):
>     rm /etc/exports.d/alpha.export
>     exportfs -arv 
I understand and its a good idea.. thanks for the explanation...

> 
> 
> More background I'm thinking expanding the area of utilizing rpm package
> in system management. Consider installing an export entry to a system
> via rpm package. Without my patch you have to write down sequence 1
> to %post and sequence 2 to %postun of the spec file. With my patch
> you have to just put /etc/exports.d/alpha.export to %files section.
> 
> This story of rpm is just my application. However, I thik my patch may be
> useful for other purposes. 
I agree but I do have a question on the first patch which I will ask
in replay to that email...

Thanks again!

steved.