NFS mounts possible from SqueezeOS (Touch)

[fnad74]

"How can SB reconnect to nfs when it reboots?"

I think we can add the entry to /etc/fstab (I haven't tried yet). Sole problem: if nfs is not present, SB may not boot, unless one uses "nofail" (but this option is buggy, i.e. is ignored, on some distros).

BTW, I have a related question: "How can SB reconnect to nfs when the NFS server reboots?" For me it's a bigger problem: SB almost never reboots, but I plan to shut down my nfs server from time to time. autonfs could be a solution. But there's another problem: what if at some point SB cannot connect, thinks /media/sda1/MyLibrary mount point is empty, thus erases the database? Then it needs to rescan once nfs is recovered... Not very optimal...

I'm in the process of implementing/testing all this. Suggestions from anybody are welcome!

[epoch1970]

If the server goes down on you, you're in serious trouble. The only way around that is not mounting... Use an automounter and dismount when possible, after a short delay like 5 minutes.
Then on the server side, detect if there is a mount or not. Refrain from going down if there is a mount (or other measurable NFS activity). Server unfs3d is slower but easier to monitor. It shows opened files via lsof, when the kernel server does not.
On the client side, you can send a WOL packet to the server within the mount request (using an exec map). Or, slower but more reliable, send wol packets when NFS retries start piling up. Usually the reason for the mount to fail is the server sleeping.

I've been using this kind of setup for a good deal of time on AppleTVs, clients to a linux server. It's been working pretty well. Almost zero lockups. Sequence "try mount>errors>wol>mount" is not fast, but very robust. If you can somehow anticipate the wake of the server in addition to that defensive scheme, you could have a swift system. Beware of the client-side cache, and make sure to set negative caching to 0.
The AppleTv has 256MB RAM, and I had no issue running an automounter and the NFS+WOL monitor on top of it.

Using an automounter will also ease your mounting-at-boot issues, most certainly.

HTH

[mkt]

I got this working. Not sure what was wrong before, but did a factory reset and then:

Inserted USB stick.

Mounted NFS share as /media/sda1

Stopped the server and did a wipe and rescan.

This seemed to work and allowed me to use the NFS mount for the built in server. I only used a few files to test it, but will try with a larger collection to validate the performance delta between an NSF share and local storage.

On the upside 24/96 -5 FLAC played from the share without skipping

I'm trying to do this, too. After a few tries this seems to work. Here are some more details.

I inserted a usb stick in Touch and /media/sda1 appeared mounted.
I made a mount point on the usb stick

mkdir /media/sda1/music

and did an nfs mount there

mount -t nfs -o intr,nfsvers=3,rsize=32768,wsize=32768,hard,tcp,nolock 192.168.1.3:/music/music/24-96 /media/sda1/music

Putting the moint point on the usb lets the Touch write to the usb rather than the nfs share which I prefer to export wo. This seems like a good idea?

Then I restarted the squeezecenter

/etc/init.d/squeezecenter restart

It seems to have scanned and be working.

I mounted a directory of 24/96 and it's playing fine. Any ideas on how the Touch squeezecenter will handle ~50K songs?

[crazyj]

"How can SB reconnect to nfs when it reboots?"

I think we can add the entry to /etc/fstab (I haven't tried yet). Sole problem: if nfs is not present, SB may not boot, unless one uses "nofail" (but this option is buggy, i.e. is ignored, on some distros).

BTW, I have a related question: "How can SB reconnect to nfs when the NFS server reboots?" For me it's a bigger problem: SB almost never reboots, but I plan to shut down my nfs server from time to time. autonfs could be a solution. But there's another problem: what if at some point SB cannot connect, thinks /media/sda1/MyLibrary mount point is empty, thus erases the database? Then it needs to rescan once nfs is recovered... Not very optimal...

I'm in the process of implementing/testing all this. Suggestions from anybody are welcome!

Sorry to drag this up again, but I just found a version of tomato-firmware for my router that allows me to export nfs from the attached router hard disk.

so what became of testing for this? will it retain entries made in fstab, and is it best to use a local usb stick in the touch as the cache point (or sd card) what happens when the sd/usb is removed?

Better yet, is there a way to load all this onto a local usb stick/sd so it will access a remote nfs share when the stick is inserted, but default to the normal SqueezeOS behavior when the local sd/usb is removed?

[crazyj]

Mmmm, maybe I'm just too linux-stupid, but I keep getting "bad file descriptor". Am I mounting the wrong directories? Anyone tried mounting to the SD card?

I'm trying:
mount -t nfs -o intr,nfsvers=3,rsize=32768,wsize=32768,hard,tcp,no lock 192.168.1.150:/music /media/mmcblk0p1/music

also, I don't have a restart command there, just 'reboot' in the 'sbin' directory... have things changed in the operating system?

[crazyj]

I seem to have figured out the host side better. Now I'm trying:

mount -t nfs -o intr,nfsvers=3,rsize=32768,wsize=32768,hard,tcp,no lock 192.168.1.1:/music /media/mmcblk0p1/music

or
mount -t nfs -o intr,nfsvers=3,rsize=32768,wsize=32768,hard,tcp,no lock 192.168.1.1:/mnt/music /media/mmcblk0p1/music

Still with no luck, and keep getting bad file descriptor errors.

I can see 192.168.1.1 exporting /mnt/music with another client program so I know its there.

Can anyone decipher what is happening?