Recently active problems in Wuala tagged with nfs

linux client: built-in NFS server fails with "cannot create file: unknown error 526" when copying a file with 2097197226 bytes to ~/wuala/...

Client version: v119, quota 3GB, fstab entry:
localhost:/wuala /home/[username]/wuala/direct nfs defaults,users,noauto,rsize=8192,wsize=8192,timeo=14,intr,nolock,soft,nfsvers=3,mountvers=3,port=26184,mountport=26183

Double-clicking at the exact same file on the windows (GUI) client I get "The file has not been completely uploaded. Please try again later or contact its owner".

So it's maybe just an issue with user interaction / timeout: the file is requested to be uploaded but that just takes a while, and the OS tries to tell the user that it hasn't arrived yet. Is that the correct interpretation? Could that be fixed / clarified? I took the fstab entry from your FAQ, so don't blame me for the timeout value :-)

I'm using wualacmd under CentOS and I'm having problems accessing a file on this host (it seems to work fine from others).

When I try to cat the file from the NFS mount I get error "Input/output error" and in the client a few seconds later it gives "Wuala>Problem: java.io.FileNotFoundException: /home/wuala_mnt/wuala/wuala/Data/Local2/Large/979CAC0490BD16645B30A41ADA4671554AF0FF6C"

The file causing this is http://wua.la/Linux+Updates/CentOS/5/... (which is in my public group).

Chris.

On a Hardy Ubuntu Linux (32bits), using NFS, I got a lot of exceptions when copying some files from my hard disk to the NFS mount point.

com.wuala.domain.meta.storage.transaction.exception.TransactionExecutionException: java.lang.Exception: com.sleepycat.je.DeadlockException: (JE 3.2.68) Lock expired. Locker 30912987_pool-1-thread-56_Txn: waited for lock on database=stampIndices node=205323092 type=READ grant=WAIT_NEW timeoutMillis=500 startTime=1218039419060 endTime=1218039419561
Owners: [<lockinfo type="WRITE">]
Waiters: []

at bL.c.c(Z:425)
at bL.c.b(Z:415)
at bL.f.ym(Z:86)
at bL.m.ym(Z:142)
at bL.m.doRun(Z:110)
at aA.d.run(Z:35)
Caused by: java.lang.Exception: com.sleepycat.je.DeadlockException: (JE 3.2.68) Lock expired. Locker 30912987_pool-1-thread-56_Txn: waited for lock on database=stampIndices node=205323092 type=READ grant=WAIT_NEW timeoutMillis=500 startTime=1218039419060 endTime=1218039419561
Owners: [<lockinfo type="WRITE">]
Waiters: []

at com.wuala.common.rmi.exception.RemoteException.discardSleepy(RemoteException.java:62)
at com.wuala.common.rmi.exception.RemoteException.<init>(RemoteException.java:34)
at com.wuala.common.rmi.exception.RemoteException.<init>(RemoteException.java:30)
at com.wuala.server.meta.domain.workers.AbstractCommitter.run(AbstractCommitter.java:109)
at com.wuala.server.meta.service.frontend.MetaServer.run(MetaServer.java:288)
at com.wuala.server.meta.service.frontend.MetaServer.commitTransaction3(MetaServer.java:203)
at com.wuala.domain.meta.storage.server.messages.CommitTransaction3Ping.run(CommitTransaction3Ping.java:58)
at com.wuala.server.common.rmi.mina.PingPongIoHandler.runPing(PingPongIoHandler.java:219)
at com.wuala.server.common.rmi.mina.PingPongIoHandler$1.doWork(PingPongIoHandler.java:200)
at com.sleepycat.collections.TransactionRunner.run(TransactionRunner.java:229)
at com.wuala.server.common.database.util.WualaTransactionRunner.run(WualaTransactionRunner.java:24)
at com.wuala.server.common.rmi.mina.PingPongIoHandler.handlePing(PingPongIoHandler.java:198)
at com.wuala.server.common.rmi.mina.PingPongIoHandler.messageReceived(PingPongIoHandler.java:129)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:569)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:647)
at com.wuala.server.common.rmi.mina.FastExecutorFilter.processEvent(FastExecutorFilter.java:171)
at com.wuala.server.common.rmi.mina.FastExecutorFilter$ProcessEventsRunnable.run(FastExecutorFilter.java:216)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)</init></init></lockinfo></lockinfo>

Unter osx (10.5 aktuell) sind Dateien im nfs-mount die Umlaute oder Sonderzeichen enthalten tote links. Man kann auf die nicht direkt üas nfs-volume zugreifen.

.. Die Dateien werden mit ihrem Namen bis zum Umlaut angezeigt und "verschwinden" bei einem Klick drauf.

Und debian werden die Umlaute oder Sonderzeichen zwar als Fragezeichen angezeigt, aber man kann trotzdem zugreifen.

Ich bin mir jetzt nicht sicher, ob das ein osx-Problem ist mit allen nfs-volumes ist. Ich hatte nur den Eindruck, dass es ein paar Versionen früoch nicht so war. Da kann ich mich aber komplett irren. :D

At first glance, Wuala seems to work okay with 'rsync'.

However, I can't get it working with "rdiff-backup". I keep getting the "Stale NFS file handle" error. Are you aware of this problem and when will it be fixed?

Software Management under openSUSE's YaST pops up a warning that says "Warning: disk space is running out!" It says I have used 4.0 TB of 4.0 TB in /home/bmccann/wuala/direct. It also lists that path as being full when I am in the actual software management screen.

Hi,
I am running wuala at linux with NFS filesystem integration. When I use "rm file" at a groups folder at the NFS mount, the file gets removed from the group thogh I am missing the rights in that group.

PS: This "We've estimated the likelihood of your problem getting noticed", "Get emotional! Describe how this topic makes you feel." thing is just silly :P

Wollt nur mal saachen, mein syslog meldet bei Listingabfragen relativ oft:

Apr 10 09:29:37 localhost kernel: nfs_update_inode: inode number mismatch
Apr 10 09:29:37 localhost kernel: expected (0:12/0x3cc6193d), got (0:12/0x104b007b)

Der Fehler scheint aber keine weiteren Probleme zu verursachen. Mir sind zumindest keine aufgefallen. Eine kleine googelei ließmich üolgende Aussage stolpern:
++snipp1
Now I think I can see where the problem originates from: nfs-server
does vfs_getattr() from encode_fattr3(), but it doesn't check the
return value. So if getattr() fails, the attributes (including the
inode numebr) will be bogus.

I'll ask the NFS maintainer about this.
++snapp
++snipp2
I think there may be a second, similar bug. Over NFS, a typical
sequence on the client is:

OPEN
WRITE
CLOSE

On the server, this looks like:

OPEN
WRITE
FSYNC
RELEASE

The kernel nfsd doesn't use FLUSH, and the FSYNC is used to make the
write stable. However, there seems to be a bug in the nfsd where if
the WRITE succeeds, but the FSYNC fails, the client is incorrectly
told the stable write succeeded. For example, see the call to fsync()
in nfsd_dosync() which is called via nfsd_sync() in nfsd_write(). The
return code of fsync() isn't checked.
++snapp

Weis nicht ob das Problem wirklich wichtig ist oder ob die Problemlögsansäe helfen. Die Geschichten sind nicht meine Baustelle. :D

Ich wollte es nur mal mitteilen..

Die fehlermeldungen sehe ich sowohl unter darwin 10.5.2 als auch unter debian sarge aktuell