Re: [PATCH 0/9 v3] ext4: Punch hole and DAX fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

Like I said, there's no consistency of behaviour between
filesystems; we do what works for the specific filesystem
algorithms...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
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



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux