Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: NFSv3 Client for RTEMS (was: Problem NFS mounting Centos 7 file systems from vxWorks 5.5)
From: Andrew Johnson <anj@aps.anl.gov>
To: <tech-talk@aps.anl.gov>
Date: Fri, 20 Jan 2017 16:05:27 -0600
If anyone in the EPICS RTEMS community gets this NFSv3 client working,
please report that here and explain which RTEMS version(s) it works on...

- Andrew


On 01/20/2017 04:30 AM, Heinz Junkes wrote:
> Found this in RTEMS-Maillist:
> 
> Message: 1 
> Date: Mon, 13 Jun 2016 14:33:23 +0200
> <http://airmail.calendar/2016-06-13%2014:33:23%20GMT+2> 
> From: Sebastian Huber <sebastian.huber@embedded-brains.de
> <mailto:sebastian.huber@embedded-brains.de>> 
> To: Till Straumann <strauman@slac.stanford.edu
> <mailto:strauman@slac.stanford.edu>>, RTEMS 
> <users@rtems.org <mailto:users@rtems.org>> 
> Subject: Re: Standard RTEMS NFSv3 client now available via libbsd 
> Message-ID: <575EA813.6060108@embedded-brains.de
> <mailto:575EA813.6060108@embedded-brains.de>> 
> Content-Type: text/plain; charset=utf-8; format=flowed 
> 
> On 10/06/16 16:47
> <http://airmail.calendar/2016-06-10%2016:47:00%20GMT+2>, Till Straumann
> wrote: 
>> The client is V2, not V3. 
> 
> Thanks for clarification, this explains why its necessary to enable a 
> legacy mode on one NFS server to be able to work with RTEMS clients. 
> 
>> 
>> We have a low-priority project to add V3 but having a low priority I'm 
>> not sure if or when it's going to happen... 
> 
> Another option would be to port the FreeBSD NFS client to RTEMS. For 
> this we need a FreeBSD kernel file system layer to RTEMS file system 
> layer adaptor. 
> 
>> 
>> - Till 
>> On 06/10/2016 05:20 AM
> <http://airmail.calendar/2016-10-06%2005:20:00%20GMT+2>, Sebastian Huber
> wrote: 
>>> Hello, 
>>> 
>>> I imported a snapshot of the standard RTEMS NFSv3 client from Till 
>>> Straumann to the libbsd (the new network stack). The RPC deamon uses 
>>> a kqueue() instead of RTEMS events for synchronization. The zero-copy 
>>> optimization by means of direct usage of mbufs is currently not 
>>> available due to a lack of time and budget. 
>>> 
> 
> -- 
> Sebastian Huber, embedded brains GmbH 
> 
> 
> Heinz
> 
> On 19 January 2017 at 18:37:37, Andrew Johnson (anj@aps.anl.gov
> <mailto:anj@aps.anl.gov>) wrote:
> 
>> Calling all RTEMS developers (Till, Eric, Michael, Heinz): Given the
>> statement below from Red Hat, are there any plans in the works to
>> support NFSv3 or later on RTEMS, or some other modern network filesystem
>> protocol?
>>
>> On 01/19/2017 10:42 AM, Torsten Bögershausen wrote:
>> > But I am afraid that NFS 2 is no longer supported:
>> > <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Storage_Administration_Guide/index.html#ch-nfs>
>>
>> The RTEMS NFSv2 client does talk to our RHEL-7.3 server with the
>> configuration change I posted for Mark, but the VxWorks 5.4.2 NFS client
>> broke somewhere between the RHEL-7.2 and 7.3 servers. VxWorks 5.5 has an
>> NFSv3 client (which is buggy, make sure you get all the available
>> patches) that works OK against a RHEL-7.3 server.
>>
>> The APS now only has *2* production IOCs left running on EPICS 3.13.10,
>> having upgraded the others to Base-3.14.12 and VxWorks 5.5 or 6.9. This
>> solved the NFSv2 issue for VxWorks, but our RTEMS-4.9.2 and 4.10.2
>> systems are still stuck with NFSv2...
>>
>> - Andrew
>>
>> -- 
>> Arguing for surveillance because you have nothing to hide is no
>> different than making the claim, "I don't care about freedom of
>> speech because I have nothing to say." -- Edward Snowdon

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

References:
Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Mark Rivers
Re: Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Torsten Bögershausen
RE: Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Mark Rivers
Re: Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Ralph Lange
RE: Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Mark Rivers
Re: Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Torsten Bögershausen
Re: Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Andrew Johnson
Re: Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Heinz Junkes

Navigate by Date:
Prev: Re: Emulating the use of Global VxWorks Variables in OSI Andrew Johnson
Next: Re: Emulating the use of Global VxWorks Variables in OSI Matt Rippa
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: Re: Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Heinz Junkes
Next: Re: Problem NFS mounting Centos 7 file systems from vxWorks 5.5 Jörn Dreyer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 14 Feb 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·