[PATCH] ntfs: mount read-only when mft records are smaller than the device block

An mft record is written with a single bio of exactly mft_record_size
bytes. bio_unaligned() rejects a bio whose size is not a multiple of the
device's logical block size, so on a volume whose mft records are smaller
than that block no mft record can be written at all.

On 512n and 512e drives this is a non-issue; however, on 4Kn drives when
the mft record (1k) is smaller than the logical block size (4k) mft
writes begin to fail. At the same time, other writes that use all 4k
will succeed leading to a corruption situation.

This is a stopgap change that mounts as read-only. The longer term fix is
to perform 4k writes on 4Kn devices when writing the mft; however, that's
more involved.

Assisted-by: claude:claude-opus-5
Signed-off-by: Dennis Tighe <[email protected]>
---
From my testing:

Before this patch, on a volume with 20 files already on it:

  ro mount rc=0
  files visible: 20  <- reads are fine
  rw mount rc=0
  files created: 48  <- every creation reported success
  umount rc=0
  5 I/O errors logged

  next mount:
  ntfs_mft_record_check(): Record 64 has no FILE magic (0x0)
  map_mft_record(): Failed with error code 5.
  ntfs_lookup(): Found stale reference to inode 0x40 ... returning -EIO

  files: 0

The volume would still mount at the end, but the directory read as empty.
Looking at the disk, the mft had not been updated but 4 INDX blocks in the
root directory had been written. This occurred since the mft writes from
the original mount were failing while other data writes were succeeding.

With this patch, same volume and device on my test script:

  ntfs: (device vda): ntfs_fill_super(): mft record size (1024) is smaller
  than the device logical block size (4096).  Mft records cannot be
  written.  Mounting read-only.
  mount rc=0
  /dev/vda on /mnt/t type ntfs (ro,relatime,...)

Reproducing can be done without 4Kn hardware. I used a 4k image and qemu's
virtio-blk with logical_block_size=4096.

I noted this in the commit message, but this is very much a stopgap
measure to prevent corruption before full 4Kn support is added. It
seemed safer to me to fallback to read only for now and determine the
right path forward later. I believe there are a few options there that
are worth some discussion. 

 fs/ntfs/super.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c
index 30481e5d5dd4..ed587bc5e477 100644
--- a/fs/ntfs/super.c
+++ b/fs/ntfs/super.c
@@ -2298,6 +2298,22 @@ static int ntfs_fill_super(struct super_block *sb, struct fs_context *fc)
 		ntfs_debug("Changed device block size to %i bytes (block size bits %i) to match volume sector size.",
 				blocksize, sb->s_blocksize_bits);
 	}
+
+	/*
+	 * If the device's logical block size is larger than the mft record (1k)
+	 * writes to it will currently fail. Reads are unaffected, so we can still
+	 * mount the volume as read-only.
+	 */
+	if (vol->mft_record_size < bdev_logical_block_size(sb->s_bdev)) {
+		if (!sb_rdonly(sb)) {
+			ntfs_error(sb,
+				   "mft record size (%i) is smaller than the device logical block size (%u).  Mft records cannot be written.  Mounting read-only.",
+				   vol->mft_record_size,
+				   bdev_logical_block_size(sb->s_bdev));
+			sb->s_flags |= SB_RDONLY;
+		}
+	}
+
 	/* Initialize the cluster and mft allocators. */
 	ntfs_setup_allocators(vol);
 	/* Setup remaining fields in the super block. */
-- 
2.43.0