RE: [PATCH] hfsplus: limit sb_maxbytes to partition size

[Viacheslav Dubeyko]

On Thu, 2026-03-05 at 09:29 +0900, Hyunchul Lee wrote:
> On Wed, Mar 04, 2026 at 08:04:30PM +0000, Viacheslav Dubeyko wrote:
> > On Wed, 2026-03-04 at 05:08 -0800, Christoph Hellwig wrote:
> > > On Tue, Mar 03, 2026 at 05:28:07PM +0900, Hyunchul Lee wrote:
> > > > s_maxbytes currently is set to MAX_LFS_FILESIZE,
> > > > which allows writes beyond the partition size.
> > > 
> > > The "partition size" does not matter here.  s_maxbytes is the maximum
> > > size supported by the format and has nothing to do with the actual space
> > > allocated to the file system (which in Linux terminology would be the
> > > block device and not the partition anyway).
> > > 
> > > > 
> > > > As a result,
> > > > large-offset writes on small partitions can fail late
> > > > with ENOSPC.
> > > 
> > > That sounds like some other check is missing in hfsplus, but it
> > > should be about the available free space, not the device size.
> > > 
> > 
> > I agree with Christoph.
> > 
> > But, frankly speaking, I don't quite follow which particular issue is under fix
> > here. I can see that generic/268 failure has been mentioned. However, I can see
> > this:
> > 
> > sudo ./check generic/268 
> > FSTYP         -- hfsplus
> > PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 6.19.0-rc1+ #95 SMP
> > PREEMPT_DYNAMIC Thu Feb 19 15:29:55 PST 2026
> > MKFS_OPTIONS  -- /dev/loop51
> > MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
> > 
> > generic/268       [not run] Reflink not supported by scratch filesystem type:
> > hfsplus
> > Ran: generic/268
> > Not run: generic/268
> > Passed all 1 tests
> > 
> > Which particular issue is under fix?
> 
> Sorry it's generic/285, not generic/268.
> in generic/285, there is a test that creates a hole exceeding the block
> size and appends small data to the file. hfsplus fails because it fills
> the block device and returns ENOSPC. However if it returns EFBIG
> instead, the test is skipped.
> 
> For writes like xfs_io -c "pwrite 8t 512", should fops->write_iter
> returns ENOSPC, or would it be better to return EFBIG?
> > 

Current hfsplus_file_extend() implementation doesn't support holes. I assume you
mean this code [1]:

	len = hip->clump_blocks;
	start = hfsplus_block_allocate(sb, sbi->total_blocks, goal, &len);
	if (start >= sbi->total_blocks) {
		start = hfsplus_block_allocate(sb, goal, 0, &len);
		if (start >= goal) {
			res = -ENOSPC;
			goto out;
		}
	}

Am I correct?

Do you mean that calling logic expects -EFBIG? Potentially, if we tries to
extend the file, then -EFBIG could be more appropriate. But it needs to check
the whole call trace.

Thanks,
Slava.

[1] https://elixir.bootlin.com/linux/v6.19/source/fs/hfsplus/extents.c#L463