| Message ID | 156444945993.2682261.3926017251626679029.stgit@magnolia (mailing list archive) |
|---|---|
| Headers | show |
| Series | iomap: lift the xfs writepage code into iomap | expand |
I don't really see the point of the split, but the result looks fine to me.
On Tue, 30 Jul 2019 at 16:48, Christoph Hellwig <hch@infradead.org> wrote: > I don't really see the point of the split, but the result looks fine > to me. The split made it easier for me to debug the gfs2 side by backing out the xfs changes. Thanks, Andreas
Darrick, are you going to queue this up?
On Thu, Aug 15, 2019 at 11:52:29PM -0700, Christoph Hellwig wrote: > Darrick, > > are you going to queue this up? Yes, I'll go promote the iomap writeback branch to iomap-for-next. I haven't 100% convinced myself that it's a good idea to hook up xfs to it yet, if nothing else because of all the other problems I've had getting 5.3 testing to run to completion reliably... ...I assume gfs2 and zonedfs are getting ready to send stuff based on that branch? --D
On Sat, Aug 17, 2019 at 3:46 AM Darrick J. Wong <darrick.wong@oracle.com> wrote: > > On Thu, Aug 15, 2019 at 11:52:29PM -0700, Christoph Hellwig wrote: > > Darrick, > > > > are you going to queue this up? > > Yes, I'll go promote the iomap writeback branch to iomap-for-next. I > haven't 100% convinced myself that it's a good idea to hook up xfs to it > yet, if nothing else because of all the other problems I've had getting > 5.3 testing to run to completion reliably... > > ...I assume gfs2 and zonedfs are getting ready to send stuff based on > that branch? It doesn't look like the gfs2 bits are going to be ready for 5.4. Andreas
On 2019/08/16 18:47, Darrick J. Wong wrote: > On Thu, Aug 15, 2019 at 11:52:29PM -0700, Christoph Hellwig wrote: >> Darrick, >> >> are you going to queue this up? > > Yes, I'll go promote the iomap writeback branch to iomap-for-next. I > haven't 100% convinced myself that it's a good idea to hook up xfs to it > yet, if nothing else because of all the other problems I've had getting > 5.3 testing to run to completion reliably... > > ...I assume gfs2 and zonedfs are getting ready to send stuff based on > that branch? > > --D > I have zonefs rebased on your branch and good to go. But before posting, I am finishing a test suite for it as xfstests does not work, for obvious reasons :) I will post a V2 next week. As zonefs is not an update but a new fs, it needs to be accepted first. If it is, it will need your branch. Best regards.
On Fri, Aug 16, 2019 at 06:46:33PM -0700, Darrick J. Wong wrote: > On Thu, Aug 15, 2019 at 11:52:29PM -0700, Christoph Hellwig wrote: > > Darrick, > > > > are you going to queue this up? > > Yes, I'll go promote the iomap writeback branch to iomap-for-next. I > haven't 100% convinced myself that it's a good idea to hook up xfs to it > yet, if nothing else because of all the other problems I've had getting > 5.3 testing to run to completion reliably... Oh well. I had some XFS/iomap patches I want to dust off that depend on it, but I guess they'll have to wait then. We just need to be very careful the versions don't get out of sync, which would be a major pain in the butt.
On Fri, Aug 16, 2019 at 06:46:33PM -0700, Darrick J. Wong wrote: > On Thu, Aug 15, 2019 at 11:52:29PM -0700, Christoph Hellwig wrote: > > Darrick, > > > > are you going to queue this up? > > Yes, I'll go promote the iomap writeback branch to iomap-for-next. I > haven't 100% convinced myself that it's a good idea to hook up xfs to it > yet, if nothing else because of all the other problems I've had getting > 5.3 testing to run to completion reliably... So what is the current status? We are going to get an -rc8 to give you some more time, and I'd really hate to miss the second merge window for the change, espececially as things tend to get out of sync, and I have various bits touching the code planned for the 5.5 merge window.
On Sun, Sep 01, 2019 at 12:34:40AM -0700, Christoph Hellwig wrote: > On Fri, Aug 16, 2019 at 06:46:33PM -0700, Darrick J. Wong wrote: > > On Thu, Aug 15, 2019 at 11:52:29PM -0700, Christoph Hellwig wrote: > > > Darrick, > > > > > > are you going to queue this up? > > > > Yes, I'll go promote the iomap writeback branch to iomap-for-next. I > > haven't 100% convinced myself that it's a good idea to hook up xfs to it > > yet, if nothing else because of all the other problems I've had getting > > 5.3 testing to run to completion reliably... > > So what is the current status? We are going to get an -rc8 to give > you some more time, and I'd really hate to miss the second merge window > for the change, espececially as things tend to get out of sync, and I > have various bits touching the code planned for the 5.5 merge window. Heh, I had assumed today was going to be 5.3 final and that would be that for 5.4. However, if the 5.4 merge window isn't going to close until Sept. 29 then there's still time for more soaking. Would you mind rebasing the remaining patches against iomap-for-next and sending that out? I'll try to get to it before I go on vacation 6 - 15 Sept. Admittedly I think the controversial questions are still "How much writeback code are we outsourcing to iomap anyway?" and "Do we want to do the added stress of keeping that going without breaking everyone else"? IOWs, more philosophical than just the mechanics of porting code around. I still want a CONFIG_IOMAP_DEBUG which turns on stricter checking of the iomap(s) that ->begin_iomap pass to the actor, if you have the time; I for one am starting to forget exactly what are the valid combinations of iomap flag inputs that ->begin_iomap has to handle for a given actor and what are the valid imaps for each actor that it can pass back. :) --D
On Sun, Sep 01, 2019 at 01:44:00PM -0700, Darrick J. Wong wrote: > Would you mind rebasing the remaining patches against iomap-for-next and > sending that out? I'll try to get to it before I go on vacation 6 - 15 > Sept. Ok. Testing right now, but the rebase was trivial. > Admittedly I think the controversial questions are still "How much > writeback code are we outsourcing to iomap anyway?" and "Do we want to > do the added stress of keeping that going without breaking everyone > else"? IOWs, more philosophical than just the mechanics of porting code > around. At least as far as I'm concerned the more code that is common the better so that I don't have to fix up 4 badly maintained half-assed forks of the same code (hello mpage, ext4 and f2fs..). > I still want a CONFIG_IOMAP_DEBUG which turns on stricter checking of > the iomap(s) that ->begin_iomap pass to the actor, if you have the time; > I for one am starting to forget exactly what are the valid combinations > of iomap flag inputs that ->begin_iomap has to handle for a given actor > and what are the valid imaps for each actor that it can pass back. :) I was actually thinking of killing the input IOMAP_ types entirely, as that "flags" model just doesn't scale, and instead have more iomap_ops instances in the callers. But that is just a vague idea at the moment. I'll need some more time to think about it.
On Mon, Sep 02, 2019 at 10:16:37AM -0700, Christoph Hellwig wrote: > On Sun, Sep 01, 2019 at 01:44:00PM -0700, Darrick J. Wong wrote: > > Would you mind rebasing the remaining patches against iomap-for-next and > > sending that out? I'll try to get to it before I go on vacation 6 - 15 > > Sept. > > Ok. Testing right now, but the rebase was trivial. > > > Admittedly I think the controversial questions are still "How much > > writeback code are we outsourcing to iomap anyway?" and "Do we want to > > do the added stress of keeping that going without breaking everyone > > else"? IOWs, more philosophical than just the mechanics of porting code > > around. > > At least as far as I'm concerned the more code that is common the > better so that I don't have to fix up 4 badly maintained half-assed > forks of the same code (hello mpage, ext4 and f2fs..). Any news?
On Tue, Sep 10, 2019 at 12:01:24AM -0700, Christoph Hellwig wrote: > On Mon, Sep 02, 2019 at 10:16:37AM -0700, Christoph Hellwig wrote: > > On Sun, Sep 01, 2019 at 01:44:00PM -0700, Darrick J. Wong wrote: > > > Would you mind rebasing the remaining patches against iomap-for-next and > > > sending that out? I'll try to get to it before I go on vacation 6 - 15 > > > Sept. > > > > Ok. Testing right now, but the rebase was trivial. > > > > > Admittedly I think the controversial questions are still "How much > > > writeback code are we outsourcing to iomap anyway?" and "Do we want to > > > do the added stress of keeping that going without breaking everyone > > > else"? IOWs, more philosophical than just the mechanics of porting code > > > around. > > > > At least as far as I'm concerned the more code that is common the > > better so that I don't have to fix up 4 badly maintained half-assed > > forks of the same code (hello mpage, ext4 and f2fs..). > > Any news? Darrick is still on holidays. The iomap-for-next branch has this series in it already(*), but I suspect at this point the XFS conversion is going to have to wait until the next cycle. Cheers, Dave. (*) https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/log/?h=iomap-for-next