summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorKonstantin Komarov <almaz.alexandrovich@paragon-software.com>2026-07-02 13:07:13 +0200
committerKonstantin Komarov <almaz.alexandrovich@paragon-software.com>2026-07-24 12:45:00 +0200
commite31886cb6e0e14cf65e27da0bf1a422ff419d893 (patch)
treeec07c7abc49e05f9d2056f35445d01455bd80e7f /tools/perf/scripts/python
parent2fa56613b25d0c983ef3ff6d3e865d4254280abe (diff)
fs/ntfs3: load ATTR_BITMAP run extents from $MFT extension records
When $MFT's ATTR_BITMAP attribute is heavily fragmented, its run list can span multiple MFT extension records (attribute list entries with vcn > 0). The non-primary segment handler in ntfs_read_mft() only processed ATTR_DATA extension segments for MFT_REC_MFT, silently skipping any ATTR_BITMAP segments. This left sbi->mft.bitmap.run incomplete, causing wnd_init() to fail with -ENOENT when wnd_rescan() tried to look up a VCN not covered by the truncated run list. Observed on a 16 TB NTFS volume (0xFFFFFEFF total clusters) whose MFT bitmap run list was split across 97 extents in extension records. wnd_rescan() successfully looked up VCNs 0-122 from the runs loaded from the base record, then failed at VCN 123 (the last cluster of the bitmap) whose run was only present in an extension record. Fix by extending the MFT_REC_MFT special case to also handle ATTR_BITMAP extension segments, storing their runs into sbi->mft.bitmap.run the same way the primary segment does. Signed-off-by: Senjin <senjin@hatchling.org> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions