Intel imsm fakeraid unsupported attributes [SOLVED]

Message

motig · Post by **motig** » Tue Oct 11, 2016 2:48 pm

I have purchased an HP EliteBook 840 G2 laptop which comes with Intel fake raid controller, used primarily for "accelerating" the HDD by caching data on a smaller SSD. There is a 1 TB HDD and a 30 GB SSD drive. From what I have read on various forums, this SSD caching is not directly supported in Linux. However, I decided to try a hybrid solution. I disabled the caching feature completely in Windows, then created new partitions for Gentoo, installed a base system and GRUB. Afterwards, I re-enabled the caching but I allocated only 20 GB of the 30 GB SSD drive to caching. The other 10 GB volume is marked as "normal" and I was indeed able to create a partition on it in Windows. Intel fake raid software claims it is a RAID-0 volume with 1 disk, which struck me as weird.

Rebooting to Gentoo, it indeed does not work.

lsblk

Code: Select all

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931,5G  0 disk 
├─sda1   8:1    0   500M  0 part 
├─sda2   8:2    0   499M  0 part 
├─sda3   8:3    0     1K  0 part 
├─sda5   8:5    0 347,5G  0 part 
├─sda6   8:6    0   512M  0 part [SWAP]
├─sda7   8:7    0    24G  0 part /
├─sda8   8:8    0    64G  0 part 
└─sda9   8:9    0 494,5G  0 part 
sdb      8:16   0  29,8G  0 disk

blkid

Code: Select all

blkid
/dev/sdb: TYPE="isw_raid_member"
/dev/sda1: UUID="0684EC3684EC29BF" TYPE="ntfs" PARTUUID="fa4ecbf7-01"
/dev/sda2: UUID="72A0F302A0F2CB9B" TYPE="ntfs" PARTUUID="fa4ecbf7-02"
/dev/sda5: UUID="8EF87385F8736A7B" TYPE="ntfs" PARTUUID="fa4ecbf7-05"
/dev/sda6: UUID="bd4cc8e8-2945-4c9e-9d41-c32533a790ec" TYPE="swap" PARTUUID="fa4ecbf7-06"
/dev/sda7: LABEL="ROOT" UUID="ce90e576-de8d-4134-a28e-b1de489a4b61" TYPE="ext4" PARTUUID="fa4ecbf7-07"
/dev/sda8: PARTUUID="fa4ecbf7-08"
/dev/sda9: PARTUUID="fa4ecbf7-09"

Partitions 8 and 9 are not used yet but will be used later for ext4 filesystems.

mdadm --detail-platform

Code: Select all

       Platform : Intel(R) Matrix Storage Manager
        Version : 13.2.0.2134
    RAID Levels :
    Chunk Sizes : 4k 8k 16k 32k 64k 128k
    2TB volumes : supported
      2TB disks : supported
      Max Disks : 6
    Max Volumes : 2 per array, 4 per controller
 I/O Controller : /sys/devices/pci0000:00/0000:00:1f.2 (SATA)

So far everything looks OK but the problems start here. Volume_0000 is the volume I want to use in Gentoo, since it is not used for anything else.

mdadm --examine /dev/sdb

Code: Select all

/dev/sdb:
          Magic : Intel Raid ISM Cfg Sig.
        Version : 1.3.00
    Orig Family : bf4e6014
         Family : bf4e6014
     Generation : 00000010
mdmon: (IMSM): Unsupported attributes : 2000000
     Attributes : not supported
           UUID : 58fce6aa:ef57c65b:8b670c55:ca35f915
       Checksum : ee240255 correct
    MPB Sectors : 2
          Disks : 1
   RAID Devices : 2

  Disk00 Serial : 002523129737
          State : active
             Id : 00000003
    Usable Size : 62528008 (29.82 GiB 32.01 GB)

[Volume_0000]:
           UUID : 2f1f8af3:ed3ec2d5:378b6d8f:0e2cd2b7
     RAID Level : 0
        Members : 1
          Slots : [U]
    Failed disk : none
      This Slot : 0
     Array Size : 20588544 (9.82 GiB 10.54 GB)
   Per Dev Size : 20588808 (9.82 GiB 10.54 GB)
  Sector Offset : 0
    Num Stripes : 80424
     Chunk Size : 128 KiB
       Reserved : 0
  Migrate State : idle
      Map State : normal
    Dirty State : clean

[Volume_0001]:
           UUID : 504e8d5f:8d0d16bb:b04aaa7c:b31303b4
     RAID Level : 0
        Members : 1
          Slots : [U]
    Failed disk : none
      This Slot : 0
     Array Size : 41934848 (20.00 GiB 21.47 GB)
   Per Dev Size : 41935112 (20.00 GiB 21.47 GB)
  Sector Offset : 20592896
    Num Stripes : 163808
     Chunk Size : 128 KiB
       Reserved : 0
  Migrate State : idle
      Map State : normal
    Dirty State : clean

mdadm --assemble --scan

Code: Select all

mdmon: (IMSM): Unsupported attributes : 2000000
mdmon: Unsupported attributes in IMSM metadata.Arrays activation is blocked.
mdmon: : platform does not support raid0 with 1 disk
mdmon: IMSM RAID geometry validation failed.  Array Volume_0000 activation is blocked.
mdmon: : platform does not support raid0 with 1 disk
mdmon: IMSM RAID geometry validation failed.  Array Volume_0001 activation is blocked.
mdadm: Cannot activate member /md127/1 in /dev/md/imsm0.
mdadm: Cannot activate member /md127/0 in /dev/md/imsm0.
mdadm: No arrays found in config file or automatically

cat /proc/mdstat

Code: Select all

Personalities : [linear] 
md127 : inactive sdb[0](S)
      2644 blocks super external:imsm
       
unused devices: <none>

Is there any workaround I could try to access "Volume_0000"? I would like to use it for caching using bcache. Maybe some different way of mapping the range occupied by Volume_0000 and accessing it directly? I guess device mapper might be capable of this but I do not have much experience with it.

s4e8 · Post by **s4e8** » Tue Oct 11, 2016 4:37 pm

remove mdadm completely or add "AUTO -imsm +all" to /etc/mdadm.conf to prevent mdadm detecting imsm disks.
Due to Volume_0000 started at sector 0, it's fine to access sdb directly if all partitions don't exceed size of Volume_0000.

motig · Post by **motig** » Tue Oct 11, 2016 4:42 pm

s4e8 wrote:remove mdadm completely or add "AUTO -imsm +all" to /etc/mdadm.conf to prevent mdadm detecting imsm disks.

I am only using mdadm because I thought I would be able to use the fake raid Volume_0000. I am only interested in access to the raw blocks occupied by it though. If there is any method of mapping these blocks from /dev/sdb to a new block device so I can use them, I do not need to use mdadm.

motig · Post by **motig** » Tue Oct 11, 2016 6:42 pm

I created a ntfs file system on the Volume_0000 so I could find the start of the volume using the first seven bytes of a NTFS file system (i.e. eb52904e544653).
It turned out to be 1048576 bytes (2048 sectors). According to mdadm the volume has a size of 20588544 sectors. Thus I was able to map the sector range into a new device:

Code: Select all

dmsetup create ssd --table '0 20588544 linear /dev/sdb 2048'

Mounting the existing ntfs works so I'm marking this as solved.

s4e8 · Post by **s4e8** » Wed Oct 12, 2016 1:24 am

Volume_0000 always started at sector 0, you can access /dev/sdb1 directly, if don't change partition layout or exceed size of Volume_0000. In your case, you create the Volume_0000p1 not Volume_0000, with size of Volume_0000. If you rewrite end of created device, you will destory imsm acceleration.

motig wrote:I created a ntfs file system on the Volume_0000 so I could find the start of the volume using the first seven bytes of a NTFS file system (i.e. eb52904e544653).
It turned out to be 1048576 bytes (2048 sectors). According to mdadm the volume has a size of 20588544 sectors. Thus I was able to map the sector range into a new device:
Code: Select all
dmsetup create ssd --table '0 20588544 linear /dev/sdb 2048'
Mounting the existing ntfs works so I'm marking this as solved.

motig · Post by **motig** » Thu Oct 13, 2016 7:29 pm

Yes, if I disable acceleration in Intel software, then I can see /dev/sdb1 and it behaves like a regular disk - though it does not begin at sector 0 but at sector 2048. With acceleration enabled I can only see /dev/sdb with no partitions - I am guessing the Intel software writes some metadata there instead of a partition table.

I took the size for device mapper from what mdadm reported for Volume_0000. In the end made it a little smaller to be sure nothing overwrites the imsm acceleration data.

s4e8 · Post by **s4e8** » Fri Oct 14, 2016 4:44 am

imsm put metadata and acceleration volume at end of disk. When you activate mdadm, kernel will take over /dev/sdb, make the partitions in-accessible. The Volume_0000 IS started at sector zero, and it's a partitionable disk device, the NTFS is first partition of Volume_0000, aligned at 1M (2048 sector), the max size of this NTFS partition is size_Volume_0000 - 2048.

motig wrote:Yes, if I disable acceleration in Intel software, then I can see /dev/sdb1 and it behaves like a regular disk - though it does not begin at sector 0 but at sector 2048. With acceleration enabled I can only see /dev/sdb with no partitions - I am guessing the Intel software writes some metadata there instead of a partition table.

I took the size for device mapper from what mdadm reported for Volume_0000. In the end made it a little smaller to be sure nothing overwrites the imsm acceleration data.