An idea I want to run past you......

 

I want to add NFS version 4 support, and at same time put in a restriction:

 

For disk shares:

- you can export using either NFSv3 or NFSv4

 

For user shares:

- you can export using NFSv4 only

 

I guess my question then is, what is the current state of media players out there regarding NVSv4 support?  That is, will implementing the above break everyone's media player access to server user shares?

 

The reason I want to do this is because NVSv4 adds the concept of a "volatile file handle".  This feature should eliminate all cases of "stale file handle" which can result when accessing user shares via NFS.

Yes! Yes! Please! This would be awesome.

 

Thank you for all the hard work you are putting in it is really appreciated.

I'm ok with it, but is it possible to allow the user to select NFSv3 or v4 for user shares?

 

*edit* and by "ok with it" I mean really excited!

I guess the question to ask is, why not give the option?  That is, allow us to turn NFSv3 on/off for usershares? 

I say do it. There will always be firmware base media player that cant be updated. They are cheap for a reason.

It will be great if added as an option. Not everyone will be able to buy a new streamer if the current one doesn't support NFSv4

I'm ok with it, but is it possible to allow the user to select NFSv3 or v4 for user shares?

 

*edit* and by "ok with it" I mean really excited!

 

I guess the question to ask is, why not give the option?  That is, allow us to turn NFSv3 on/off for usershares?

 

You guys are missing the point.  It is not possible to completely eliminate stale file handles with NFSv3 access to user shares unless you allow your memory usage to grow unbounded.  This is because NFS (and AFP) are brain-dead protocols from the last century.  They both rely on being able to assign a "number" to any file object and have that number forever be associated with that object, even if the object moves around.  In the '80s this was ok because that number was actually the inode number and file systems of the day were able to directly translate to a disk block number and read in the info about the file.  But with stacking file systems and systems where files can migrate (eg from cache drive to array, or from one array to another), NFSv3 and AFP are just not up to the task.

 

In a separate post I'm going to float the idea of eliminating AFP support entirely.  This is because netatalk solves this problem by maintaining a frigging database to perform the "persistent number" to file mapping, and this set up is very fragile.  The time has come to abandon obsolete technology and that includes obsolete protocols.  Do you think Apple wants to drop AFP?  No, they recognize it's severe limitations as well.

I for one would be thrilled to see nfs4 support!

 

But then I don't use a video player any more.

 

I do use nfs for mounting volumes on all my Linux workstations. The stale file handles are a PITA, but with Tom's help I have been able to minimize the issue.

 

bkasten

I say move forward. If people have a nfs 3 player only odds are that it has samba. Worst case people could stay on unraid 5x

The only thing i use NFS for is for an iso repository in xenserver.

 

I tried using it in XBMC but had odd issues where it would play the wrong file all the time and abandoned the idea.

 

AFP is also a PITA and i say that as an apple user, it's really slow to refresh files in finder and i am glad that apple have shifted to samba in mavericks.

Please improve NFS handling even if you have to drop v3.

 

I am currently forced to use CIFS towards several Linux VMs, because NFS has been so unreliable in unRAID.

Yup - upgrade definitely.

 

There's no point in considering making v3 optional if it's going to produce errors. The core platform must always be pushed towards 100% stability IMHO.

Since disk shares can continue to be NFSv3, old players can still be used.

I'm ok with it, but is it possible to allow the user to select NFSv3 or v4 for user shares?

 

*edit* and by "ok with it" I mean really excited!

 

I guess the question to ask is, why not give the option?  That is, allow us to turn NFSv3 on/off for usershares?

 

You guys are missing the point.  It is not possible to completely eliminate stale file handles with NFSv3 access to user shares unless you allow your memory usage to grow unbounded.  This is because NFS (and AFP) are brain-dead protocols from the last century.  They both rely on being able to assign a "number" to any file object and have that number forever be associated with that object, even if the object moves around.  In the '80s this was ok because that number was actually the inode number and file systems of the day were able to directly translate to a disk block number and read in the info about the file.  But with stacking file systems and systems where files can migrate (eg from cache drive to array, or from one array to another), NFSv3 and AFP are just not up to the task.

 

In a separate post I'm going to float the idea of eliminating AFP support entirely.  This is because netatalk solves this problem by maintaining a frigging database to perform the "persistent number" to file mapping, and this set up is very fragile.  The time has come to abandon obsolete technology and that includes obsolete protocols.  Do you think Apple wants to drop AFP?  No, they recognize it's severe limitations as well.

 

AFP is still needed for Time Machine. Hopefully, this will change. There are reports of OS X applications that only work via AFP. I think once Time Machine no longer requires AFP it would be safe to drop support; although, users of the legacy AFP-only applications will complain.

You guys are missing the point.  It is not possible to completely eliminate stale file handles with NFSv3 access to user shares unless you allow your memory usage to grow unbounded. 

 

In that case then yes.  Lets support CIFS and NFSv4 only (not going to comment on AFP).  This way we wont need to troubleshoot a problem that can't be fixed.

Yep in still seeing stale file handlers even on 5.0.5 so I'm def up for the switch over for v6 if it gets rid of this issue once and for all. My main use for nfs is an openelec appliance running xbmc frodo, assuming nfs4 wouldn't break this

 

I don't know how feasible this is, but maybe leave NFS3/AFP in the UnRAID 5.0 stream, and clean them up from 6.0. Since 5.0 shipped with them it makes sense to maintain them in the last 32-bit release, but remove them from the 6.0 release. This way those who need NFS3/AFP still have an option to manage legacy devices, but since 6.0 requires a re-think from the UnRAID server perspective as far as hardware requirements then this updated protocol requirement could just be included as part of each users decision tree on what makes sense for them to move forward.

I don't know how feasible this is, but maybe leave NFS3/AFP in the UnRAID 5.0 stream, and clean them up from 6.0. Since 5.0 shipped with them it makes sense to maintain them in the last 32-bit release, but remove them from the 6.0 release. This way those who need NFS3/AFP still have an option to manage legacy devices, but since 6.0 requires a re-think from the UnRAID server perspective as far as hardware requirements then this updated protocol requirement could just be included as part of each users decision tree on what makes sense for them to move forward.

 

This = best of both worlds.

 

FWIW +1 on NFS v4.

You had me at

The time has come to abandon obsolete technology

You had me at

The time has come to abandon obsolete technology

 

I use WD TV Live SMP's with NFS and Google has not shown problems with NFSv4 from what I have been able to find so I'm good - go for it.  I can always stay with an older version if it is a problem.

I agree about moving on to v4, nothing on my end will suffer compatibility wise.

 

But is there any particular reason that you can't have both sets of drivers? Say it comes with v4-only active by default with a button/flag/plugin that can downgrade the system to v3 if the user decides (with a clear understanding that they can't complain about stale handles)?

(with a clear understanding that they can't complain about stale handles)?

They will still complain.

+1 for dropping v3. If people's equipment doesn't support v4 they'll just have to use samba. I'm also in favor of making this change in unraid version 5 as well as version 6.

I did a test on the Netgear NTV550 media player which is now manufacture discontinued.  The last firmware update (v3.2.27) was in July of 2012 and I can assure you that NO future update will be forthcoming.

 

I have been using NFS as I had problems with SMB when I was running a FreeNAS server with hesitation/stuttering  problems.  Thus, I continued to use NFS when I switched to unRAID simply because it worked without problems. 

 

Because there was some indication that older devices that use NFSv3 might not work with NFSv4, I decided to have a look again at using SMB with the the NTV550.  I can report that in the tests that I did this evening I had no problems whatsoever.  I think the new improvements that have been made in SMB in the past couple of years have gone a long way to reducing extra overhead that caused problems in earlier years. 

 

If my experience is typical, the possibility that NFSv4 may not work with older devices that use NFSv3 could be a non-issue as SMB will work without playback problems.