It seems not necessary to me. unmap_buffer from flushpage is the mechanism
that is supposed to take care of clearing the dirty bit and to wait for
I/O completation (uplugging the device if necessary). If that wouldn't be
true then we would have visible corruption going on and we would be
reading a flood of fs corruption reports on l-k ;).
When we had the problem in the other way around (before turning on
unmap_underlying_metadata) we had visible reports on the list.
Note: if the sync_page is necessary for alien cases like NFS that's fine,
I'm not complaining the callback per se, just the ext2 implementation.
If I am missing something I'd appreciate if who did the change would
enlight me. BTW, doing run_task_queue() at such an high frequency is not
good even if necessary (unmap_buffer does it only when the buffer is
locked!) and I'd rather prefer to find an alternate solution if possile
since it will hurt both the truncate operation and it will screwup people
plugging of the I/O request queue.
Thanks,
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:12 EST