AIX LVM + JFS (JFS1) read-only disk reader - prediction log.
Author: Claude Opus 5.5 (claude-opus-5-5). Series letter: J.
Written BEFORE reading any header, any disk byte, or running any LVM command. Format: ID [confidence] claim.

--- round 1 ---
J01 [0.60] Sector 0 of an AIX physical volume is the IPL record, magic 0xC9C2D4C1 ("IBMA" in EBCDIC).
J02 [0.55] Sector 7 holds the LVM record, starting with the ASCII magic "_LVM".
J03 [0.45] The VGDA starts at sector 136.
J04 [0.60] JFS (JFS1) headers ship on the box (/usr/include/jfs/filsys.h, ino.h), so the format is documented locally.
J05 [0.60] The JFS superblock is at byte 4096 of the logical volume.
J06 [0.30] Its magic contains the ASCII "%jfs".
J07 [0.55] On-disk inodes are 128 bytes.
J08 [0.60] The root directory is inode 2.
J09 [0.45] Directories are BSD-like variable-length entries (inode, record length, name length, name).
J10 [0.50] Inodes have 8 direct block pointers plus indirection, addressing 4 KB blocks/fragments.
J11 [0.45] storevg / lv00 was created before the 2022-05-25 reinstall (the reinstall left hdisk1 alone).
J12 [0.35] /store's unallocated blocks hold recognisable data from before 2022.
J13 [0.40] My first reader lists /store's root directory exactly as ls -lia does (names, inode numbers, sizes).
J14 [0.55] storevg's physical partition size is at least 64 MB (a ~147 GB disk under the 1016-PP-per-disk limit).
Tue Oct  6 11:26:17 PM MDT 2026

--- round 2, after jfsread matched /store (115 entries, 70 checksums); /store created 2022-06-01 ---
J15 [0.45] hdisk1 has non-zero data in partitions that storevg has never allocated (the disk had a previous life).
J16 [0.50] Any such data predates 2022 (recognisable dates, hostnames or formats from before the reinstall).
Tue Oct  6 11:38:19 PM MDT 2026

=== OUTCOMES (scored 2026-10-06) ===
J01 HIT      [0.60] sector 0 starts C9C2D4C1.
J02 HIT      [0.55] sector 7 starts "_LVM" + VGID.
J03 HIT      [0.45] VGDA copy 1 at sector 136 (copy 2 at 2242; VGSA at 128 and 2234).
J04 HIT      [0.60] /usr/include/jfs: filsys.h, ino.h, dir.h, fsdefs.h ...
J05 HIT      [0.60] superblock = block 1 (byte 4096); backup at block 31.
J06 MISS     [0.30] magic 0x43218765 (v3), stored here byte-reversed as 65 87 21 43 ("v3p" magic). No "%jfs".
J07 HIT      [0.55] DILENGTH 128.
J08 HIT      [0.60] ROOTDIR_I 2.
J09 HIT      [0.45] d_ino, d_reclen, d_namlen, d_name.
J10 HIT      [0.50] 8 direct, single indirect to 4 MB, double beyond.
J11 MISS     [0.45] /store's superblock: created 2022-06-01 22:03:07 UTC; storevg's VGDA 22:03:06. After the reinstall.
J12 MISS     [0.35] (inferred) old data only reaches ~PP 45; lv00 sits at PP 111-143, which were zero.
J13 MISS     [0.40] three fixes first: raw devices need 512-aligned whole-sector reads; I put s_time at 48 instead of 44
                    (forgot the padding after two chars); and inodes must be located by allocation-group geometry
                    because the .inodes inode is empty on disk.
J14 HIT      [0.55] 256 MB partitions.
J15 HIT      [0.45] PPs 1-45 hold non-zero data: x86 code and an old NTFS volume.
J16 HIT      [0.50] that NTFS volume was formatted 2011-08-14 00:44 UTC (whole 146.8 GB disk, NTLDR-era boot code).

Calibration:  0.50-0.79: 9/9   <0.50: 3/7
Under-confident in the middle again (format facts that ship in /usr/include); the misses are history
(J11/J12) and my own first-draft code (J13).
Not predicted: /store is a big-file filesystem (version 2, bigexp 5: 128 KB blocks past 4 MB); inode generation
numbers are the fs creation timestamp; AIX's LVM leaves most of sectors 9-4351 alone, so the previous owner's
NTFS boot sector at sector 63 survived; sectors 70-71 repeat the _LVM and DEFECT records of sectors 7-8.
Checked: jfsread listing == live lstat for all 115 entries; cksum identical for all 70 files (incl. 12.8 MB).
I stopped at filesystem metadata on the old NTFS volume: it's a previous owner's data.

--- round 3, the old NTFS volume on hdisk1 (aggregate timestamps only, no names) and hdisk0 ---
J17 [0.55] The NTFS version is 3.1 (XP / Server 2003), not 3.0 (Windows 2000).
J18 [0.40] The newest surviving timestamps fall before 2014 (within ~2 years of the 2011 format).
J19 [0.50] At least 30% of surviving files were created on the format day, 2011-08-14 (the OS install).
J20 [0.35] hdisk0 also has an NTFS boot sector at sector 63 (the two drives shared a past).
Wed Oct  7 12:12:37 AM MDT 2026

--- results so far this round: hdisk1's 2011 NTFS is 3.1 and was never used (32-record MFT, 19 system files, all
    created 2011-08-14 00:44:43-58); hdisk0 has a 732 MB FAT16 ("MSDOS5.0") boot sector at 63. Before the region scan:
J21 [0.50] MFT records from an older NTFS filesystem survive in PPs 1-45, with timestamps before 2011-08-14.
J22 [0.40] That older system's newest timestamps fall in 2009-2011 (in service until shortly before the reformat).
Wed Oct  7 12:14:26 AM MDT 2026

=== OUTCOMES round 3 ===
J17 HIT      [0.55] NTFS 3.1.
J18 HIT      [0.40] every timestamp in the 2011 volume is 2011-08-14 00:44 (it was never used).
J19 HIT      [0.50] 100% - but only because the volume holds nothing except its 19 system files.
J20 MISS     [0.35] hdisk0 sector 63 is a FAT16 boot sector ("MSDOS5.0", 732 MB partition, 255x63 geometry), not NTFS.
                    (Its sector-0 partition entries are AIX's own type-0x41 PReP boot entries for hd5, not old data -
                    I briefly took them for an old DOS partition table.)
J21 HIT      [0.50] 17,284 MFT records of an older NTFS survive in PPs 1-45 (13,096 in use, 4,179 torn).
J22 HIT      [0.40] newest pre-reformat activity: 2011-05. Creation dates peak 2005-04/05 (~7,300 files: an OS install
                    with vendor modification dates from 1995-2004); bursts of modifications 2004-10 and 2007-02.
hdisk1 history: x86 system installed ~spring 2005, in use to ~May 2011; quick-formatted blank NTFS 2011-08-14;
AIX storevg 2022-06-01. Only aggregate counts and dates were read; no names or contents.