From d2bc23487af5d9f29826299e300abe2c5c63a4a8 Mon Sep 17 00:00:00 2001 From: "https://christian.amsuess.com/chrysn" Date: Wed, 29 Jan 2020 07:49:12 +0000 Subject: [PATCH] Added a comment: Re: use of RAM disk --- ...nt_3_12a1b6f9fd616f5c498d5aff1cf1bcb6._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_3_12a1b6f9fd616f5c498d5aff1cf1bcb6._comment diff --git a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_3_12a1b6f9fd616f5c498d5aff1cf1bcb6._comment b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_3_12a1b6f9fd616f5c498d5aff1cf1bcb6._comment new file mode 100644 index 0000000000..a7c70bfbb7 --- /dev/null +++ b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_3_12a1b6f9fd616f5c498d5aff1cf1bcb6._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="https://christian.amsuess.com/chrysn" + nickname="chrysn" + avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc" + subject="Re: use of RAM disk" + date="2020-01-29T07:49:08Z" + content=""" +The chunks case should fold into the original one if git-annex merges the chunks using [ioctl_ficlonerange](https://manpages.debian.org/buster/manpages-dev/ioctl_ficlonerange.2.en.html), but admittedly that is a) not portable (but neither is mounting a RAM-disk) and b) will only work on some file systems. + +I don't understand the applications in named pipes well enough to comment there (will have to read up a bit). + +But more generally, I'd gut-feeling-expect that if all is properly advertised (possibly by a fcntl, but [RWH_WRITE_LIFE_SHORT](https://manpages.debian.org/buster/manpages-dev/fcntl.2.en.html) doesn't quite seem to be it) and no fsyncs are sent (like [eatmydata](https://www.flamingspork.com/projects/libeatmydata/) does), any file should behave like that until a file system action is performed that forces it to be committed to disk -- or the kernel decides that it'd better use that RAM for something else, but that's what it can probably do best. + +I'm not sure the approach of screening (and possibly patching) data producers to not fsync (on some systems, closing might be an issue too, and that's where it gets more complex) is better than putting things to a RAM disk, I just think it's an alternative worth exploring. +"""]]