| Message ID | 1394812471-9693-1-git-send-email-psusi@ubuntu.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
[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@ubuntu.com> > --- > 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), >
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 from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Mar 15, 2014 at 10:24 AM, Christoph Hellwig <hch@infradead.org> 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
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". -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Mar 15, 2014 at 5:22 PM, Phillip Susi <psusi@ubuntu.com> 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 from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----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 from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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),
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 <psusi@ubuntu.com> --- man2/readahead.2 | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)