Issue with 'Unknown Error: -512'

[Brandon Falk]

On 7/19/2011 7:31 AM, Garrett Cooper wrote:
> On Tue, Jul 19, 2011 at 4:58 AM, Garrett Cooper<yanegomi at gmail.com>  wrote:
>> On Mon, Jul 18, 2011 at 5:19 PM, Brandon Falk<falkman at 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 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.
>> What UFS options do you have defined in your kernel?
>      Also, what does mount say and have you tried running as root?
> Thanks,
> -Garrett
>

Garrett,
I am running as root. No issues with the mounting. As for options, which 
do you want?

-Brandon Falk