при горячем подключении дисков из кабины с волоконно-оптическим каналом сообщается неправильный размер

Во-первых, мы даже не уверены, что это проблема udev, но нам нужно где-то начать спрашивать ... У нас есть Hitachi Fibre Channel SAN, обслуживающий тома на пару машин, на которых работает сервер ubuntu 12.04 amd64.

Для сопоставления мы используем идентификаторы / dev / disk / by-id, созданные udev.

...
/dev/disk/by-id/scsi-1HITACHI_750505270125
/dev/disk/by-id/scsi-1HITACHI_750505270125-part1
/dev/disk/by-id/scsi-1HITACHI_750505270126
/dev/disk/by-id/scsi-1HITACHI_750505270126-part1
...

где последние 4 цифры (0125, 0126, 0127 ...) определяют LUN, созданные на Hitachi, поэтому мы знаем, к какому физическому тому мы обращаемся.

Мы обнаружили странную проблему, когда у нас был том объемом 1,1 Т на LUN 125, и мы разбили его на более мелкие куски со стороны кабины. После переназначения одного из новых дисков серверу кажется, что размер тома кэшируется (см. 1150,5 ГБ размер)...

root@server1:~# fdisk -l /dev/disk/by-id/scsi-1HITACHI_750505270125

Disk /dev/disk/by-id/scsi-1HITACHI_750505270125: 1150.5 GB, 1150514364416 bytes
255 heads, 63 sectors/track, 139875 cylinders, total 2247098368 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

                                      Device Boot      Start         End      Blocks   Id  System
/dev/disk/by-id/scsi-1HITACHI_750505270125-part1              63  1048575999   524287968+  83  Linux

Странно то, что у нас одни и те же тома подключены к другой машине. Они не активны, но все еще видны. Мы наблюдали такое же поведение, но после перезагрузки диски выглядят так, как должны (см. 536,9 ГБ размер):

root@server2:~# fdisk -l /dev/disk/by-id/scsi-1HITACHI_750505270125

Disk /dev/disk/by-id/scsi-1HITACHI_750505270125: 536.9 GB, 536870912000 bytes
255 heads, 63 sectors/track, 65270 cylinders, total 1048576000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

                                      Device Boot      Start         End      Blocks   Id  System
/dev/disk/by-id/scsi-1HITACHI_750505270125-part1              63  1048575999   524287968+  83  Linux

Забавно то, что мы разбили диск на втором сервере (server2), тот, который видит правильный размер, и на первом сервере (server1) мы можем видеть этот раздел, хотя фактический размер диска все еще старый . Мы даже отформатировали его и смонтировали на server2, написали текстовый файл, размонтировали его, перемонтировали на server1 и, конечно же, мы можем увидеть текстовый файл и получить к нему доступ.

Похоже, где-то попутно кто-то кеширует размеры томов?

На всякий случай, после отсоединения и повторного подключения дисков мы повторно сканируем LUN и запускаем udevadm trigger чтобы обновить дерево udev ...

Нам не очень удобно использовать диски с таким несоответствием, и если нам нужно перезагрузить систему, чтобы показать реальные размеры, мы теряем все преимущества горячего подключения ... Любые идеи о том, как это происходит, и безопасно ли их использовать тома без перезапуска?

В качестве побочного вопроса, когда мы отсоединяем диски от кабины волокна, мы запускаем udevadm trigger и похоже, что udev просто добавляет новые диски (устройства), но не удаляет пропавшие устройства ... так ли это должно быть?