Hi,

This is probably a really quick one for those who know what they are doing. However for lesser mortals like myself I'm not sure how to proceed.

I finally got my LinHES box to automatically mount my video share from my freenas server as an NFS share. I also managed to get mythwelcome (following RacerX's howto) to work. For me mythwelcome is important as it means saving energy. In the same vein my freenas box has wake up period and a shutdown period.

If I am recording a tv show and the nfs share is mounted and the share goes dead, for example the freenas box enters a shutdown period, when mythwelcome shuts LinHES down, it cannot unmount the share and hangs.

Is there a way around this? Or rather I am sure there is a way around this, can anyone help me with this?

Thanks

t

_________________
Version:R8
Intel C2D 7400, Nvidia 5600 via HDMI to Samsung B37B650TW (PAL), Asus P5QL-E mobo, 4Gb PC6400 DDR2 ram, Samsung Spinpoint 500 Gb & 1Tb drive, Nova-HD-S2 (x2)

This is something NFS is famous for.
If hard mounts are used, the nfs client will hang forever until it gets a response from the nfs server.
Soft mounts are a little more forgiving, but run the risk of data loss and frankly are not that much better.

I'm in the same boat as you. Where to put my stuff? Samba has been good for a long time,,,,,,,,

Hi jams,

So there is no real solution to this then? Either the risk of data loss or hanging forever...

Is there a better way to enable access to a centralised network media store?

_________________
Version:R8
Intel C2D 7400, Nvidia 5600 via HDMI to Samsung B37B650TW (PAL), Asus P5QL-E mobo, 4Gb PC6400 DDR2 ram, Samsung Spinpoint 500 Gb & 1Tb drive, Nova-HD-S2 (x2)

I am not 100% sure but using autofs might work for you. I used autofs in v7.x but I have not set it back up in R8.

The data problem occurs only when writing data and the nfs server goew away. If your doing readonly then using soft shouldn't be a problem.

There really isn't a whole lot that can be done, other then making sure your NFS server doesn't shutdown while it's in use.

hi,

Been away over the weekend... autofs sounds interesting.

I've looked at the page on the ArchWiki and as I am not a linux guru of something, I got lost somewhere...

Can someone help me decipher what I need to do.

I'll go and have a poke on my media centre and see what I can see.

Thanks brfransen for that idea.

Chris

_________________
Version:R8
Intel C2D 7400, Nvidia 5600 via HDMI to Samsung B37B650TW (PAL), Asus P5QL-E mobo, 4Gb PC6400 DDR2 ram, Samsung Spinpoint 500 Gb & 1Tb drive, Nova-HD-S2 (x2)

This has a good step-by-step for setting up autofs, but you'll find it won't resolve the problem. I just setup autofs for an NFS share on a test machine, then shutdown the NFS server while copying a large number of files to it. 45 minutes later it still hasn't errored on the copy. As jams stated, this is an inherent issue with NFS clients and the only real solution is to keep your NAS up 24/7.

Thanks for the additional info slowtolearn. Looks like I'll just have to live with this issue.

Thanks for the information.

_________________
Version:R8
Intel C2D 7400, Nvidia 5600 via HDMI to Samsung B37B650TW (PAL), Asus P5QL-E mobo, 4Gb PC6400 DDR2 ram, Samsung Spinpoint 500 Gb & 1Tb drive, Nova-HD-S2 (x2)

There's always Samba as another alternative

Indeed, but the same problem exists when accessing a CIFS mount and that server shuts down - Control is not handed back to the client in a timely (if ever) manner. mount.nfs and mount.cifs both allow for the intr/nointr (although the mount.cifs man page claims these are currently unimplemented) and hard/soft mount options, but in my testing those appear to only allow manual intervention of a stalled I/O operation on a defunct mount.

What about when samba runs as service?

I'm not sure I follow. On the NAS in question Samba is running as a daemon ("service"). If you mean Samba running as a daemon on the client machine (the Myth box writing the recordings to the NAS in tophee's question) that doesn't matter, as the problem lies in the mount options and I/O operations on the client, the Samba services themselves are not interacting between the two machines.

With either NFS or Samba (CIFS) there doesn't seem to be a signal to let the client I/O operations abort when the mount becomes defunct (the NAS shuts down, or stops the NFS/Samba daemon, network between the two fails, etc.), they keep retrying forever. Or, the signal does get sent but the client doesn't receive/recognize it.

I personally use NFS over Samba for a few reasons, one of which is that in my testing I was able to consistently abort I/O ops with Ctrl-C if the NFS mount "died", but could not do the same reliably using CIFS. I tried autofs when I saw brfransen mention it because I was hopeful that it would trigger the signal and allow the client to abort without manual intervention, but it did not in my testing.

So, as far as I am aware, the only way to reliably deal with a remote mount is to make sure it stays available (ie. Don't let the NAS shutdown).

I think it needs a different approach

Here is a suggestion
Linhes R8 FE/BE -MythWelcome









On the Server

Create a user mythtv









Install XBMC

Setup

Xbmc/Video/Files\Add Video

On Linhes R8 lauch XMBC
/Video/ Files/ Add Video and connect to video share on the server

Access the share via XBMC. If you run XMBC and the server is not available it will generate an error (can't connect) but you can click on the message and clear it.

This still does not address tophee's concern (and there's no reason to install Samba on the LinHES machine unless you want to share directories from it):

Any client attempting initial access to an inactive share should error out and return ("client" here would refer to the attempt to mount the unavailable NFS share), the problem being discussed here is when the client machine accesses an active share, begins I/O operations on that share, and the share goes dead. In this scenario
A) The NFS/CIFS share was available on the NAS
B) The share was mounted on the client machine
C) I/O ops are currently occurring from the client machine to the mounted share, and...
D) The NAS shuts down, orphaning the mount on the client machine

Now the I/O ops on the client machine are retrying forever so the application accessing the share is "hung".

A quick Google turned up this GitHub project. This portion of the description may allow the application to abort if the share can be successfully unmounted on the client machine:

Haven't tried it myself, but may be worth looking into...

[EDIT]To hopefully clearly differentiate between client "machine" and "application"[/EDIT]