Date: Mon, 18 Jul 2011 19:19:19 -0500 From: Brandon Falk <falkman@gamozo.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Issue with 'Unknown Error: -512' Message-ID: <4E24CD87.4010906@gamozo.org> In-Reply-To: <4E244EE1.40604@FreeBSD.org> References: <4E2448D1.6020504@gamozo.org> <4E244EE1.40604@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/18/2011 10:18 AM, Andriy Gapon wrote: > on 18/07/2011 17:53 Brandon Falk said the following: >> Hello, >> >> In recent branches (confirmed with 224119) builds compiled with clang happen to >> throw 'Unknown error: -512' in a lot of places, making the system unusable. >> (Untested on gcc compiled systems). Originally I thought the problem was with >> specific programs, then I narrowed it down to file I/O, and now I've narrowed it >> down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues >> whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every >> other time you run the program. Common issues, portsnap is affected, making it >> impossible to fetch/extract ports. As well as redirecting output in shells eg >> `echo 'hi'> test` fails every other try. You have the same issue with text >> editors like `edit` where it fails every other save. There are no issues with >> `echo 'hi'>> test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. >> >> Any tips? Otherwise I'll be looking into this today myself. > > Just a hint that you could try using DTrace syscall and fbt providers to see where > in kernel (if in kernel) that -512 return value originates. > Update: I've traced more and more into the kernel, and currently I have found the following trace: >>> ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) >>> vn_truncate() (in sys/kern/vfs_vnops.c:636) >>> kern_openat() (in sys/kern/vfs_syscalls.c:1043) >>> kern_open() (in sys/kern/vfs_syscalls.c:1035) >>> open() (in sys/kern/vfs_syscalls.c:1006) ufs_setattr() returns with -1 (EPERM) I'll continue to try to find the exact problem. A quick workaround currently would probably be to use a different filesystem other than ufs, but then again, I have no clue if other filesystems have the same issue. Hopefully that trace will help anyone who wants to help out. -Brandon Falk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E24CD87.4010906>