[Doktor-X]

i have quastion about nfs mount method's, so what is difference if i mount my nfs share's "directly" using autostart.sh methode e.g.

mount -t nfs 192.168.1.2:/e /storage/HD -o nolock

and using xbmc gui e.g.

Videos->Files->Add Videos...->Browse->Network Filesystem (NFS)

[popcornmix]

The first uses built in kernel support for nfs. The second uses a library built as part of xbmc.

The first allows you to tune parameters. For example mounting with:

Code:

sudo mount 192.168.1.2:/HD -o _netdev,nfsvers=3,rw,intr,noatime,rsize=32768,wsize=32768,nolock,async,proto=udp /storage/HD

will likely give much better performance. This tuning is not possible from xbmc gui.

[doug]

May I ask a silly follow-up question as I've never used a symlink...

Would something as simple as:

Code:

ln -s 192.168.1.2:/HD /storage/HD

enable xbmc to see the original path to a file (e.g., 192.168.1.2/HD/movie.mkv instead of /storage/HD/movie.mkv) for the purpose of having consistent thumbnail names across RBP, Linux, and Windows?

[nickr]

No

[Milhouse]

Would something as simple as:

Code:

ln -s 192.168.1.2:/HD /storage/HD

enable xbmc to see the original path to a file (e.g., 192.168.1.2/HD/movie.mkv instead of /storage/HD/movie.mkv) for the purpose of having consistent thumbnail names across RBP, Linux, and Windows?

No, because it would need to be something like "ln -s nfs://192.168.1.2/HD/movie.mkv" and with the nfs:// prefix it's no longer a valid local file system file name so you won't be able to create the symbolic link. However you might be able to solve that problem with Path_substitution (wiki).

Another advantage of OS mounts is that you can change the server details (for example if migrating data from an old server to a new server) or change the protocol (from CIFS to NFS) without impacting the media library database, simply by changing the mount details, as the mount point never needs to change.

A minor disadvantage when using OS NFS mounts is that if the NFS server is rebooted, the NFS mounts can become stale (inaccessible) whereas XBMC NFS mounts are established only when required, so tend to suffer from this problem much less (if at all).

An advantage of XBMC mounts is that you use a consistent path for all devices - depending on OS, you may not be able to create the same OS mount point you used on another machine with a different distribution (for example with OpenELEC, you can't create a mount point in /mnt which is a location often used by other Linux systems - all your mount points have to go in /storage).

On the other hand, I've experienced far more problems with XBMC NFS mounts than OS NFS mounts, with XBMC NFS mounts randomly unable to STAT files etc. (temporarily unable to play media, or scraping in garbage to the media library), so I now use OS NFS mounts exclusively (udp rather than tcp for better performance).

[doug]

However you might be able to solve that problem with Path_substitution (wiki).

Thanks, I'll give that a try next week (currently on the road) and report back for others. I think it's a useful thing because my HTPC with an SSD is *much* better at thumbnail generation. So copying the Thumbnail directory is really nice.

Edit/update:
Using path substitution worked, but I didn't perceive any benefits.

[Milhouse]

So copying the Thumbnail directory is really nice.

Well if you're going to do that, don't forget to copy the Textures13.db file.

Personally I wouldn't recommend path substitution or copying where thumbnails are concerned, particularly when you are mixing clients with different performance characteristics. Pre-loading the texture cache is a more reliable solution and just as easy to automate.

[azrael17]

Also, if you have certain devices OS mounts can be extremely difficult. I have several android tablets and had to go with XBMC mounts because OS mounts in android wouldn't work properly.

[doveman2]

The first uses built in kernel support for nfs. The second uses a library built as part of xbmc.

The first allows you to tune parameters. For example mounting with:

Code:

sudo mount 192.168.1.2:/HD -o _netdev,nfsvers=3,rw,intr,noatime,rsize=32768,wsize=32768,nolock,async,proto=udp /storage/HD

will likely give much better performance. This tuning is not possible from xbmc gui.

I've been having trouble with XBMC restarting, which might be linked to accessing XBMC NFS mounts, so I thought I'd try this instead.

I'm running OpenElec (rbej's Gotham build) and don't need to use sudo. It rejected _netdev as an invalid option, so I omitted that and used

mount 192.168.1.64:/Media -o nfsvers=3,rw,intr,noatime,rsize=32768,wsize=32678,nolock,async,proto=udp /storage/NFS-Media

/Media is the only export I've set up in Hanewin NFS and it's set to

e:\Media -readonly -public -name:Media

Should this still work OK without the _netdev option?

[Milhouse]

Should this still work OK without the _netdev option?

OpenELEC doesn't support _netdev (or sudo), and you should be able to access NFS using the settings above. I use the same settings with OE 3.1.3 (Frodo) and have no problems with a FreeNAS 8.3.1 server.

[doveman2]

Should this still work OK without the _netdev option?

OpenELEC doesn't support _netdev (or sudo), and you should be able to access NFS using the settings above. I use the same settings with OE 3.1.3 (Frodo) and have no problems with a FreeNAS 8.3.1 server.

Thanks. So to automount like this, I just need to put this in autostart.sh but where should this file go with OE (Gotham but I don't suppose it's any different)?

[Milhouse]

Same in Frodo and Gotham: /storage/.config/autostart.sh

Not sure if it's still required with Gotham, but you may want to make sure the network is up before mounting your network shares - this is my autostart.sh which works with both Frodo and Gotham:

Code:

#!/bin/sh

# Wait for the network to come up...
while [ -z "$(connmanctl state | grep State | grep -E "ready|online")" ]; do sleep 0.25; done; logger -t "$(basename $0)" "** Network is up **"

[ ! -d /storage/freenas ] && mkdir /storage/freenas
[ ! -d /storage/data ]    && mkdir /storage/data
NFSOPTS=nfsvers=3,rw,intr,noatime,rsize=32768,wsize=32768,nolock,async,proto=udp
mount -t nfs 192.168.0.3:/mnt/share /storage/freenas -o $NFSOPTS &
mount -t nfs 192.168.0.3:/mnt/share/data  /storage/data -o $NFSOPTS &

[doveman2]

Thanks, that sounds like a good idea

I don't have -t in my command currently, is that important?

Also, does the NFS path, need to be set to rw in Hanewin or is it OK to set -readonly there and then use ro in the command instead of rw?

EDIT: I think I've answered the first question myself as I mounted with and without -t nfs and mount shows they're identical

192.168.1.64:/Media/ on /storage/NFS-Media type nfs (rw,noatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,nolock,proto=udp,port=2049,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.1.64)
192.168.1.64:/Media/ on /storage/NFS-Movies type nfs (rw,noatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,nolock,proto=udp,port=2049,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.1.64)

so it seems to realise it's a nfs mount from the other options specified.

[Milhouse]

Yes, -t is important as it tells mount what type of filesystem you are mounting (in this case, nfs).

I don't know anything about Hanewin, but a read-only filesystem should be OK - you're only reading the media, right? In that case you might also want to change rw to ro in NFSOPTS.

[doveman2]

Yes, -t is important as it tells mount what type of filesystem you are mounting (in this case, nfs).

I don't know anything about Hanewin, but a read-only filesystem should be OK - you're only reading the media, right? In that case you might also want to change rw to ro in NFSOPTS.

Thanks, I figured it should be OK and that it's only reading but thought I'd better check.