On Wed 11-11-15 09:31:39, Dave Chinner wrote: > On Tue, Nov 10, 2015 at 11:02:53AM +0100, Jan Kara wrote: > > On Tue 10-11-15 11:00:27, Dave Chinner wrote: > > > On Mon, Nov 09, 2015 at 05:51:49PM +0100, Jan Kara wrote: > > > > The zeroing code in __dax_fault() needs to go away anyway so whether we > > > > return buffer_new buffer is not really substantial but I'd like to get some > > > > agreement and consistency among filesystems in with which flags zeroed > > > > blocks are returned. Thoughts? > > > > > > There is no consistency to begin with, especially w.r.t. unwritten > > > extent behaviour as the upper layers don't all understand that > > > buffer_unwritten is a valid flag for getblock to return. Hence we > > > have hacks in XFS setting buffer_new() in strange cases to get the > > > upper level code to zero stuff that really needs zeroing... > > > > In ext4 we set buffer as new in two cases: > > > > 1) When it was freshly allocated (regardless whether into unwritten or > > normal extent). > > Which only works for freshly allocated unwritten extents, not for > writes into preallocated extents. > > > 2) When it was converted from unwritten to written state. > > Which, for direct IO, is no good when we do the conversion after IO > completion because we need to know at IO submission if we need to do > sub-block zeroing (i.e. dio_zero_block() will skip the zeroing if > buffer_new() is not set on unwritten blocks). OK, sorry I parsed the code flow wrong, ext4 sets buffer_new for any unwritten extent it returns (when create == 1 only but that doesn't really make a difference). And then for any freshly allocated block. This seems pretty consistent to me. There are two places in ext4 that set returned buffer as new (those two cases mentioned above) and that seems to be enough. Maybe XFS needs something different but at least from looking at ext4 setting of buffer_new is not complex... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
