Date: Tue, 19 Jul 2011 04:58:47 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Brandon Falk <falkman@gamozo.org> Cc: freebsd-hackers@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: Issue with 'Unknown Error: -512' Message-ID: <CAGH67wTwvwThV7xgPNTXt-0n-zwpkrdgvvdvVuiQ__fJf9Sr3w@mail.gmail.com> In-Reply-To: <4E24CD87.4010906@gamozo.org> References: <4E2448D1.6020504@gamozo.org> <4E244EE1.40604@FreeBSD.org> <4E24CD87.4010906@gamozo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 18, 2011 at 5:19 PM, Brandon Falk <falkman@gamozo.org> wrote: > 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 wa= s >>> 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 issue= s >>> 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'> =A0test` fails every other try. You have the same issue wit= h >>> text >>> editors like `edit` where it fails every other save. There are no issue= s >>> with >>> `echo 'hi'>> =A0test` 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() =A0 (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 curren= tly > 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. What UFS options do you have defined in your kernel? Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wTwvwThV7xgPNTXt-0n-zwpkrdgvvdvVuiQ__fJf9Sr3w>