Don't fadvise we don't need data that we do need

The documentation for posix_fadvise states that if len is 0 the advice
extends to the end of the file. We currently always pass 0 for
the first two posix_fadvise calls (first because ofs is 0, second
because ofs == BLOB_READ_SIZE == 1024*1024) so we're advising the kernel
to dump any predicted file caching twice per file.

This patch ensures we don't pass a len of 0 in the two scenarios above.

Signed-off-by: Aidan Hobson Sayers <aidanhs@cantab.net>
[rlb@defaultvalue.org: adjust commit summary]
Reviewed-by: Rob Browning <rlb@defaultvalue.org>
Tested-by: Rob Browning <rlb@defaultvalue.org>

diff --git a/lib/bup/hashsplit.py b/lib/bup/hashsplit.py
index 72ea20de997709df26f1e4d316cf5534a4483990..571ddf6434ac1723c1948ffc5c4ba6f59843a72c 100644 (file)
--- a/lib/bup/hashsplit.py
+++ b/lib/bup/hashsplit.py
@@ -48,11 +48,12 @@ def readfile_iter(files, progress=None):
         while 1:
             if progress:
                 progress(filenum, len(b))
-            fadvise_done(f, max(0, ofs - 1024*1024))
             b = f.read(BLOB_READ_SIZE)
             ofs += len(b)
+            # Warning: ofs == 0 means 'done with the whole file'
+            # This will only happen here when the file is empty
+            fadvise_done(f, ofs)
             if not b:
-                fadvise_done(f, ofs)
                 break
             yield b