На устройстве не осталось места, хотя занято только 50% пространства и 1% инодов.

Вопрос или проблема

Это на Iomega IX200 NAS, который был расширен до 4 ТБ дисков с оригинальных 2 ТБ.

Все выглядит хорошо.

Но когда я пытаюсь сохранить данные в новый файл, я получаю ошибку “На устройстве не осталось места”. Я получаю эту ошибку, независимо от того, пытаюсь ли я сохранить файл через общий доступ к диску NAS на другом устройстве или через сессию SSH на самом NAS.

df -h сообщает:

Filesystem            Size  Used Avail Use% Mounted on
rootfs                 50M  3.7M   47M   8% /
/dev/root.old         6.5M  2.1M  4.4M  33% /initrd
none                   50M  3.7M   47M   8% /
/dev/md0_vg/BFDlv     4.0G  624M  3.2G  17% /boot
/dev/loop0            592M  538M   54M  91% /mnt/apps
/dev/loop1            4.9M  2.2M  2.5M  48% /etc
/dev/loop2            260K  260K     0 100% /oem
tmpfs                 122M     0  122M   0% /mnt/apps/lib/init/rw
tmpfs                 122M     0  122M   0% /dev/shm
/dev/mapper/md0_vg-vol1
                       16G  1.5G   15G  10% /mnt/system
/dev/mapper/5244dd0f_vg-lv58141b0d
                      3.7T  2.0T  1.7T  55% /mnt/pools/A/A0

/mnt/pools/A/A0 – это то, что обеспечивает хранилище.

df -h -i:

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
rootfs                   31K     567     30K    2% /
/dev/root.old           1.7K     130    1.6K    8% /initrd
none                     31K     567     30K    2% /
/dev/md0_vg/BFDlv       256K      20    256K    1% /boot
/dev/loop0               25K     25K      11  100% /mnt/apps
/dev/loop1              1.3K    1.1K     139   89% /etc
/dev/loop2                21      21       0  100% /oem
tmpfs                    31K       4     31K    1% /mnt/apps/lib/init/rw
tmpfs                    31K       1     31K    1% /dev/shm
/dev/mapper/md0_vg-vol1
                         17M    9.7K     16M    1% /mnt/system
/dev/mapper/5244dd0f_vg-lv58141b0d
                        742M    2.6M    739M    1% /mnt/pools/A/A0

Когда раздел был увеличен, я запустил lvresize и xfs_grow, после чего он начал показывать емкость 3.7 ТБ.

Диски/разделы:

$ parted -l

Model: Seagate ST4000VN008-2DR1 (scsi)
Disk /dev/sda: 4001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      36.9kB  21.5GB  21.5GB               primary       
 2      21.5GB  4001GB  3979GB               primary       


Model: Seagate ST4000VN008-2DR1 (scsi)
Disk /dev/sdb: 4001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      36.9kB  21.5GB  21.5GB               primary       
 2      21.5GB  4001GB  3979GB               primary       


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/5244dd0f_vg-lv58141b0d: 3979GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  3979GB  3979GB  xfs               


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/md0_vg-vol1: 17.2GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  17.2GB  17.2GB  xfs               


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/md0_vg-BFDlv: 4295MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  4295MB  4295MB  ext2              


Error: /dev/mtdblock0: unrecognised disk label                            

Error: /dev/mtdblock1: unrecognised disk label                            

Error: /dev/mtdblock2: unrecognised disk label                            

Error: /dev/mtdblock3: unrecognised disk label                            

Error: /dev/md0: unrecognised disk label                                  

Error: /dev/md1: unrecognised disk label                                  

Когда я запустил mdadm --detail, я заметил, что второй раздел пары RAID1 был установлен как ‘removed’:

mdadm --detail /dev/md1
/dev/md1:
        Version : 01.00
  Creation Time : Mon Mar  7 08:45:49 2011
     Raid Level : raid1
     Array Size : 3886037488 (3706.01 GiB 3979.30 GB)
  Used Dev Size : 7772074976 (7412.03 GiB 7958.60 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Thu Jan 23 03:29:04 2025
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           Name : ix2-200-DC386F:1
           UUID : 8a192f2c:9829df88:a6961d81:20478f62
         Events : 365631

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed   #### <<<< ЭТОТ /dev/sdb2
       2       8        2        1      active sync   /dev/sda2

Когда я выполняю исследование на /dev/sdb2, я получаю:

$ mdadm --examine /dev/sdb2
mdadm: No md superblock detected on /dev/sdb2.

Я задумался, не ограничение ли это все еще, в пределах прошивки, (оригинальные диски имели емкость 1.8 ТБ). Но теперь думаю, что проблема в ‘removed’ диске, но может ли это объяснить, почему я могу использовать только 1.7 ТБ из 3.4 ТБ файловой системы? /dev/sda2 сообщается как ‘clean’.

Редактирование:

Я попробовал
mdadm --zero-superblock /dev/sdb2

Затем

mdadm --manage /dev/md1 --add /dev/sdb2

Но я получил ошибку mdadm: add new device failed for /dev/sdb2 as 3: Invalid argument.

Ответ или решение

Для решения проблемы «Недостаточно места на устройстве», когда фактическое использование дискового пространства составляет всего 50%, а использование инодов лишь 1%, крайне важно понять внутренние процессы и структуру файловых систем, а также управление RAID-массивами. Приведенные вами данные содержат несколько ключевых моментов, требующих разъяснения и комплексного подхода.

Теория

Файловая система XFS, используемая в вашем устройстве, известна своей высокой производительностью и масштабируемость, но может вызывать трудности при управлении, особенно в контексте изменения размера разделов и RAID-конфигураций. Ошибка «No space left on device» чаще всего свидетельствует об проблеме не с физическим пространством, а с метаданными или конфигурацией RAID.

В данном случае, сокращение доступного пространства файловой системы может быть связано с тем, что вторая часть вашего RAID1 массива — /dev/sdb2 — была удалена, а оставшийся диск /dev/sda2 работает в режиме одиночного диска в массиве, недоступном для записи. Это приводит к тому, что файл-система видит лишь половину доступного пространства, изначально рассчитанного для двухдискового массива.

Пример

В вашей системе RAID1 используется для создания зеркалирования, предоставляющего надежность данных путем дублирования. Это означает, что оба диска (изначально /dev/sda2 и /dev/sdb2) должны иметь одинаковые данные. Однако в текущем состоянии массив работает в режиме деградации, то есть только один из двух дисков фактически участвует в зеркалировании. Отсюда и необъяснимое уменьшение доступного пространства — система просто не видит вторую часть массива.

Отсутствие суперблока на /dev/sdb2 препятствует его включению обратно в массив. Это может быть вызвано попытками модификации конфигурации или неудачным обновлением, например, вследствие изменения размера раздела без корректного обновления метаданных.

Применение

Для решения данной проблемы требуется несколько этапов:

  1. Проверка метаданных и суперблоков: Поскольку /dev/sdb2 не имеет md-суперблока, возможно, потребуется вручную создать новый или восстановить массив из существующих данных, если они не были перезаписаны.

  2. Обновление RAID-конфигурации: Используйте mdadm для рекомпоновки массива. Это может включать такие команды, как mdadm --zero-superblock, но будьте осторожны, так как это может стереть существующие данные на устройстве. Возможно, потребуется перестроить RAID с использованием --raidhotadd или аналогичных опций.

  3. Проверка целостности файловой системы: После успешной реконфигурации RAID убедитесь, что файловая система не имеет ошибок, используя такую утилиту, как xfs_repair.

  4. Обновление и корректировка LVM: После восстановления RAID, переоцените пространство Logical Volume Manager (LVM), чтобы убедиться в правильном отображении расширенного размера. Использование xfs_grow здесь было правильным шагом, но он актуален только после корректной настройки всех логических подразделений.

  5. Регулярный мониторинг и резервное копирование: Даже после решения текущей проблемы, очень важно иметь стабильный план регулярного мониторинга системы и резервного копирования данных.

В завершение, необходимо отметить, что работа над дисковыми массивами и RAID-конфигурацией требует определенных знаний и может привести к потере данных при неправильных действиях. Рекомендуется привлечение опытных специалистов для выполнения сложных операций и анализа системных логов, чтобы точно определить причины и пути решения проблемы.

Оцените материал
Добавить комментарий

Капча загружается...