From: Dennis Tighe <dennis.tighe@gmail.com>
To: Hyunchul Lee <hyc.lee@gmail.com>, Namjae Jeon <linkinjeon@kernel.org>
Cc: ntfs@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH v2] ntfs: mount read-only when mft records are smaller than the device block
Date: Mon, 24 Aug 2026 07:42:00 -0700 [thread overview]
Message-ID: <6a8c583f.a4ccd6f3.2488d7.bd37@mx.google.com> (raw)
In-Reply-To: <CANFS6bb5BHY_XskcC2BoYQnB8iq0J0q90+r08xuANRoJNwHOeQ@mail.gmail.com>
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, since both report a 512-byte
logical block and a 1k record is a clean multiple of it. On 4Kn drives the
mft record (1k) is smaller than the 4k logical block, so every mft write
fails. At the same time, other writes (like directory index entries) that
are 4k will succeed leading references to unwritten mft records and a
corruption situation.
Reads are unaffected, so mount read-only rather than refusing outright,
and refuse a later remount read-write for the same reason.
This is a stopgap. Writing these volumes needs read-modify-write at the
device's block size, which this does not implement.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Dennis Tighe <dennis.tighe@gmail.com>
---
Changes in v2:
* Add the same check to ntfs_reconfigure(), so a later
"mount -o remount,rw" is refused rather than silently re-enabling the
writes. Thanks to Hyunchul Lee for catching this.
fs/ntfs/super.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c
index 30481e5d5dd4..5de07fab101c 100644
--- a/fs/ntfs/super.c
+++ b/fs/ntfs/super.c
@@ -304,6 +304,12 @@ static int ntfs_reconfigure(struct fs_context *fc)
le16_to_cpu(vol->vol_flags), es);
return -EROFS;
}
+ if (vol->mft_record_size < bdev_logical_block_size(sb->s_bdev)) {
+ ntfs_error(sb, "mft record size (%i) is below the device block size (%u)%s",
+ vol->mft_record_size,
+ bdev_logical_block_size(sb->s_bdev), es);
+ return -EROFS;
+ }
if (vol->logfile_ino && !ntfs_empty_logfile(vol->logfile_ino)) {
ntfs_error(sb, "Failed to empty journal LogFile%s",
es);
@@ -2298,6 +2304,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
next prev parent reply other threads:[~2026-08-24 14:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-23 17:45 [PATCH] ntfs: mount read-only when mft records are smaller than the device block Dennis Tighe
2026-08-24 9:37 ` Hyunchul Lee
2026-08-24 14:42 ` Dennis Tighe [this message]
2026-08-25 1:30 ` [PATCH v2] " Hyunchul Lee
2026-08-25 5:47 ` [PATCH] " Christoph Hellwig
2026-08-25 7:28 ` Namjae Jeon
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=6a8c583f.a4ccd6f3.2488d7.bd37@mx.google.com \
--to=dennis.tighe@gmail.com \
--cc=hyc.lee@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs@lists.linux.dev \
/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