Wondering if anyone can advise me on this, I’m going to be getting my hands on a NAS sometime soon (FreeNAS), and wondered what my best option in OSMC on Pi2 would be for mounting NFS Shares. All videos, highest bitrates are around 15MBps, average is 2-3MBps however. I’ve read through the forums and noticed that some people have been having issues with Kodi’s NFS mount implentation, and the recommended course is to use fstab.
If that’s the case, what options is it best to specify for the mount? It only needs read access, and is for the video files as mentioned above. I’ve seen options similar to the below thrown around, are they suitable?
That thread is possibly getting just a little more technical then perhaps you need .
If you’re lucky, @DBMandrake will chip in here as he has not only NFS knowledge, but more importantly here specific knowledge of getting your media through NFS on OSMC on these platforms. But don’t think he’d disagree too much with this summary:
Don’t use libNFS (entering “nfs://…” URIs into Kodi). [[Edit: Thanks to @TheRookie I’ll qualify that with “Unless you’re sharing your configuration between different Kodi systems and/or libNFS works fine for you anyway” ]].
Do mount the NFS shares manually by entering them in “/etc/fstab”. You will need to create a suitable directory somewhere to mount the share - please don’t create it under “/media/” …
Mount options …
3.1 “noauto,x-systemd.automount” - Debian/Raspbian “magic” to get the filesystem to mount automagically at boot.
3.2 “noatime” - Don’t update the access times on files. This will prevent your “RPi” from trying to write that information back to the NAS. That may cause you issues if you’re accessing the same media with anything else, which uses the file access time to determine whether something has been watched or not. If that’s not an issue to you, it’s probably worth including just because there’s no need for the “RPi” to write that information back. If you are going to set that, there are other options (such as “nodiratime”) which you might also want to add, for consistency.
3.3 “async” - ignore that; that was from an example from a much older system.
3.4 “nfsvers=3” - that will force your NAS and your “RPi” to talk using NFS version 3. If you don’t specify this, if your NAS supports it, you’ll probably use NFS version 4. If you’re running modern “RPi” hardware, and if your NAS does support it, that might work better for you - Try it and see.
3.5 “rsize=8192” (and “wsize=8192”) - That’s a … subject of discussion between myself and @DBMandrake. I’d say (if you’re using modern “RPi” hardware, based on the discussion we’ve been having in the other thread) then do not specify either - let the operating system decide what’s best. @DBMandrake may disagree, but again I don’t think he would disagree with “If you’re interested then try changing it and see what happens”
3.6 “nolock” (and “local_lock=all”) - Disables file locking. Personally I’ve not seen any evidence that the software does any file locking, so I’d say leave those out, purely on the K.I.S.S. principle.
3.7 “retrans=2” - Tweaks one particular part of the NFS protocol; personally I’d leave it out and use the kernel default (typically 2 or 3 anyway).
3.8 “soft” - This affects how errors are handled (… plus some other tweaks we don’t need to worry about …), particularly the NFS server going away. I come from somewhat different a background from @DBMandrake and aren’t used to NFS servers going away . I’d always use hard mounts, but in this case, @DBMandrake is entirely correct and a soft mount is the best option.
3.9 “tcp” - This was also the subject of some discussion, but I believe the consensus was that if you’re running later “RPi” hardware, tcp is what you want; if older then you might want to use udp (in which case you will need to adjust your rsize down to 8192). If you do use NFSv4, you’ll have no choice - that only supports TCP.
3.10 You might want to add “ro”, as you say it is only for read access. That will mount “Read Only” (and also mean you won’t need options such as “noatime”).
That’s just from me; I the believe the team are working on this sort of thing at the moment, so I’m sure at some point there will be an official recommendation as to how to do this; for the moment, that will hopefully give you what you need.
Don’t touch any of this unless you know what you’re doing! Otherwise I’m sure it will be taken care of for you, and doubtless all the nasty details hidden behind some wonderful U.I., by some subsequent update and that will always be the best way to manage it!
(and that “1.”, unless it only shows that in the preview, should of course be “4.” ).
Ah, the first “1.” one then Sorry, I didn’t see how that would be different if you had a shared media library. I guess you mean how would you access that library if it were shared via NFS?
OSMC currently has 2 ways to access an NFS share. One is by entering an NFS URI into Kodi, E.g. “nfs://…”; the other (currently; I’m sure the team will do something about this one way or another) involves mounting the NFS share within the underlying operating system (E.g., “Raspbian”). Those 2 ways are completely different, even though they achieve the same end, and (at least at the moment) it appears one (mounting) is performing much better than the other (NFS URI).
If this isn’t something you need to know about immediately, I’d leave it for the moment. There’s quite an extensive (getting ridiculously ) technical thread elsewhere - @Dilligaf has already kindly linked to it - in which the team state they’re working on this at the moment. So if you can wait then personally I would; I’m sure there will be some resolution in an update soon, and whatever the OSMC team present as the way to access NFS shares it will be the carefully considered and selected best option for these systems.
If you can’t wait, you’ll need to perform some Linux command-line hackery - that’s best avoided unless you’re familiar with that sort of thing (please, if you’re in that situation, don’t just Google for the first article that looks likely - there’s a lot of … inappropriate … information out there!). If you are familiar with that sort of thing, you need to create a suitable mount point then add a line to “/etc/fstab”, using options selected from those above, to mount the share.
Even if the media is on the same computer as one of the Kodi instances, you MUST use a network share path. You cannot use a local file path with MySQL.
If I understand correctly, mounting an NFS share locally means that other devices would have to be able to mount them on exactly the same mount points?
There I’m afraid I can’t help you - I know very, very little about Kodi. But yes, if you’re intending to share the configuration between different devices running Kodi, and if they are on different platforms so you can’t mount the NFS share in the same place on all of them, I would imagine that would give you problems, yes (but I don’t know that - that’s just a guess).
Also a guess, but if you are running your Kodis (?!) on similar platforms, if you could always mount the share in the same place then I’d imagine it wouldn’t be a problem.
Interesting, but I’ll have to let someone who knows Kodi respond to that - have you thought of asking on their forums?
I’m not particularly sure that libNFS is to blame here for poor NFS performance on the Vero 2.
While libNFS isn’t as robust as the kernel based mount, it should still work fine for most use-cases. It seems however, that things are more problematic in Jarvis. I’ve seen reports on Pi that also support this.
It would be interesting if you tried the latest kernel with libNFS. The new Ethernet driver splits RX and TX in to tasklets and uses likely/unlikely() macros which gives us a bit more performance if we are correct (branch prediction). We also have larger RX/TX buffers and more appropriate throttling. The Ethernet driver generates a high number of IRQs, so it’s important we service them as quickly as possible.
@THEM: I invite you to test this experimental kernel. See PM.
I took out the wsize though as I’m not looking to write back to the NFS server.
.
