From: Christoph Hellwig <hch@lst.de>
To: Viacheslav Dubeyko <slava@dubeyko.com>
Cc: glaubitz@physik.fu-berlin.de, frank.li@vivo.com, hch@lst.de,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 6/6] hfsplus: switch address_space_operations on iomap-based support
Date: Fri, 24 Jul 2026 07:37:48 +0200 [thread overview]
Message-ID: <20260724053748.GG4181@lst.de> (raw)
In-Reply-To: <20260722213759.1360225-7-slava@dubeyko.com>
> @@ -605,20 +606,32 @@ void hfsplus_file_truncate(struct inode *inode)
> inode->i_ino, (long long)hip->phys_size, inode->i_size);
>
> if (inode->i_size > hip->phys_size) {
> + if (S_ISREG(inode->i_mode)) {
> + res = hfsplus_iomap_cont_expand(inode, inode->i_size);
> + if (res)
> + return;
> +
> + mark_inode_dirty(inode);
> + } else {
> + struct address_space *mapping = inode->i_mapping;
> + struct folio *folio;
> + void *fsdata = NULL;
> +
> + res = hfsplus_write_begin(NULL, mapping,
> + inode->i_size, 0,
> + &folio, &fsdata);
> + if (res)
> + return;
> +
> + res = generic_write_end(NULL, mapping,
> + inode->i_size, 0, 0,
> + folio, fsdata);
> + if (res < 0)
> + return;
> +
> + mark_inode_dirty(inode);
Can't this use the iomap zeroing helpers?
> -static int hfsplus_writepages(struct address_space *mapping,
> +static int hfsplus_legacy_writepages(struct address_space *mapping,
> struct writeback_control *wbc)
> {
> return mpage_writepages(mapping, wbc, hfsplus_get_block);
> @@ -196,8 +139,8 @@ static int hfsplus_writepages(struct address_space *mapping,
> const struct address_space_operations hfsplus_btree_aops = {
> .dirty_folio = block_dirty_folio,
> .invalidate_folio = block_invalidate_folio,
> - .read_folio = hfsplus_read_folio,
> - .writepages = hfsplus_writepages,
> + .read_folio = hfsplus_legacy_read_folio,
> + .writepages = hfsplus_legacy_writepages,
Would btree be a better name then legacy? So the story here is
there is a btree inode, and you want to keep the buffer_head based
path for this, at least for now?
> @@ -290,10 +274,22 @@ static int hfsplus_setattr(struct mnt_idmap *idmap,
> attr->ia_size != i_size_read(inode)) {
> inode_dio_wait(inode);
> if (attr->ia_size > inode->i_size) {
> - error = generic_cont_expand_simple(inode,
> - attr->ia_size);
> - if (error)
> - return error;
> + if (S_ISREG(inode->i_mode)) {
> + loff_t old_size = inode->i_size;
> +
> + i_size_write(inode, attr->ia_size);
> + error = hfsplus_iomap_cont_expand(inode,
> + attr->ia_size);
> + if (error) {
> + i_size_write(inode, old_size);
> + return error;
> + }
> + } else {
> + error = generic_cont_expand_simple(inode,
> + attr->ia_size);
> + if (error)
> + return error;
> + }
You're not suppoed to see ->setattr for ATTR_SIZE for anything but
regular files from the VFS. I don't think there's any hfsplus specific
path that could cause this either, could it?
prev parent reply other threads:[~2026-07-24 5:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 21:37 [PATCH 0/6] hfsplus: convert regular file I/O to iomap-based operations Viacheslav Dubeyko
2026-07-22 21:37 ` [PATCH 1/6] hfs/hfsplus: exchange hardcoded number of extents on named constants Viacheslav Dubeyko
2026-07-24 5:28 ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 2/6] hfsplus: rework hfsplus_get_block() logic Viacheslav Dubeyko
2026-07-24 5:28 ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 3/6] hfsplus: take the bitmap page lock for allocate/free Viacheslav Dubeyko
2026-07-24 5:29 ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 4/6] hfsplus: add iomap operations for regular file data Viacheslav Dubeyko
2026-07-24 5:32 ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 5/6] hfsplus: add iomap-based file_operations Viacheslav Dubeyko
2026-07-24 5:33 ` Christoph Hellwig
2026-07-22 21:37 ` [PATCH 6/6] hfsplus: switch address_space_operations on iomap-based support Viacheslav Dubeyko
2026-07-24 5:37 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260724053748.GG4181@lst.de \
--to=hch@lst.de \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=slava@dubeyko.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox