On Wed, Aug 20, 2025 at 10:11:43AM +0800, Chunsheng Luo wrote: > Tue, 19 Aug 2025 16:07:19 Miklos Szeredi wrote: > > >> > >> Only flush extending writes (up to LLONG_MAX) for files with upcoming > >> write operations, and Fix confusing 'end' parameter usage. > > > > Patch looks correct, but it changes behavior on input file of > > copy_file_range(), which is not explained here. > > Thank you for your review. > > For the copy_file_range input file, since it only involves read operations, > I think it is not necessary to flush to LLONG_MAX. Therefore, for the input file, > flushing to the end is sufficient. > > If you think my understanding is correct, I can resend a revised version of > the patch to update the commit log and include a clear explanation regarding > the behavior changes in 'fuse_copy_file_range' and 'fuse_file_fallocate' operations. I don't understand the current behavior at all -- why do the callers of fuse_writeback_range pass an @end parameter when it ignores @end in favor of LLONG_MAX? And why is it necessary to flush to EOF at all? fallocate and copy_file_range both take i_rwsem, so what could they be racing with? Or am I missing something here? fuse-iomap flushes and unmaps only the given file range, and afaict that's just fine ... but there is this pesky generic/551 failure I keep seeing, so I might actually be missing some subtlety. :) --D > Thanks > Chunsheng Luo >
