I’m getting increasingly fed up with my Drobo FS. I’m getting close to dumping the damn thing.
Right now it’s sitting there, activity light blinking like mad, yet there’s no IO from the one system that’s got it mounted. The dashboard says all is fine. Yet, a simple directory open on my Mac takes several minutes.
What is it doing? Is someone accessing it from outside? How can I tell? Why doesn’t the dashboard give you some clue as what is going on? If I knew it was doing some sort of reorg or check, I’d relax.
If it is doing some kind of housekeeping, why doesn’t it suspend when it has real work to do.
I can’t agree more - for something like the DroboFS, simply getting a little blinky light is pretty poor feedback, and as you’ve noticed the Dashboard isn’t helping any. I’d unmount it from all computers and see if the activity stops - at least then you’ll know if it’s being initiated by a computer versus some internal process.
Can I just pull the network plug? I started a copy of 107MB which has taken an hour so far and is only halfway through.[hr]
Well, I finally stopped the backup, and ejected the drobofs. Still activity. Pulled the networklink from the back of the drobo, no activity light. Does this mean someone is accessing my drobo from outside?.
Do you have fuppes, firefly, mindlna, or any other media server DroboApp on you FS? Do you have any iPod, iPad, Apple TV, XBMC client, MythTV client, Windows 7 machine on your network? Any of those might be connecting to your FS and indexing its content in the background.
If you really, really want to figure out where the activity is coming from, a way to figure out is to SSH to your FS and type:
netstat -anp
This will show all processes listening for connections and which connections are currently open. For example, on mine I see something like this:
[quote]Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN 500/unfsd
tcp 0 0 0.0.0.0:548 0.0.0.0:* LISTEN 358/afpd
tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 256/nasd
tcp 0 0 0.0.0.0:5001 0.0.0.0:* LISTEN 256/nasd
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 336/smbd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 336/smbd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 497/portmap
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 26198/lighttpd
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 26198/lighttpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 9615/sshd
tcp 0 0 192.168.10.27:2049 192.168.10.34:57446 ESTABLISHED 500/unfsd
tcp 0 0 192.168.10.27:2049 192.168.10.21:56010 ESTABLISHED 500/unfsd
(… a bunch more like these two above …)
netstat: /proc/net/tcp6: No such file or directory
udp 0 0 0.0.0.0:2049 0.0.0.0:* 500/unfsd
udp 0 0 0.0.0.0:137 0.0.0.0:* 334/nmbd
udp 0 0 0.0.0.0:5002 0.0.0.0:* 256/nasd
udp 0 0 0.0.0.0:111 0.0.0.0:* 497/portmap
[/quote]
What can you see from that? First, there are servers for SSH (port tcp:22), NFS (ports tcp:2049 and udp:2049), SMB (windows file sharing, ports tcp:139, tcp:445, and udp:137), AFP (apple file sharing, port tcp:358), lighttpd (ports tcp:80 and tcp:443, for https), and NASD from DRI (ports tcp:5000, tcp:5001 and udp:5002).
But what is interesting is the stuff in the middle. Whenever you see a line with ESTABLISHED, that means an active connection to your FS. In my case, you can see that the FS (with IP 192.168.10.27) has a bunch of connection from my laptop (with IP 192.168.10.34) on the NFS server port. Device 192.168.10.21 is also connecting to the FS on the NFS port, and that one is my wife’s laptop.
If you want, you can copy/paste the output of netstat and we can have a look at it.
In all the systems I’ve seen to this day, communication between internal processes will never cause the network activity light to blink. Network traffic between processes should never even reach the network interface, since they are usually handled at the software stack level.
Even then, unless the OP has MySQL and some PHP app running on top of that, as far as I know none of the DroboApps connects to another DroboApp on the same device.
I’m not sure what you mean. If you mean closing the server’s port (i.e. the entries that say LISTEN), that is pretty much impossible. The port must remain “open” for the server to receive incoming connections.
If you mean active connections (i.e. the ones that say ESTABLISHED), technically you can send a specially crafted packet that will terminate the connection, but I don’t think it is wise to do so. If an application is using TCP is usually because it requires the persistency that TCP offers. If you start breaking established TCP connections in the middle of transfers, who knows what kind of inconsistencies it can cause.
My advice is: if you don’t want open connections, then shut down the services. If the client allows you to control the number of active connections, then try to configure it to connect only when necessary. Otherwise, it is not really safe to break TCP connections like that.
But if you don’t mind me asking, why exactly do you want to do that in the first place?
