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) <[email protected]>
---
fs/hfsplus/inode.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
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,
};
--
2.42.0
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 <[email protected]>
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 <[email protected]>
>
> 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
--
Jan Kara <[email protected]>
SUSE Labs, CR