From: Andriy G. <av...@ic...> - 2006-09-05 09:48:17
|
System: FreeBSD 6.1-RELEASE-p2 i386 fusefs-kmod-0.3.0_2 fusefs-libs-2.5.3 fusefs-sshfs-1.6 Problem: I can save a file in xemacs if file size is larger than a certain value and can not save if it's smaller. The problem seems to happen if file size becomes smaller than its original size (when opened by xemacs) and what is the most the strange is that only xemacs is affected - vim works ok. ktrace/kdump output for both cases follows: 42654 xemacs-21.4.19 CALL open(0xbfbfc760,0x601,0x1b6) 42654 xemacs-21.4.19 NAMI "/home/avg/mnt/ssh/lux/work/controller/trunk/src/oamp/test/cl-test.cpp" 42654 xemacs-21.4.19 RET open 7 42654 xemacs-21.4.19 CALL lseek(0x7,0,0,0,0x1) 42654 xemacs-21.4.19 RET lseek 0 42654 xemacs-21.4.19 CALL write(0x7,0x8a7e000,0x823) 42654 xemacs-21.4.19 GIO fd 7 wrote 2083 bytes ... 42654 xemacs-21.4.19 CALL open(0xbfbfc760,0x601,0x1b6) 42654 xemacs-21.4.19 NAMI "/home/avg/mnt/ssh/lux/work/controller/trunk/src/oamp/test/cl-test.cpp" 42654 xemacs-21.4.19 RET open 7 42654 xemacs-21.4.19 CALL lseek(0x7,0,0,0,0x1) 42654 xemacs-21.4.19 RET lseek 0 42654 xemacs-21.4.19 CALL write(0x7,0x8a7e000,0x822) 42654 xemacs-21.4.19 RET write -1 errno 5 Input/output error It seems that xemacs opens a file before (over-)writing with the following mode: O_WRONLY | O_CREAT | O_TRUNC Maybe this is a problem or the subsequent "new" lseek with offset=0, pad=0 and whence=SEEK_CUR ? -- Andriy Gapon |
From: Csaba H. <csa...@cr...> - 2006-09-08 23:29:38
|
On Tue, Sep 05, 2006 at 12:47:15PM +0300, Andriy Gapon wrote: > Problem: > I can save a file in xemacs if file size is larger than a certain value > and can not save if it's smaller. The problem seems to happen if file > size becomes smaller than its original size (when opened by xemacs) and Thanks for the report. > what is the most the strange is that only xemacs is affected - vim works ok. That's what I find the least strange :) The action of "saving a file" as such can't just be mapped to an unambiguous sequence of syscalls. Therefore I see nothing extraordinary in producing different behavoiurs. Okay. Before I try to do anything about it, please try to answer the following questions: 1) Can you see the error with devel fuse4bsd? 2) Can you see the error with fusexmp_fh (from the fuse distribution, the port doesn't install this example fs)? 3) Do you mean that with your setup, saving a file in xemacs so that it gets shorter is sufficient to trigger the error? 4) Would you please mount the fs with "-d" and send the output? Csaba |
From: Andriy G. <av...@ic...> - 2006-09-11 13:51:56
|
on 09/09/2006 01:08 Csaba Henk said the following: > On Tue, Sep 05, 2006 at 12:47:15PM +0300, Andriy Gapon wrote: >> Problem: >> I can save a file in xemacs if file size is larger than a certain value >> and can not save if it's smaller. The problem seems to happen if file >> size becomes smaller than its original size (when opened by xemacs) and [snip] > Okay. Before I try to do anything about it, please try to answer the > following questions: > > 1) Can you see the error with devel fuse4bsd? > 2) Can you see the error with fusexmp_fh (from the fuse distribution, > the port doesn't install this example fs)? > 3) Do you mean that with your setup, saving a file in xemacs > so that it gets shorter is sufficient to trigger the error? > 4) Would you please mount the fs with "-d" and send the output? Csaba, a quick answer to some of the questions: 3) yes; however now I think that it happens on the second save 4) here goes a small snippet with the error: LOOKUP /xlat.c NODEID: 16 unique: 2, error: 0 (Unknown error: 0), outsize: 136 unique: 0, opcode: OPEN (14), nodeid: 16, insize: 48 OPEN[134613632] flags: 0x1 unique: 0, error: 0 (Unknown error: 0), outsize: 32 unique: 1, error: 0 (Unknown error: 0), outsize: 112 unique: 2, opcode: SETATTR (4), nodeid: 16, insize: 128 unique: 2, error: 0 (Unknown error: 0), outsize: 112 unique: 0, opcode: WRITE (16), nodeid: 16, insize: 4160 WRITE[134613632] 4096 bytes to 0 WRITE[134613632] 4096 bytes unique: 0, error: 0 (Unknown error: 0), outsize: 24 unique: 1, opcode: WRITE (16), nodeid: 16, insize: 4160 . . more successful writes . WRITE[134613632] 4096 bytes to 16384 WRITE[134613632] 4096 bytes unique: 1, error: 0 (Unknown error: 0), outsize: 24 ====================== error is here =================== unique: 2, opcode: READ (15), nodeid: 16, insize: 64 READ[134613632] 3065 bytes from 20480 unique: 2, error: -5 (Input/output error), outsize: 16 ======================================================= unique: 0, opcode: WRITE (16), nodeid: 16, insize: 4160 WRITE[134613632] 4096 bytes to 20480 WRITE[134613632] 4096 bytes unique: 0, error: 0 (Unknown error: 0), outsize: 24 unique: 1, opcode: WRITE (16), nodeid: 16, insize: 4160 WRITE[134613632] 4096 bytes to 24576 WRITE[134613632] 4096 bytes unique: 1, error: 0 (Unknown error: 0), outsize: 24 unique: 2, opcode: WRITE (16), nodeid: 16, insize: 4160 Original file size was 23627 bytes. Complete output is at http://oddity-e.topspin.kiev.ua/sshfs.log I opened a files with xemacs, deleted couple of characters, successfully saved it, deleted couple more characters and tried to save again. As a reminder, here's how ktrace output looked like: 42654 xemacs-21.4.19 CALL open(0xbfbfc760,0x601,0x1b6) 42654 xemacs-21.4.19 NAMI "....." 42654 xemacs-21.4.19 RET open 7 42654 xemacs-21.4.19 CALL lseek(0x7,0,0,0,0x1) 42654 xemacs-21.4.19 RET lseek 0 42654 xemacs-21.4.19 CALL write(0x7,0x8a7e000,0x822) 42654 xemacs-21.4.19 RET write -1 errno 5 Input/output error So, I am not sure why sshfs or libfuse performs a read internally for write(2) and why result of that read is returned as overall operation result. -- Andriy Gapon |
From: Csaba H. <csa...@cr...> - 2006-09-11 21:20:06
|
On Mon, Sep 11, 2006 at 04:50:56PM +0300, Andriy Gapon wrote: > . > . more successful writes > . > WRITE[134613632] 4096 bytes to 16384 > WRITE[134613632] 4096 bytes > unique: 1, error: 0 (Unknown error: 0), outsize: 24 > ====================== error is here =================== > unique: 2, opcode: READ (15), nodeid: 16, insize: 64 > READ[134613632] 3065 bytes from 20480 > unique: 2, error: -5 (Input/output error), outsize: 16 > ======================================================= Oh yeah, gotcha. I think it is the bug which was fixed here: http://mercurial.creo.hu/repos/fuse4bsd-hg/?cs=9131f671c86d This was slightly after the latest release, so the port version is affected by the bug. ----- Sidenote to Anish: ------ I have now a pretty roadmap for the next release. So now I see I won't make it tomorrow (given that I just took a fulltime job...). I wouldn't like to branch the code (in a stable / devel fashion). That would be sort of a PITA, so I don't do that as long as we can get on without it. And I do think we get on without it: I suggest you to add small-but-useful bugfixes -- like the above one or http://mercurial.creo.hu/repos/fuse4bsd-hg/?cs=18f8e6225e93 -- to the port as patches. I think it's not much work for you to do that, and we don't have to fear of side effects in case of these. Would you be as kind as to roll these patches in (and maybe other ones if I/we bump into more of this type)? Please speak up if you see any problem with this approach. TYA. ----------- Csaba |
From: Andriy G. <av...@ic...> - 2006-09-27 14:31:14
|
Csaba, thank you for your help! The change in http://mercurial.creo.hu/repos/fuse4bsd-hg/?cs=9131f671c86d has helped but not entirely — I can now do more saves, but xemacs chokes later although with a completely different error now. ################################################################### Excerpt from xemacs messages: Wrote /home/avg/mnt/ssh/lux/xlat.c Wrote /home/avg/mnt/ssh/lux/xlat.c Finding truename: Interrupted system call, /export/home/avg/mnt/ssh/lux/xlat.c ################################################################### ktrace/kdump leading to this: 21599 xemacs-21.4.19 CALL readlink(0xbfbfc6e0,0x8e56900,0x64) 21599 xemacs-21.4.19 NAMI "/export/home/avg/mnt/ssh/lux/.#xlat.c" 21599 xemacs-21.4.19 RET readlink 32/0x20 21599 xemacs-21.4.19 CALL getpid 21599 xemacs-21.4.19 RET getpid 21599/0x545f 21599 xemacs-21.4.19 CALL unlink(0xbfbfc710) 21599 xemacs-21.4.19 NAMI "/export/home/avg/mnt/ssh/lux/.#xlat.c" 21599 xemacs-21.4.19 RET unlink -1 errno 4 Interrupted system call ⋮ 21599 xemacs-21.4.19 CALL stat(0xbfbfdb50,0xbfbfdbd0) 21599 xemacs-21.4.19 NAMI "/home/avg/mnt/ssh/lux/xlat.c" 21599 xemacs-21.4.19 RET stat -1 errno 4 Interrupted system call ⋮ 21599 xemacs-21.4.19 NAMI "/export" 21599 xemacs-21.4.19 RET readlink -1 errno 22 Invalid argument 21599 xemacs-21.4.19 CALL readlink(0xbfbfd6b0,0xbfbfce00,0x3ff) 21599 xemacs-21.4.19 NAMI "/export/home" 21599 xemacs-21.4.19 RET readlink -1 errno 22 Invalid argument 21599 xemacs-21.4.19 CALL readlink(0xbfbfd6b0,0xbfbfce00,0x3ff) 21599 xemacs-21.4.19 NAMI "/export/home/avg" 21599 xemacs-21.4.19 RET readlink -1 errno 22 Invalid argument 21599 xemacs-21.4.19 CALL readlink(0xbfbfd6b0,0xbfbfce00,0x3ff) 21599 xemacs-21.4.19 NAMI "/export/home/avg/mnt" 21599 xemacs-21.4.19 RET readlink -1 errno 22 Invalid argument 21599 xemacs-21.4.19 CALL readlink(0xbfbfd6b0,0xbfbfce00,0x3ff) 21599 xemacs-21.4.19 NAMI "/export/home/avg/mnt/ssh" 21599 xemacs-21.4.19 RET readlink -1 errno 22 Invalid argument 21599 xemacs-21.4.19 CALL readlink(0xbfbfd6b0,0xbfbfce00,0x3ff) 21599 xemacs-21.4.19 NAMI "/export/home/avg/mnt/ssh/lux" 21599 xemacs-21.4.19 RET readlink -1 errno 22 Invalid argument 21599 xemacs-21.4.19 CALL readlink(0xbfbfd6b0,0xbfbfce00,0x3ff) 21599 xemacs-21.4.19 NAMI "/export/home/avg/mnt/ssh/lux/xlat.c" 21599 xemacs-21.4.19 RET readlink -1 errno 4 Interrupted system call ################################################################### fuse debug output leading to this: unique: 0, opcode: OPEN (14), nodeid: 2, insize: 48 OPEN[134612288] flags: 0x0 unique: 0, error: 0 (Unknown error: 0), outsize: 32 unique: 0, opcode: READ (15), nodeid: 2, insize: 64 READ[134612288] 3705 bytes from 77824 READ[134612288] 0 bytes unique: 0, error: 0 (Unknown error: 0), outsize: 16 unique: 0, opcode: WRITE (16), nodeid: 2, insize: 3586 WRITE[134612096] 3522 bytes to 77824 WRITE[134612096] 3522 bytes unique: 0, error: 0 (Unknown error: 0), outsize: 24 unique: 1, opcode: FSYNC (20), nodeid: 2, insize: 56 FSYNC[134612096] unique: 0, opcode: FSYNC (20), nodeid: 2, insize: 56 FSYNC[134612288] unique: 0, error: 0 (Unknown error: 0), outsize: 16 unique: 0, opcode: RELEASE (18), nodeid: 2, insize: 56 RELEASE[134612096] flags: 0x1 unique: 0, error: 0 (Unknown error: 0), outsize: 16 unique: 0, opcode: RELEASE (18), nodeid: 2, insize: 56 RELEASE[134612288] flags: 0x0 unique: 0, error: 0 (Unknown error: 0), outsize: 16 unique: 0, opcode: LOOKUP (1), nodeid: 1, insize: 47 LOOKUP /xlat.c NODEID: 2 unique: 0, error: 0 (Unknown error: 0), outsize: 136 unique: 0, opcode: LOOKUP (1), nodeid: 1, insize: 49 LOOKUP /.#xlat.c NODEID: 6 unique: 0, error: 0 (Unknown error: 0), outsize: 136 unique: 0, opcode: READLINK (5), nodeid: 6, insize: 40 unique: 0, error: 0 (Unknown error: 0), outsize: 48 unique: 0, opcode: LOOKUP (1), nodeid: 1, insize: 49 LOOKUP /.#xlat.c NODEID: 6 unique: 0, error: 0 (Unknown error: 0), outsize: 136 unique: 0, opcode: UNLINK (10), nodeid: 1, insize: 49 unique: 2, opcode: LOOKUP (1), nodeid: 1, insize: 47 unique: 3, opcode: LOOKUP (1), nodeid: 1, insize: 47 unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 47 unique: 5, opcode: LOOKUP (1), nodeid: 1, insize: 47 unique: 6, opcode: LOOKUP (1), nodeid: 1, insize: 47 unique: 7, opcode: LOOKUP (1), nodeid: 1, insize: 47 Last several lines look very strange — there are only "unique" messages and no reporting from within the operations. I think it is very important to note that ".#xlat.c" file mentioned above is a broken symlink (by design), I think this is how (x)emacs locks a file: .#xlat.c -> av...@od....21599 P.S. regarding your question to Anish I want to make a note that the change http://mercurial.creo.hu/repos/fuse4bsd-hg/?cs=18f8e6225e93 is already present (in a slightly different form) in patch file files/patch-fuse_module_fuse.c as a hunk #19. -- Andriy Gapon |
From: Csaba H. <csa...@cr...> - 2006-09-29 22:10:13
|
On Wed, Sep 27, 2006 at 05:30:20PM +0300, Andriy Gapon wrote: > The change in > http://mercurial.creo.hu/repos/fuse4bsd-hg/?cs=9131f671c86d has helped > but not entirely ??? I can now do more saves, but xemacs chokes later > although with a completely different error now. OK. Investigating the case, I've seen two independent bugs. The first one: one can see a bunch of "Interrupted system call" reports upon doing namei related things (there are some of it in the log you sent, but also xemacs reports it in the minibuffer). This is harmless, albeit harder to fix. It's not clear who generates those interrupts and why. It might be a similar issue to the one Miklos mentioned in connenction with Krusader in this post: http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/2773/focus=2778 I don't see why Xemacs would behave like the KIO system, but heaven knows. This might mean that I have to rewrite interrupt handling in the kernel module, like Miklos did it on Linux when he was hit by the Krusader bug. All in all, I don't yet know what to do about it. * * * The second one: that was a bug in sshfs (which made it segfaulting). Now it's fixed, see it, eg. in my Mercurial mirror: http://mercurial.creo.hu/repos/sshfs-hg/?cs=97fc7e353ddc Csaba |
From: Andriy G. <av...@ic...> - 2006-10-02 12:03:47
|
Csaba, Miklos, thank you for the update and the patch. I am testing it now. Meanwhile here's another low-priority/minor-annoyance problem specific to (x)emacs. XEmacs message: Cannot write backup file; backing up in ~/%backup%~ sshfs stdout: unique: 0, opcode: LOOKUP (1), nodeid: 1, insize: 48 LOOKUP /xlat.c~ NODEID: 5 unique: 0, error: 0 (Unknown error: 0), outsize: 136 unique: 0, opcode: GETATTR (3), nodeid: 5, insize: 40 unique: 0, error: 0 (Unknown error: 0), outsize: 112 unique: 0, opcode: LOOKUP (1), nodeid: 1, insize: 47 LOOKUP /xlat.c NODEID: 2 unique: 0, error: 0 (Unknown error: 0), outsize: 136 unique: 0, opcode: LOOKUP (1), nodeid: 1, insize: 48 LOOKUP /xlat.c~ NODEID: 5 unique: 0, error: 0 (Unknown error: 0), outsize: 136 unique: 0, opcode: RENAME (12), nodeid: 1, insize: 63 RENAME /xlat.c -> /xlat.c~ unique: 0, error: -1 (Operation not permitted), outsize: 16 ktrace: 26204 xemacs-21.4.19 CALL stat(0xbfbfd5e0,0xbfbfd660) 26204 xemacs-21.4.19 NAMI "/home/avg/mnt/ssh/lux/xlat.c~" 26204 xemacs-21.4.19 RET stat 0 26204 xemacs-21.4.19 CALL rename(0xbfbfd670,0xbfbfd640) 26204 xemacs-21.4.19 NAMI "/home/avg/mnt/ssh/lux/xlat.c" 26204 xemacs-21.4.19 NAMI "/home/avg/mnt/ssh/lux/xlat.c~" 26204 xemacs-21.4.19 RET rename -1 errno 1 Operation not permitted directory permissions [the first one is the mount point]: $ ls -ld ~/mnt/ssh/lux/ drwxr-xr-x 1 503 504 4096 2 Oct 14:48 /home/avg/mnt/ssh/lux/ $ ls -l ~/mnt/ssh/lux/xlat.c* -rw-r--r-- 1 503 504 93353 2 Oct 14:48 /home/avg/mnt/ssh/lux/xlat.c -rw-r--r-- 1 503 504 23627 5 Apr 15:22 /home/avg/mnt/ssh/lux/xlat.c~ Please note that if I use -o idmap=user I see my user id instead of 503 in ls output, but the behavior of xemacs doesn't change. Simply using mv doesn't work too: $ mv /home/avg/mnt/ssh/lux/xlat.c /home/avg/mnt/ssh/lux/xlat.c~ mv: rename /home/avg/mnt/ssh/lux/xlat.c to /home/avg/mnt/ssh/lux/xlat.c~: Operation not permitted -- Andriy Gapon |
From: Miklos S. <mi...@sz...> - 2006-10-02 12:12:20
|
> thank you for the update and the patch. I am testing it now. > Meanwhile here's another low-priority/minor-annoyance problem specific > to (x)emacs. > > XEmacs message: > Cannot write backup file; backing up in ~/%backup%~ > > sshfs stdout: > unique: 0, opcode: LOOKUP (1), nodeid: 1, insize: 48 > LOOKUP /xlat.c~ > NODEID: 5 > unique: 0, error: 0 (Unknown error: 0), outsize: 136 > unique: 0, opcode: GETATTR (3), nodeid: 5, insize: 40 > unique: 0, error: 0 (Unknown error: 0), outsize: 112 > unique: 0, opcode: LOOKUP (1), nodeid: 1, insize: 47 > LOOKUP /xlat.c > NODEID: 2 > unique: 0, error: 0 (Unknown error: 0), outsize: 136 > unique: 0, opcode: LOOKUP (1), nodeid: 1, insize: 48 > LOOKUP /xlat.c~ > NODEID: 5 > unique: 0, error: 0 (Unknown error: 0), outsize: 136 > unique: 0, opcode: RENAME (12), nodeid: 1, insize: 63 > RENAME /xlat.c -> /xlat.c~ > unique: 0, error: -1 (Operation not permitted), outsize: 16 > > ktrace: > 26204 xemacs-21.4.19 CALL stat(0xbfbfd5e0,0xbfbfd660) > 26204 xemacs-21.4.19 NAMI "/home/avg/mnt/ssh/lux/xlat.c~" > 26204 xemacs-21.4.19 RET stat 0 > 26204 xemacs-21.4.19 CALL rename(0xbfbfd670,0xbfbfd640) > 26204 xemacs-21.4.19 NAMI "/home/avg/mnt/ssh/lux/xlat.c" > 26204 xemacs-21.4.19 NAMI "/home/avg/mnt/ssh/lux/xlat.c~" > 26204 xemacs-21.4.19 RET rename -1 errno 1 Operation not permitted > > directory permissions [the first one is the mount point]: > $ ls -ld ~/mnt/ssh/lux/ > drwxr-xr-x 1 503 504 4096 2 Oct 14:48 /home/avg/mnt/ssh/lux/ > > $ ls -l ~/mnt/ssh/lux/xlat.c* > -rw-r--r-- 1 503 504 93353 2 Oct 14:48 /home/avg/mnt/ssh/lux/xlat.c > -rw-r--r-- 1 503 504 23627 5 Apr 15:22 /home/avg/mnt/ssh/lux/xlat.c~ > > Please note that if I use -o idmap=user I see my user id instead of 503 > in ls output, but the behavior of xemacs doesn't change. > > Simply using mv doesn't work too: > > $ mv /home/avg/mnt/ssh/lux/xlat.c /home/avg/mnt/ssh/lux/xlat.c~ > mv: rename /home/avg/mnt/ssh/lux/xlat.c to > /home/avg/mnt/ssh/lux/xlat.c~: Operation not permitted I think this might be because sshfs doesn't allow renaming to an existing file. Try the '-oworkaround=rename' option. Miklos |
From: Andriy G. <av...@ic...> - 2006-10-02 12:55:59
|
on 02/10/2006 15:11 Miklos Szeredi said the following: > Andriy Gapon said: >> $ mv /home/avg/mnt/ssh/lux/xlat.c /home/avg/mnt/ssh/lux/xlat.c~ >> mv: rename /home/avg/mnt/ssh/lux/xlat.c to >> /home/avg/mnt/ssh/lux/xlat.c~: Operation not permitted > > I think this might be because sshfs doesn't allow renaming to an > existing file. Try the '-oworkaround=rename' option. > Miklos, thanks a lot! I can not believe I overlooked this issue and the option. Now I would like to report another issue that I am having with xemacs, maybe this is something simple too. After I (successfully) save edited (shortened) file for the first time, any subsequent attempts raise the following xemacs messages: xlat.c changed on disk; really edit the buffer? (y, n, r or C-h) File changed on disk: /home/avg/mnt/ssh/lux/xlat.c According to this explanation: http://computing.fnal.gov/docs/products/xemacs/v21_1/lispref.info,.ModificationTime.html xemacs probably sees some file timestamp that it doesn't like/expect. I don't have anything terribly useful in ktrace or sshfs debug output except that FUSE operations leading to the messages are LOOKUPs and GETATTRs. -- Andriy Gapon |
From: Andriy G. <av...@ic...> - 2006-10-02 12:35:27
|
on 30/09/2006 01:07 Csaba Henk said the following: > > The second one: that was a bug in sshfs (which made it segfaulting). Now > it's fixed, see it, eg. in my Mercurial mirror: > > http://mercurial.creo.hu/repos/sshfs-hg/?cs=97fc7e353ddc Csaba, after applying this sshfs change and the FreeBSD fuse patches that you previously suggested, I still sometimes get Input/output errors on save, although somewhat differently. XEmacs produces Input/output error message. In ktrace I see: 26440 xemacs-21.4.19 CALL write(0x7,0x9067000,0x10000) [ ... data ...] 26440 xemacs-21.4.19 RET write 65536/0x10000 26440 xemacs-21.4.19 CALL write(0x7,0x9067000,0x6c4f) 26440 xemacs-21.4.19 RET write -1 errno 5 Input/output error 26440 xemacs-21.4.19 CALL write(0x7,0x9067000,0x6c4f) 26440 xemacs-21.4.19 GIO fd 7 wrote 4096 bytes [ ... data ...] 26440 xemacs-21.4.19 RET write 27727/0x6c4f 26440 xemacs-21.4.19 CALL fsync(0x7) 26440 xemacs-21.4.19 RET fsync 0 26440 xemacs-21.4.19 CALL close(0x7) 26440 xemacs-21.4.19 RET close 0 In sshfs output I see that all writes are successful and there are no I/O error at all: unique: 3, opcode: WRITE (16), nodeid: 4, insize: 4160 WRITE[134612096] 4096 bytes to 0 WRITE[134612096] 4096 bytes unique: 3, error: 0 (Unknown error: 0), outsize: 24 unique: 2, opcode: WRITE (16), nodeid: 4, insize: 4160 WRITE[134612096] 4096 bytes to 4096 WRITE[134612096] 4096 bytes unique: 2, error: 0 (Unknown error: 0), outsize: 24 unique: 1, opcode: WRITE (16), nodeid: 4, insize: 4160 WRITE[134612096] 4096 bytes to 8192 WRITE[134612096] 4096 bytes unique: 1, error: 0 (Unknown error: 0), outsize: 24 . . . unique: 2, opcode: WRITE (16), nodeid: 4, insize: 4160 WRITE[134612096] 4096 bytes to 86016 WRITE[134612096] 4096 bytes unique: 2, error: 0 (Unknown error: 0), outsize: 24 unique: 1, opcode: WRITE (16), nodeid: 4, insize: 3215 WRITE[134612096] 3151 bytes to 90112 WRITE[134612096] 3151 bytes unique: 1, error: 0 (Unknown error: 0), outsize: 24 There are no other operations but WRITEs in this block of messages (i.e. previously there was a problem with READ on write-only file, but now there are no READs). >From what I gather from sshfs debug and ktrace, file/data size was 93263, sshfs/fuse wrote it down in 22 chunks of 4096 bytes plus final chunk of 3151 bytes, all successful. On xemacs level there were only two (actually three) OS writes: one of size 64k and the other with remaining 27727 bytes. For some reason the first attempt to write those 27727 bytes failed or was reported as failed, but there was something like a retry (by xemacs or FUSE lib ?) and it was successful. Still xemacs got Input/output error nevertheless. -- Andriy Gapon |
From: Miklos S. <mi...@sz...> - 2006-10-02 13:16:55
|
> thanks a lot! I can not believe I overlooked this issue and the option. > > Now I would like to report another issue that I am having with xemacs, > maybe this is something simple too. > > After I (successfully) save edited (shortened) file for the first time, > any subsequent attempts raise the following xemacs messages: > > xlat.c changed on disk; really edit the buffer? (y, n, r or C-h) > File changed on disk: /home/avg/mnt/ssh/lux/xlat.c > > According to this explanation: > http://computing.fnal.gov/docs/products/xemacs/v21_1/lispref.info,.ModificationTime.html > xemacs probably sees some file timestamp that it doesn't like/expect. > I don't have anything terribly useful in ktrace or sshfs debug output > except that FUSE operations leading to the messages are LOOKUPs and > GETATTRs. My guess it's a Fuse4BSD issue, but I could be wrong. It sounds like a caching problem: write should invalidate cached attributes, otherwise stat() will return stale info. Miklos |
From: Csaba H. <csa...@cr...> - 2006-10-02 14:36:18
|
On Mon, Oct 02, 2006 at 03:15:49PM +0200, Miklos Szeredi wrote: > My guess it's a Fuse4BSD issue, but I could be wrong. > > It sounds like a caching problem: write should invalidate cached > attributes, otherwise stat() will return stale info. First we should know the exact version of fuse4bsd does Andriy use. Since attribute caching is just a recent addition to it... Andriy, for me the most useful/comfortable is if you use the latest devel version. It's also fine if not, but in that case please exactly specify the list of patches you applied against the last release... Csaba |
From: Andriy G. <av...@ic...> - 2006-10-02 14:47:22
|
on 02/10/2006 17:32 Csaba Henk said the following: > Andriy, for me the most useful/comfortable is if you use the latest > devel version. It's also fine if not, but in that case please exactly > specify the list of patches you applied against the last release... This is actually: fusefs-kmod-0.3.0_3 fusefs-libs-2.5.3_1 fusefs-sshfs-1.6 from the latest FreeBSD ports, plus the extra patch for sshfs: http://mercurial.creo.hu/repos/sshfs-hg/?cs=97fc7e353ddc I think that the above means that I have the following changes to the release: 1. unprivileged_proc_debug fix 2. READs on write-only file fix 3. root directory locking fix -- Andriy Gapon |