| Message ID | 20231215200245.748418-9-willy@infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Clean up the writeback paths | expand |
On Fri, Dec 15, 2023 at 08:02:39PM +0000, Matthew Wilcox (Oracle) wrote: > The earlier commit to remove hfsplus_writepage only removed it from > one of the aops. Remove it from the btree_aops as well. Looks good: Reviewed-by: Christoph Hellwig <hch@lst.de> although I had some reason to be careful back then. hfsplus should be testable again that the hfsplus Linux port is back alive. Is there any volunteer to test hfsplus on the fsdevel list?
On 16.12.23 05:33, Christoph Hellwig wrote: > On Fri, Dec 15, 2023 at 08:02:39PM +0000, Matthew Wilcox (Oracle) wrote: >> The earlier commit to remove hfsplus_writepage only removed it from >> one of the aops. Remove it from the btree_aops as well. > > Looks good: > > Reviewed-by: Christoph Hellwig <hch@lst.de> > > although I had some reason to be careful back then. hfsplus should > be testable again that the hfsplus Linux port is back alive. Is there > any volunteer to test hfsplus on the fsdevel list? What do you have in mind on that side? "Just" running it through fstests and see that we don't regress here or more than that?
On Mon, Dec 18, 2023 at 10:41:27AM +0000, Johannes Thumshirn wrote: > > although I had some reason to be careful back then. hfsplus should > > be testable again that the hfsplus Linux port is back alive. Is there > > any volunteer to test hfsplus on the fsdevel list? > > What do you have in mind on that side? "Just" running it through fstests > and see that we don't regress here or more than that? Yeah. Back in the day I ran hfsplus through xfstests, IIRC that might even have been the initial motivation for supporting file systems that don't support sparse files. I bet a lot has regressed or isn't support since, though.
On 18.12.23 16:04, Christoph Hellwig wrote: > On Mon, Dec 18, 2023 at 10:41:27AM +0000, Johannes Thumshirn wrote: >>> although I had some reason to be careful back then. hfsplus should >>> be testable again that the hfsplus Linux port is back alive. Is there >>> any volunteer to test hfsplus on the fsdevel list? >> >> What do you have in mind on that side? "Just" running it through fstests >> and see that we don't regress here or more than that? > > Yeah. Back in the day I ran hfsplus through xfstests, IIRC that might > even have been the initial motivation for supporting file systems > that don't support sparse files. I bet a lot has regressed or isn't > support since, though. > Let me see what I can do on that front over my winter vacation. As long as there's no APFS support in Linux its the only way to exchange data between macOS and Linux anyways, so we shouldn't break it.
On Mon 18-12-23 15:40:42, Johannes Thumshirn wrote: > On 18.12.23 16:04, Christoph Hellwig wrote: > > On Mon, Dec 18, 2023 at 10:41:27AM +0000, Johannes Thumshirn wrote: > >>> although I had some reason to be careful back then. hfsplus should > >>> be testable again that the hfsplus Linux port is back alive. Is there > >>> any volunteer to test hfsplus on the fsdevel list? > >> > >> What do you have in mind on that side? "Just" running it through fstests > >> and see that we don't regress here or more than that? > > > > Yeah. Back in the day I ran hfsplus through xfstests, IIRC that might > > even have been the initial motivation for supporting file systems > > that don't support sparse files. I bet a lot has regressed or isn't > > support since, though. > > > > Let me see what I can do on that front over my winter vacation. As long > as there's no APFS support in Linux its the only way to exchange data > between macOS and Linux anyways, so we shouldn't break it. AFAIK macOS actually does support UDF so there are other filesystems you can use for data exchange. Honza
diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c index 702a0663b1d8..3d326926c195 100644 --- a/fs/hfsplus/inode.c +++ b/fs/hfsplus/inode.c @@ -28,11 +28,6 @@ static int hfsplus_read_folio(struct file *file, struct folio *folio) return block_read_full_folio(folio, hfsplus_get_block); } -static int hfsplus_writepage(struct page *page, struct writeback_control *wbc) -{ - return block_write_full_page(page, hfsplus_get_block, wbc); -} - static void hfsplus_write_failed(struct address_space *mapping, loff_t to) { struct inode *inode = mapping->host; @@ -159,9 +154,10 @@ const struct address_space_operations hfsplus_btree_aops = { .dirty_folio = block_dirty_folio, .invalidate_folio = block_invalidate_folio, .read_folio = hfsplus_read_folio, - .writepage = hfsplus_writepage, + .writepages = hfsplus_writepages, .write_begin = hfsplus_write_begin, .write_end = generic_write_end, + .migrate_folio = buffer_migrate_folio, .bmap = hfsplus_bmap, .release_folio = hfsplus_release_folio, };
The earlier commit to remove hfsplus_writepage only removed it from one of the aops. Remove it from the btree_aops as well. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> --- fs/hfsplus/inode.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)