Re: [PATCH v5 1/2] iomap: fix zero padding data issue in concurrent append writes

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

 



On Wed, Dec 04, 2024 at 07:05:01AM -0500, Brian Foster wrote:
> On Wed, Dec 04, 2024 at 05:06:00PM +0800, Long Li wrote:
> > On Tue, Dec 03, 2024 at 09:54:41AM -0500, Brian Foster wrote:
> > > Not sure I see how this is a serialization dependency given that
> > > writeback completion also samples i_size. But no matter, it seems a
> > > reasonable implementation to me to make the submission path consistent
> > > in handling eof.
> > > 
> > > I wonder if this could just use end_pos returned from
> > > iomap_writepage_handle_eof()?
> > > 
> > > Brian
> > > 
> > 
> > It seems reasonable to me, but end_pos is block-size granular. We need
> > to pass in a more precise byte-granular end. 
> 
> Well Ok, but _handle_eof() doesn't actually use the value itself so from
> that standpoint I see no reason it couldn't at least return the
> unaligned end pos. From there, it looks like we do still want the
> rounded up value for the various ifs state management calls.
> 
> I can see a couple ways of doing that.. one is just align the value in
> the caller and use the two variants appropriately. Since the ifs_
> helpers all seem to be in byte units, another option could be to
> sanitize the helpers to the appropriate start/end rounding internally.
> 
> Either of those probably warrant a separate prep patch or two rather
> than being squashed in with the i_size fix, but otherwise I'm not seeing
> much of a roadblock here. Am I missing something?
> 
> Brian
> 

Agreed. Looks like there are no other roadblocks. I'll update in the next
version. 

Best Regards
Long Li




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux