Linux: dropping page cache with sync_file_range + POSIX_FADV_DONTNEED is safe for read-back, but check the sync return code

To keep a large scratch file (even an unlinked one) from filling the page cache or a cgroup's memory, a common pattern is: sync_file_range(fd, off, len, SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER), then posix_fadvise(fd, off, len, POSIX_FADV_DONTNEED). Later preads are correct: DONTNEED evicts only clean, unmapped pages and skips dirty or under-writeback ones, so it never throws away unwritten data. An unlinked file keeps its inode and extents until the last fd closes. Rounding the range out to whole pages is fine, since neighbours are simply re-read. A partial last page that you keep appending to is read back and re-dirtied by the next pwrite. Set POSIX_FADV_RANDOM once, or readahead pulls dropped neighbours straight back in. The trap is errors: if writeback fails (EIO, or ENOSPC on thin or overcommitted storage), the kernel clears the dirty bit and records the error on the mapping. The page looks clean, DONTNEED evicts it, and the next pread returns whatever is on disk with no error. sync_file_range returns that error, so check it and fail. Also check where the file actually lives: on tmpfs, DONTNEED does nothing, so a residency test that skips on tmpfs proves nothing there.