lkml.org 
[lkml]   [2011]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Man page doc for SEEK_DATA/SEEK_HOLE
On 09/19/2011 12:27 PM, Sunil Mushran wrote:
> On 09/19/2011 10:57 AM, Eric Blake wrote:
>> Also, it seems a shame that the kernel can fail with EINVAL instead of
>> properly emulating SEEK_HOLE and SEEK_DATA even on file systems with
>> no underlying support for reporting holes.
>>
>
> Why do you say that? If I am reading generic_file_llseek_unlocked()
> correctly, the default behavior is treat offset < i_size as data.

The proposed wording states:

> .B EINVAL
> .I whence
> -is not one of
> -.BR SEEK_SET ,
> -.BR SEEK_CUR ,
> -.BR SEEK_END ;
> -or the resulting file offset would be negative,
> +is not valid (this error may be returned if
> +.I whence
> +is
> +.BR SEEK_DATA
> +or
> +.BR SEEK_HOLE
> +and the underlying file system does not support the operation).

I guess it should instead read:

EINVAL whence is not valid (this error may be returned if whence is
SEEK_DATA or SEEK_HOLE but the kernel does not support the operation).

Given your argument that new enough kernels understand SEEK_DATA and
SEEK_HOLE for all file systems.

I agree that EINVAL will occur if you compile against new enough glibc
that exposes the constants, but then run against an older kernel that
does not yet understand them. But I want the text to be clarified to be
bullet-proof that if I am running against kernel 3.1 or newer, the only
way I will ever get EINVAL for these two constants is if I do something
else invalid, like a negative offset.

--
Eric Blake eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org


\
 
 \ /
  Last update: 2011-09-19 20:47    [W:0.051 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site