* split the reflink remap from the block allocation path
@ 2017-04-03 12:11 Christoph Hellwig
0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2017-04-03 12:11 UTC (permalink / raw)
To: linux-xfs
We've run into various problems due to the fact that the reflink remap
code reuses the xfs_bmapi_write codepath for setting up the extent list
entries and abuses the firstblock field for that purpose.
This series fixes this by creating an entirely separate xfs_bmapi_remap
path that is much simpler than xfs_bmapi_write and does not need to
overload the firstblock field.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: split the reflink remap from the block allocation path
2017-04-03 12:18 Christoph Hellwig
@ 2017-04-10 7:36 ` Christoph Hellwig
0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2017-04-10 7:36 UTC (permalink / raw)
To: linux-xfs
Any chance to get some reviews on this series?
On Mon, Apr 03, 2017 at 02:18:27PM +0200, Christoph Hellwig wrote:
> We've run into various problems due to the fact that the reflink remap
> code reuses the xfs_bmapi_write codepath for setting up the extent list
> entries and abuses the firstblock field for that purpose.
>
> This series fixes this by creating an entirely separate xfs_bmapi_remap
> path that is much simpler than xfs_bmapi_write and does not need to
> overload the firstblock field.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---
^ permalink raw reply [flat|nested] 4+ messages in thread
* split the reflink remap from the block allocation path
@ 2017-04-03 12:18 Christoph Hellwig
2017-04-10 7:36 ` Christoph Hellwig
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2017-04-03 12:18 UTC (permalink / raw)
To: linux-xfs
We've run into various problems due to the fact that the reflink remap
code reuses the xfs_bmapi_write codepath for setting up the extent list
entries and abuses the firstblock field for that purpose.
This series fixes this by creating an entirely separate xfs_bmapi_remap
path that is much simpler than xfs_bmapi_write and does not need to
overload the firstblock field.
^ permalink raw reply [flat|nested] 4+ messages in thread
* split the reflink remap from the block allocation path
@ 2017-04-03 12:10 Christoph Hellwig
0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2017-04-03 12:10 UTC (permalink / raw)
To: linux-xfs
We've run into various problems due to the fact that the reflink remap
code reuses the xfs_bmapi_write codepath for setting up the extent list
entries and abuses the firstblock field for that purpose.
This series fixes this by creating an entirely separate xfs_bmapi_remap
path that is much simpler than xfs_bmapi_write and does not need to
overload the firstblock field.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-04-10 7:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-03 12:11 split the reflink remap from the block allocation path Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2017-04-03 12:18 Christoph Hellwig
2017-04-10 7:36 ` Christoph Hellwig
2017-04-03 12:10 Christoph Hellwig
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.