Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Apr 2012 14:42:02 +0200
From:      Attila Nagy <bra@fsn.hu>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        freebsd-fs@FreeBSD.org
Subject:   Re: SEEK_HOLE and SEEK_DATA does not work on zfs (with test case)
Message-ID:  <4F7C419A.4050607@fsn.hu>
In-Reply-To: <4F7C14B3.3040705@FreeBSD.org>
References:  <4F7BFDD4.6080703@fsn.hu> <4F7C088D.4070803@FreeBSD.org> <4F7C0B41.20702@fsn.hu> <4F7C0CE4.2030408@FreeBSD.org> <4F7C129B.9010206@fsn.hu> <4F7C14B3.3040705@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 04/04/12 11:30, Andriy Gapon wrote:
> on 04/04/2012 12:21 Attila Nagy said the following:
>> On 04/04/12 10:57, Andriy Gapon wrote:
>>> on 04/04/2012 11:50 Attila Nagy said the following:
>>>> On 04/04/12 10:38, Andriy Gapon wrote:
>>>>> on 04/04/2012 10:52 Attila Nagy said the following:
>>>>>> Hi,
>>>>>>
>>>>>> I've started to experiment with SEEK_HOLE and SEEK_DATA in python on a recent
>>>>>> FreeBSD 9-STABLE/amd64 box and it quickly became evident that the program that
>>>>>> works on Solaris doesn't work on FreeBSD.
>>>>>> Python itself couldn't cause this, because it correctly issues the lseek, but
>>>>>> taking the C test program from here:
>>>>>> https://lkml.org/lkml/2011/4/22/79
>>>>>> gives the same result (failure).
>>>>> Please see this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164445
>>>>> If you can't figure out a patch from its contents, then I'll try to provide it
>>>>> some time later today.
>>>>>
>>>> I will try it, but the e-mail above the patch is somewhat scary...
>>> Sorry, I could not understand what you mean.
>>>
>> "The patch does the copy of the offset passed from the application
>> correctly, and allows lseek(2) with SEEK_DATA/SEEK_HOLE to be used on
>> ZFS, but it is not a solution. I couldn't see a problem in the
>> assembler of the copyin and copyout functions in
>> sys/amd64/amd64/support.S, but I might be wrong, I'm no assembler
>> expert."
>>
>> This is scary. :)
> Did you see my comment in the PR trail?  It explains why that approach is not
> scary but entirely correct.
> Due to some mailing issues it is re-ordered with the patch.
>
No, thanks for the clarification. I've tried that patch and the C test 
program runs fine.
Will you commit this?

And I think a regression test case would also be good. :)

Thanks,



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F7C419A.4050607>