The readahead(2) man page was claiming that the call blocks until all
data has been read into the cache. This is incorrect.
Signed-off-by: Phillip Susi <[email protected]>
---
man2/readahead.2 | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/man2/readahead.2 b/man2/readahead.2
index 605fa5e..1b0376e 100644
--- a/man2/readahead.2
+++ b/man2/readahead.2
@@ -27,7 +27,7 @@
.\"
.TH READAHEAD 2 2013-04-01 "Linux" "Linux Programmer's Manual"
.SH NAME
-readahead \- perform file readahead into page cache
+readahead \- initiate file readahead into page cache
.SH SYNOPSIS
.nf
.BR "#define _GNU_SOURCE" " /* See feature_test_macros(7) */"
@@ -37,8 +37,8 @@ readahead \- perform file readahead into page cache
.fi
.SH DESCRIPTION
.BR readahead ()
-populates the page cache with data from a file so that subsequent
-reads from that file will not block on disk I/O.
+initates readahead on a file so that subsequent reads from that file will
+hopefully be satisfied from the cache, and not block on disk I/O.
The
.I fd
argument is a file descriptor identifying the file which is
@@ -57,8 +57,6 @@ equal to
.IR "(offset+count)" .
.BR readahead ()
does not read beyond the end of the file.
-.BR readahead ()
-blocks until the specified data has been read.
The current file offset of the open file referred to by
.I fd
is left unchanged.
@@ -94,6 +92,13 @@ On some 32-bit architectures,
the calling signature for this system call differs,
for the reasons described in
.BR syscall (2).
+
+The call attempts to schedule the reads in the background and return
+immediately, however it may block while reading filesystem metadata
+in order to locate where the blocks requested are. This occurs frequently
+with ext[234] on large files using indirect blocks instead of extents,
+giving the appearence that the call blocks until the requested data has
+been read.
.SH SEE ALSO
.BR lseek (2),
.BR madvise (2),
--
1.8.3.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
[CC += Past reporters: Corrado Zoccolo, Greg Smith, Zhu Yanhai]
On 03/14/2014 04:54 PM, Phillip Susi wrote:
> The readahead(2) man page was claiming that the call blocks until all
> data has been read into the cache. This is incorrect.
Phillip, thanks for a good patch that sums things up. I didn't follow
up an earlier patch from Greg Smith, but that patch failed to explain the
behavior we discussed in https://bugzilla.kernel.org/show_bug.cgi?id=54271
where call did sometimes block for a considerable time.
I've applied the patch. Thanks for your efforts and persistence.
I've tweaked your text a bit to make some details clearer (I hope):
readahead() initiates readahead on a file so that subsequent
reads from that file will, be satisfied from the cache, and not
block on disk I/O (assuming the readahead was initiated early
enough and that other activity on the system did not in the
meantime flush pages from the cache).
...
readahead() attempts to schedule the reads in the background
and return immediately. However, it may block while it reads
the filesystem metadata needed to locate the requested blocks.
This occurs frequently with ext[234] on large files using indi‐
rect blocks instead of extents, giving the appearence that the
call blocks until the requested data has been read.
Okay?
Cheers,
Michael
> Signed-off-by: Phillip Susi <psusi-GeWIH/[email protected]>
> ---
> man2/readahead.2 | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/man2/readahead.2 b/man2/readahead.2
> index 605fa5e..1b0376e 100644
> --- a/man2/readahead.2
> +++ b/man2/readahead.2
> @@ -27,7 +27,7 @@
> .\"
> .TH READAHEAD 2 2013-04-01 "Linux" "Linux Programmer's Manual"
> .SH NAME
> -readahead \- perform file readahead into page cache
> +readahead \- initiate file readahead into page cache
> .SH SYNOPSIS
> .nf
> .BR "#define _GNU_SOURCE" " /* See feature_test_macros(7) */"
> @@ -37,8 +37,8 @@ readahead \- perform file readahead into page cache
> .fi
> .SH DESCRIPTION
> .BR readahead ()
> -populates the page cache with data from a file so that subsequent
> -reads from that file will not block on disk I/O.
> +initates readahead on a file so that subsequent reads from that file will
> +hopefully be satisfied from the cache, and not block on disk I/O.
> The
> .I fd
> argument is a file descriptor identifying the file which is
> @@ -57,8 +57,6 @@ equal to
> .IR "(offset+count)" .
> .BR readahead ()
> does not read beyond the end of the file.
> -.BR readahead ()
> -blocks until the specified data has been read.
> The current file offset of the open file referred to by
> .I fd
> is left unchanged.
> @@ -94,6 +92,13 @@ On some 32-bit architectures,
> the calling signature for this system call differs,
> for the reasons described in
> .BR syscall (2).
> +
> +The call attempts to schedule the reads in the background and return
> +immediately, however it may block while reading filesystem metadata
> +in order to locate where the blocks requested are. This occurs frequently
> +with ext[234] on large files using indirect blocks instead of extents,
> +giving the appearence that the call blocks until the requested data has
> +been read.
> .SH SEE ALSO
> .BR lseek (2),
> .BR madvise (2),
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
On Sat, Mar 15, 2014 at 10:05:14AM +0100, Michael Kerrisk (man-pages) wrote:
> However, it may block while it reads
> the filesystem metadata needed to locate the requested blocks.
> This occurs frequently with ext[234] on large files using indi???
> rect blocks instead of extents, giving the appearence that the
> call blocks until the requested data has been read.
>
> Okay?
The part above is something that should be in the BUGS section.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
On Sat, Mar 15, 2014 at 10:24 AM, Christoph Hellwig <[email protected]> wrote:
> On Sat, Mar 15, 2014 at 10:05:14AM +0100, Michael Kerrisk (man-pages) wrote:
>> However, it may block while it reads
>> the filesystem metadata needed to locate the requested blocks.
>> This occurs frequently with ext[234] on large files using indi???
>> rect blocks instead of extents, giving the appearence that the
>> call blocks until the requested data has been read.
>>
>> Okay?
>
> The part above is something that should be in the BUGS section.
Good call. Done. Thanks, Christoph.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
On 03/15/2014 05:05 AM, Michael Kerrisk (man-pages) wrote:
> I've tweaked your text a bit to make some details clearer (I hope):
>
> readahead() initiates readahead on a file so that subsequent
> reads from that file will, be satisfied from the cache, and not
> block on disk I/O (assuming the readahead was initiated early
> enough and that other activity on the system did not in the
> meantime flush pages from the cache).
Slight grammatical error there: there's an extra comma in "file will, be".
On Sat, Mar 15, 2014 at 5:22 PM, Phillip Susi <[email protected]> wrote:
> On 03/15/2014 05:05 AM, Michael Kerrisk (man-pages) wrote:
>>
>> I've tweaked your text a bit to make some details clearer (I hope):
>>
>> readahead() initiates readahead on a file so that subsequent
>> reads from that file will, be satisfied from the cache, and not
>> block on disk I/O (assuming the readahead was initiated early
>> enough and that other activity on the system did not in the
>> meantime flush pages from the cache).
>
>
> Slight grammatical error there: there's an extra comma in "file will, be".
Thanks. Fixed.
Otherwise okay, I assume?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 03/15/2014 12:25 PM, Michael Kerrisk (man-pages) wrote:
>> Slight grammatical error there: there's an extra comma in "file
>> will, be".
>
> Thanks. Fixed.
>
> Otherwise okay, I assume?
Yep.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJTJOGXAAoJEI5FoCIzSKrwWL0IAJR+RDiqPUUMuRQyT+ZUICnX
5MToU3EnyEpwY37HXHIAcQv6cYwo7Z7gP7EQseChIcozzQO/xCulrH/41FyuxRt1
ci1ow/XeydhsWQ0nKpY8ox5DWfErV0csUYO+dazrKRKGnAPXQv0+Bx2DPP9mPKuJ
q9FBMP+FIFuVQW6o0VxOxQIW1lx/oYI+a5q+P91pd4fDcI0igKFNn6x5SvoaDbLI
HwA6VTmySs2BVwN3w3BK6fadWXnqd6xJUMGN0OdsqiecZGW+qgB6EdyrY9xPOjgX
ixFCpcj67OGPZY+sEAdO2T+QxNytnhhP/5Z/F7kkiu/6mKoRm/uQSdSnDZr4aPU=
=5KCU
-----END PGP SIGNATURE-----
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>