Messages in this thread | | | Date | Thu, 6 Nov 2008 15:20:54 +1100 | From | Dave Chinner <> | Subject | Re: Metadata in sys_sync_file_range and fadvise(DONTNEED) |
| |
On Wed, Nov 05, 2008 at 05:19:20PM -0800, Chad Talbott wrote: > On Sun, Nov 2, 2008 at 2:45 PM, Dave Chinner <david@fromorbit.com> wrote: > > On Fri, Oct 31, 2008 at 01:54:14PM -0700, Chad Talbott wrote: > >> Andrew suggests a new SYNC_FILE_RANGE_METADATA flag for > >> sys_sync_file_range(), and leaving posix_fadvise() alone. > > > > What is the interface that a filesystem will see? No filesystem has > > a "metadata sync" method - is this going to fall through to some new > > convoluted combination of writeback flags to an inode/mapping > > that more filesystems than not can get wrong? > > Good point, coupled with metadata/data ordering and your argument > below, a decent argument against exposing this interface. > > > FWIW, sys_sync_file_range() is fundamentally broken for data > > integrity writeback - at no time does it call a filesystem method > > that can result in a barrier I/O being issued to disk after > > writeback is complete. So, unlike fsync() or fdatasync(), the data > > can still be lost after completion due to power failure on drives > > with volatile write caches.... > > Seems to be true. I'm not currently concerned with sync_file_range > for data integrity, so I'm going to punt on this issue.
;)
> If the consensus is against exposing a "sync metadata" interface, I'm > fine with ext2 silently updating metadata alongside neighboring data > in *either* posix_fadvise() or sync_file_range.
I think that sync_file_range is the better choice for "correct" behaviour. There is the assumption with syncing data explicitly that the metadata needs to reference that data is written to disk as well.
> Either way, does it > seem reasonable for posix_fadvise(DONTNEED) to call > __filemap_fdatawrite_range to do its work?
From a kernel perspective, I don't think it really matters. To an application, it could. e.g. If you're calling posix_fadvise on a large range, then the I/O patterns will be the same either way. If you're calling posix_fadvise() on small, sparse ranges of the file, then you'll turn one large, fast writeout into lots of small random writes. i.e. upgrade the kernel and the application goes much slower....
I guess this all depends on whether this would be considered a regression or a stupid application ;)
Cheers,
Dave. -- Dave Chinner david@fromorbit.com
| |