Re: LSI MegaRAID SAS 8208ELP в Debian

2016-02-12 Пенетрантность Andrey Melnikoff 
Sergey B Kirpichev  wrote:
> On Mon, Feb 08, 2016 at 06:44:21PM +0300, Andrey Melnikoff wrote:
> > Потому что это "Fake Raid".
> Может таки имелось в виду: "выкинь ты ее"?
Можно конечно и так прочитать. Но для начала.
a) поставь свежее ядро, 3.2.0 - замшелая протухшая древность.
b) эту железку должен поддерживать mptsas драйвер 
c) обнови mdadm

d) с дисками - никто не мешает нашинковать SASы разной убитости как JBOD (raid 
0)
и отдать наверх. Для чего у тебя md0 сделан в формате 0.90 - lilo чтоль стоит?

e) данные ddf обычно прячут в конец диска

и покажи dmesg после загрузки, mdadm --detail /dev/md127, mdadm -Ebsc partitions

Re: LSI MegaRAID SAS 8208ELP в Debian

2016-02-08 Пенетрантность Sergey B Kirpichev 
On Mon, Feb 08, 2016 at 06:03:43PM +0300, Павел Марченко wrote:
>Конечно это не мое дело, но зачем такие сложности?
>Почему не использовать железный raid?

В смысле, выкинуть контроллер и купить новый?  Вариант,
но это уже вне моей компетенции.

>Если уже и начинать химичить, то проще загрузчик и /boot на флешку и
>грузится с нее.

Загружаться с - задача максимум, конечно.  В запасе есть еще
SATA-контроллер на материнской плате, так что загрузиться найдется откуда.

А минимум - чтобы эта штука просто работала как контроллер.

Re: LSI MegaRAID SAS 8208ELP в Debian

2016-02-08 Пенетрантность Sergey B Kirpichev 
On Mon, Feb 08, 2016 at 06:44:21PM +0300, Andrey Melnikoff wrote:
> Потому что это "Fake Raid".

Может таки имелось в виду: "выкинь ты ее"?

> > Если уже и начинать химичить, то проще загрузчик и /boot на флешку и
> > грузится с нее.
> Проще, но автор не ищщет легких путей.

Убитых флешек автору уже на ожерелье хватит.  Так что
конкретно этот вариант - наверное все-таки не вариант.

Re: LSI MegaRAID SAS 8208ELP в Debian

2016-02-08 Пенетрантность Andrey Melnikoff 
Павел Марченко  wrote:

> Конечно это не мое дело, но зачем такие сложности?
> Почему не использовать железный raid?
Потому что это "Fake Raid".

> Если уже и начинать химичить, то проще загрузчик и /boot на флешку и
> грузится с нее.
Проще, но автор не ищщет легких путей.

Re: LSI MegaRAID SAS 8208ELP в Debian

2016-02-08 Пенетрантность Павел Марченко 
Конечно это не мое дело, но зачем такие сложности?
Почему не использовать железный raid?
Если уже и начинать химичить, то проще загрузчик и /boot на флешку и
грузится с нее.

7 февраля 2016 г., 19:07 пользователь Sergey Kirpichev  написал:

> На всякий случай попробую поспрошать здесь.
>
> Может кто-то из уважаемых имеет счастье иметь этот контроллер
> в Debian, да еще в работоспособном виде?
>
> # lspci |grep SAS
> 03:00.0 SCSI storage controller: LSI Logic / Symbios Logic MegaRAID SAS
> 8208ELP/8208ELP (rev 08)
>
> Задачи:
> 1) заставить его отдавать голые диски в систему (в наличии
> при ем 3 шт. SAS разных размеров и разной степени убитости).
> 2) побить диски на разделы, сделать рейд средствами системы (md).
> 3) грузиться потом с этого самого контроллера.
>
> C 1-2) худо-бедно получилось справиться, подсунув PCI ID
> драйверу mptsas при инсталляции Debian Wheezy (см. напр.
> http://forum.univention.de/viewtopic.php?f=48=1406
> (В ядре из Jessie, вроде, этот idшник уже есть в драйвере.)
> Загрузчик поставил на первый диск (sda), там же раздел для /boot,
> далее на всех трех дисках выделил одинаковые разделы и
> сделал raid5 массив.
>
> А вот с 3) пока выяснилось следующее: контроллер позволяет
> в своем биос пометить загрузочным только созданный там
> райд-массив: в частности, raid0 из отдельного диска.  Именно
> последний вариант я выбрал, сделав его из sda.
>
> Система загружается, видит диски и разделы на них, за
> исключением разделов на том самом первом диске.  Соответственно,
> программный raid5 сразу разваливается.  Помимо дисков и созданных
> мной mdadm массивов - виден также /dev/md127 (metadata:ddf), видимо
> это то, что добавлено через BIOS контроллера.  Если сказать
> mdadm --stop /dev/md127 && partprobe /dev/sda - появляются созданные
> ранее разделы на первом диске, доступные для записи и после добавления
> руками /dev/sda5 в развалившийся ранее raid5 массив - начинается
> синхронизация данных на него (покуда массив не разваливается из-за
> проблем с уже другим диском).
>
> Подозреваю, что если сказать ядру md.ddf=0 - оно не будет стартовать
> /dev/md127.  Будет ли этого достаточно, чтобы после загрузки корректно
> определялись _все_ разделы и можно было обновлять загрузчик на /dev/sda
> без риска повредить метаданные, что добавил контроллер?
>
> PS: В аттаче прикрепил вывод mdadm с созданных массивов (уже после
> убития raid5, увы, покуда еще там что-то шевелилось), --examine с sda.
>



-- 
В смысле осмысления бессмысленного смысл тоже имеет определенную
осмысленность!!!

LSI MegaRAID SAS 8208ELP в Debian

2016-02-07 Пенетрантность Sergey Kirpichev 
На всякий случай попробую поспрошать здесь.

Может кто-то из уважаемых имеет счастье иметь этот контроллер
в Debian, да еще в работоспособном виде?

# lspci |grep SAS
03:00.0 SCSI storage controller: LSI Logic / Symbios Logic MegaRAID SAS 
8208ELP/8208ELP (rev 08)

Задачи:
1) заставить его отдавать голые диски в систему (в наличии
при ем 3 шт. SAS разных размеров и разной степени убитости).
2) побить диски на разделы, сделать рейд средствами системы (md).
3) грузиться потом с этого самого контроллера.

C 1-2) худо-бедно получилось справиться, подсунув PCI ID
драйверу mptsas при инсталляции Debian Wheezy (см. напр.
http://forum.univention.de/viewtopic.php?f=48=1406
(В ядре из Jessie, вроде, этот idшник уже есть в драйвере.)
Загрузчик поставил на первый диск (sda), там же раздел для /boot,
далее на всех трех дисках выделил одинаковые разделы и
сделал raid5 массив.

А вот с 3) пока выяснилось следующее: контроллер позволяет
в своем биос пометить загрузочным только созданный там
райд-массив: в частности, raid0 из отдельного диска.  Именно
последний вариант я выбрал, сделав его из sda.

Система загружается, видит диски и разделы на них, за
исключением разделов на том самом первом диске.  Соответственно,
программный raid5 сразу разваливается.  Помимо дисков и созданных
мной mdadm массивов - виден также /dev/md127 (metadata:ddf), видимо
это то, что добавлено через BIOS контроллера.  Если сказать
mdadm --stop /dev/md127 && partprobe /dev/sda - появляются созданные
ранее разделы на первом диске, доступные для записи и после добавления
руками /dev/sda5 в развалившийся ранее raid5 массив - начинается
синхронизация данных на него (покуда массив не разваливается из-за
проблем с уже другим диском).

Подозреваю, что если сказать ядру md.ddf=0 - оно не будет стартовать
/dev/md127.  Будет ли этого достаточно, чтобы после загрузки корректно
определялись _все_ разделы и можно было обновлять загрузчик на /dev/sda
без риска повредить метаданные, что добавил контроллер?

PS: В аттаче прикрепил вывод mdadm с созданных массивов (уже после
убития raid5, увы, покуда еще там что-то шевелилось), --examine с sda.
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
  Creation Time : Fri Feb  5 11:46:13 2016
 Raid Level : raid1
 Array Size : 248896 (243.10 MiB 254.87 MB)
  Used Dev Size : 248896 (243.10 MiB 254.87 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Fri Feb  5 22:15:29 2016
  State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

   UUID : 80bd2915:f9f84736:2e3043bf:80ad74ee (local to host debian)
 Events : 0.21

Number   Major   Minor   RaidDevice State
   0   8   170  active sync   /dev/sdb1
   1   8   331  active sync   /dev/sdc1

$ sudo mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
  Creation Time : Fri Feb  5 11:47:01 2016
 Raid Level : raid5
 Array Size : 285988864 (272.74 GiB 292.85 GB)
  Used Dev Size : 142994432 (136.37 GiB 146.43 GB)
   Raid Devices : 3
  Total Devices : 3
Persistence : Superblock is persistent

Update Time : Fri Feb  5 23:59:24 2016
  State : clean, FAILED 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

 Layout : left-symmetric
 Chunk Size : 512K

   Name : debian:1  (local to host debian)
   UUID : 4b854156:7a4d61e6:aba2c6bc:836bc8c5
 Events : 2080

Number   Major   Minor   RaidDevice State
   0   000  removed
   1   001  removed
   2   8   372  active sync   /dev/sdc5

   1   8   21-  faulty spare   /dev/sdb5
   3   85-  spare   /dev/sda5


$ sudo mdadm --examine /dev/sda
/dev/sda:
  Magic : de11de11
Version : 01.00.00
Controller GUID : 4C534920:20202020::::
  (LSI )
 Container GUID : 4C534920:20202020:1055:::1424
  (LSI  01/01/80 03:00:00)
Seq : 000f
  Redundant hdr : yes
  Virtual Disks : 1

  VD GUID[0] : 4C534920:20202020:1055::43E64F20:0A28
  (LSI  02/05/16 22:16:48)
 unit[0] : 0
state[0] : Optimal, Consistent
   init state[0] : Not Initialised
   access[0] : Read/Write
 Name[0] : 
 Raid Devices[0] : 1 (0)
   Chunk Size[0] : 128 sectors
   Raid Level[0] : RAID0
  Device Size[0] : 438475776
   Array Size[0] : 438475776

 Physical Disks : 1
  NumberRefNo  Size   Device  Type/State
 0998e4942  438475776K /dev/sdaactive/Online


$ uname -a
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux

$ sudo mdadm --version
mdadm - v3.2.5 - 18th May 2012

$ sudo smartctl -a /dev/sdb
smartctl 5.41