77 replies to this topic

[delavega]

Other images crashes too when the share was previously connected but it isnt anymore?

[Erik Slagter]

It has nothing to do with the image bit with the linux kernel.

[delavega]

so small chances for a fix

[Erik Slagter]

In other words, not much we can do to really fix the issue.

 

On the other hand, the real problem is the disappearance of the server, not the hanging of the client. Would you expect to be able to remove a real harddisk from your STB, while it is on and running, without consequences?

[delavega]

what if you can add in network settings "unmount" like we have "mount again"

[Rob van der Does]

On the other hand, the real problem is the disappearance of the server, not the hanging of the client.

Nope; the 'disappearance' of the client can be due to all kinds of reasons (e.g. temporarily network anomalies), and is not a real problem at all. The 'hanging client' on the other hand is indeed a problem.

[Erik Slagter]

I mean the CAUSE of the problem. And see my other comment. Nobody expects to be able to remove a physical harddisk from a device while the device is on and running.

[MiLo]

I mean the CAUSE of the problem. And see my other comment. Nobody expects to be able to remove a physical harddisk from a device while the device is on and running.

That's actually what you do when you pull out a USB stick...

[littlesat]

When someone knows or can point us to a good fix when mounts are going down.... Then in can be implemented...

[Erik Slagter]

I mean the CAUSE of the problem. And see my other comment. Nobody expects to be able to remove a physical harddisk from a device while the device is on and running.

That's actually what you do when you pull out a USB stick...

Of which we all know it isn't supposed to work without unmounting it first, either.

[Erik Slagter]

When someone knows or can point us to a good fix when mounts are going down.... Then in can be implemented...

Yeah, I guess that person can be rich.

[Sjaaky]

We all know the fallacies of network/distributed computing. Just stating that it shouldn't happen, doesn't make the problem go away.

[SpaceRat]

Just stating that it shouldn't happen, doesn't make the problem go away.

However that's the Linux way to "solve" problems.

[Rob van der Does]

OK, just done the following 2 tests on two boxes on VIX; box 1 has an internal HDD; box 2 has an 'autofs' mount to that HDD.

 

1- Box 2 was booted without LAN-cable connected. Obviously the movie-list of box 1 was not available.

After connecting the LAN-cable (while E2 was alive) the movie-list did contain the files of box 1.

 

2- On box 2 I played back a file from box 1. During playback I disconnected the LAN-cable. Obviously playback stopped, and spinners showed. During this 'spinning I reconnected the LAN-cable and playback resumed by itself.

[Erik Slagter]

We all know the fallacies of network/distributed computing. Just stating that it shouldn't happen, doesn't make the problem go away.

There are simply two choices:

 

- assume the other end will come back "sometime" and wait for that (which has always been te linux kernel approach)

- assume the other won't come back, drop the write behind cache and accept the data inconsistency (meta data will be more or less okay) (comparable to what happens when you unplug an usb disk while it is mounted, although there will be no danger for inconsistent filesystem metadata aka foobar filesystem).

 

I guess for a stb the second option would be acceptable. The linux kernel guys have overruled this choice though, so I guess there is not much we can do (other than patch our kernels ourselves, do I hear a volunteer?).

 

It's not simple lameness like you suggest.

[MiLo]

One real solution I can see is to have E2 handle all protocols itself, i.e. E2 implements the Samba, NFS and whatever other protocols. The "service" objects in E2 were obviously sort of designed with something like this in mind, which explains all the virtual mumbojumbo methods. One could start with simple HTTP sharing between boxes (HTTP can be used to read parts of files and similar things needed to play recordings) and add protocols until they're all working.

Problem with that approach is that it's a ton of work, even with the help of existing NFS userspace and Samba libraries.


Another path is to use autofs directly from E2. That is, directly handle the kernel messages and don't bother with the horrible autofs userspace part. This will not completely solve it, but will take away the most obvious fault paths and prevent most hangups by offering the user a way out when a mount can't be restored. I already looked into this, but the main problem is that I couldn't figure out what the interface from the kernel was. Only way to do so is probably to reverse engineer the existing autofs tools.

[MiLo]

1- Box 2 was booted without LAN-cable connected. Obviously the movie-list of box 1 was not available.
After connecting the LAN-cable (while E2 was alive) the movie-list did contain the files of box 1.
2- On box 2 I played back a file from box 1. During playback I disconnected the LAN-cable. Obviously playback stopped, and spinners showed. During this 'spinning I reconnected the LAN-cable and playback resumed by itself.

Yeah, that works. With or without autofs. To get the living room box to respond again in a lost connection to server situation, I had to boot a random other box and offer the expected share at the expected IP address. Only that made the living room machine resume duty again.

The trouble is that we would want to prevent those spinners from appearing at all. Or at least, have some way of getting the box back under control without leaving the couch.

[delavega]

The trouble is that we would want to prevent those spinners from appearing at all. Or at least, have some way of getting the box back under control without leaving the couch. 

 exactely!