Pádraig Brady <[EMAIL PROTECTED]> writes: > I was thinking it would be useful to > add an option to dd to tell it to > instruct the OS not to cache the data.
Yes, that's handy, but doesn't "dd iflag=direct" already do that for you? Hmm, I see that Linus doesn't like O_DIRECT <http://kerneltrap.org/node/7563>. Perhaps we should also support the method that Linus prefers. Can you fill us in as to why that is? > Note, posix_fadvise(POSIX_FADV_DONTNEED) on linux, > invalidates the cache for a file rather than a process.... > This is not what is usually required, and > I'm working on the kernel guys to get them > to change this. Yes, thanks, that sounds right. But dd always accesses the file sequentially. Wouldn't POSIX_FADV_SEQUENTIAL be better? or perhaps POSIX_FADV_NOREUSE? And if not, why not? I just tried the following naive patch on my Debian stable host and dd immediately dumped core inside posix_fadvise. This is not a good sign. It sounds like, despite Linus's wishes, posix_fadvise is not really ready for prime_time. diff --git a/src/dd.c b/src/dd.c index 27a4a08..824c928 100644 --- a/src/dd.c +++ b/src/dd.c @@ -68,6 +68,10 @@ static void process_signals (void); # define fdatasync(fd) (errno = ENOSYS, -1) #endif +#ifndef POSIX_FADV_SEQUENTIAL +# define posix_fadvise(fd, offset, len, advice) ENOSYS +#endif + #define max(a, b) ((a) > (b) ? (a) : (b)) #define output_char(c) \ do \ @@ -1734,6 +1738,9 @@ main (int argc, char **argv) #endif } + posix_fadvise (STDIN_FILENO, 0, 0, POSIX_FADV_SEQUENTIAL); + posix_fadvise (STDOUT_FILENO, 0, 0, POSIX_FADV_SEQUENTIAL); + install_signal_handlers (); start_time = gethrxtime (); _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
