public inbox for ntfs3@lists.linux.dev
 help / color / mirror / Atom feed
From: Ruslan Elishev <relishev@gmail.com>
To: ntfs3@lists.linux.dev
Cc: almaz.alexandrovich@paragon-software.com,
	linux-kernel@vger.kernel.org, Ruslan Elishev <relishev@gmail.com>
Subject: [PATCH] ntfs3: fix mount failure on volumes with fragmented MFT bitmap
Date: Sat, 28 Mar 2026 12:53:08 +0200	[thread overview]
Message-ID: <20260328105308.786150-1-relishev@gmail.com> (raw)

When the $MFT's $BITMAP attribute is fragmented across multiple MFT
records (base record + extent records), ntfs_fill_super() fails with
-ENOENT during wnd_init() because the MFT bitmap's run list only
contains runs from the base MFT record.

The issue is that wnd_init() (which calls wnd_rescan()) is invoked
before ni_load_all_mi(), so the extent MFT records containing
additional $BITMAP runs have not been loaded yet. When wnd_rescan()
tries to look up a VCN beyond the base record's runs, run_lookup_entry()
fails and returns -ENOENT.

This affects NTFS volumes with a large or heavily fragmented MFT, which
is common on long-used Windows systems where the MFT bitmap's run list
doesn't fit in the base MFT record and spills into extent records.

Fix this by:
1. Moving ni_load_all_mi() before wnd_init() so all extent records
   are available.
2. After ni_load_all_mi(), iterating through the attribute list to
   find any $BITMAP extent attributes and unpacking their runs into
   sbi->mft.bitmap.run before wnd_init() is called.

Tested on a 664GB NTFS volume with 86 MFT bitmap runs spanning
records 0 (VCN 0-105) and 17 (VCN 106-165). Before the fix, mount
fails with -ENOENT. After the fix, mount succeeds and all read/write
operations work correctly. Stress-tested with 8 test categories
(large file integrity, 10K small files, copy, move, delete/recreate
cycles, concurrent writes, deep directories, overwrite persistence).

Signed-off-by: Ruslan Elishev <relishev@gmail.com>
---
 fs/ntfs3/super.c | 39 +++++++++++++++++++++++++++++++++------
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/fs/ntfs3/super.c b/fs/ntfs3/super.c
index abcdef..123456 100644
--- a/fs/ntfs3/super.c
+++ b/fs/ntfs3/super.c
@@ -1364,16 +1364,43 @@
 	tt = inode->i_size >> sbi->record_bits;
 	sbi->mft.next_free = MFT_REC_USER;

-	err = wnd_init(&sbi->mft.bitmap, sb, tt);
-	if (err)
-		goto put_inode_out;
-
 	err = ni_load_all_mi(ni);
 	if (err) {
 		ntfs_err(sb, "Failed to load $MFT's subrecords (%d).", err);
 		goto put_inode_out;
 	}

+	/* Merge MFT bitmap runs from extent records loaded by ni_load_all_mi. */
+	{
+		struct ATTRIB *a = NULL;
+		struct ATTR_LIST_ENTRY *le = NULL;
+
+		while ((a = ni_enum_attr_ex(ni, a, &le, NULL))) {
+			CLST svcn, evcn;
+			u16 roff;
+
+			if (a->type != ATTR_BITMAP || !a->non_res)
+				continue;
+
+			svcn = le64_to_cpu(a->nres.svcn);
+			if (!svcn)
+				continue; /* Base record runs already loaded. */
+
+			evcn = le64_to_cpu(a->nres.evcn);
+			roff = le16_to_cpu(a->nres.run_off);
+
+			err = run_unpack_ex(&sbi->mft.bitmap.run, sbi,
+					    MFT_REC_MFT, svcn, evcn, svcn,
+					    Add2Ptr(a, roff),
+					    le32_to_cpu(a->size) - roff);
+			if (err < 0) {
+				ntfs_err(sb, "Failed to unpack $MFT bitmap extent (%d).", err);
+				goto put_inode_out;
+			}
+			err = 0;
+		}
+	}
+
+	err = wnd_init(&sbi->mft.bitmap, sb, tt);
+	if (err)
+		goto put_inode_out;
+
 	sbi->mft.ni = ni;

 	/* Load $Bitmap. */
--
2.43.0

             reply	other threads:[~2026-03-28 16:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-28 10:53 Ruslan Elishev [this message]
2026-04-07 17:18 ` [PATCH] ntfs3: fix mount failure on volumes with fragmented MFT bitmap Konstantin Komarov

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=20260328105308.786150-1-relishev@gmail.com \
    --to=relishev@gmail.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs3@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