On Mon, 8 Jul 2019 at 13:26, Mariusz Dabrowski <mariusz.dabrowski@xxxxxxxxx> wrote: > > On Saturday, July 6, 2019 5:13:14 PM CEST Stephan Diestelhorst wrote: > > (Off list, please keep me in CC, thx!) > > Hi there, > > > > TL;DR: > > https://github.com/neilbrown/mdadm/commit611d95290dd41d73bd8f9cc06f7ec293a40 > > b819e regresses mdadm and does not let me assemble my main drive due to > > kernel error > > > > md: invalid array_size 125035870 > default size 125035776 > > > > caused by changed reservation size in mdadm, and thus reduced "Usable > > Size" being reduced too much (smaller than 0.5 * Array Size). > > > > Full write-up with logs etc here: > > https://forum.manjaro.org/t/mdadm-issues-live-cd-works-existing-install-bre > > aks-fakeraid-imsm/93613 > > > > I chased through both 4.0 mdadm (which works, e.g., from a Live image), > > and the new 4.1 version (from Manjaro update), and the same disk in the > > same machine works with the older, and refuses to work with the newer > > mdadm. > > > > The kernel message suggests that the kernel refuses to assemble the > > array, and tracing the computation back through both versions (4.0 and > > GIT head 3c9b46cf9ae15a9be98fc47e2080bd9494496246 ) reveals that both > > versions end up using the default for reserved space, which is > > MPB_SECTOR_CNT + IMSM_RESERVED_SECTORS (the other difference between the > > versions is the size computed, but that is hopefully intentional due to > > 444909385fdaccf961308c4319d7029b82bf8bb1 ). > > > > I understand too little to propose a fix or know why the defaults were > > changed, but this is clearly a regression, and the disk works in the > > same machine in Windows, and with older Live images. > > > > More log output in the Manjaro forum thread, and I have some more log > > output with printf's sprinkled around if necessary. > > > > Happy to help fix this, please have a look :) > > > > Thanks, > > Stephan > > Hello Stephan, > I have failed to reproduce your issue. Thanks a lot for trying! > I would like to know how your array was created: in OS using mdadm or with RST PreOS? This array was created by the laptop manufacturer. It an Acer S7 191 which has a peculiar SSD. It is a dual sided mSATA SSD which has two independent mSATA SSDs on either side of the PCB, and they are then joined together to a single block device using RAID-0 IMSM. There is something slightly peculiar here.. I got the disk out of a broken S7 and put it into a different one. Mentioning that in case the BIOS stores any specific data about the disk and that has changed without it noticing (but I think that is unlikely). > Which version of mdadm/RST have you used? Like I said above, the disk came pre-configured. I can boot into Windows alright and can also inspect the disk with the Intel RST tools, currently at 16.0.2.1086. On the mdadm side, the disk assembles with mdadm 4.0 and does not with 4.1; and the commit I mention above is the one that makes the difference. Happy to pull out any RST data, here is what I get from the System Report: Kit installed: 16.0.2.1086 User interface version: 16.0.2.1086 Language: English (UK) RAID option ROM version: 11.5.0.1582 Driver version: 16.0.2.1086 ISDI version: 16.0.2.1086 And then details for the disks and arrays. Array ... Size: 122,114 MB ... Available space: 8MB Volume ... Size 122,105 MB Disk ... Size: 60 GB Disk ... Size: 60 GB The disk is a LITEONIT CMT-64L3M firmware L2C6 > Your notebook is booting in legacy or UEFI mode? Booting in EFI mode, via rEFInd. Thanks, Stephan
