ZFS - знищення подвоєного zvol або набору даних зупиняє сервер. Як відновитись?

Я використовую Nexentastor на вторинному сервері зберігання даних, який працює на HP ProLiant DL180 G6 з 12 дисками SAS середньої лінії (7200 RPM). Система має процесор E5620 та 8 Гб оперативної пам’яті. Немає пристрою ZIL або L2ARC.

Минулого тижня я створив розширений zvol об'ємом 750 ГБ із зменшенням напруги та стисненням, що дозволяється ділитися через iSCSI з хостом VMWare ESX. Потім я створив образ файлового сервера Windows 2008 і скопіював ~ 300 ГБ даних користувачів у віртуальний комп'ютер. Після задоволення системою я перемістив віртуальну машину до магазину NFS в тому ж пулі.

Отримавши і працюючи з моїми віртуальними машинами в сховищі даних NFS, я вирішив видалити оригінальний зуб 750 Гб. Це застопорило систему. Доступ до веб-інтерфейсу Nexenta та NMC припинено. Зрештою, я зміг потрапити до сирої оболонки. Більшість операцій з ОС було добре, але система зависла на zfs destroy -r vol1/filesystemкоманду. Некрасивий. Я знайшов наступні дві записи помилок OpenSolaris і тепер розумію, що машина буде замурована на невідомий проміжок часу. Минуло 14 годин, тому мені потрібен план, щоб мати можливість відновити доступ до сервера.

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390

і

http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=593704962bcbe0743d82aa339988?bug_id=6924824

В майбутньому я, мабуть, прийму поради, наведені в одному із способів вирішення питання:

Workaround
    Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.

Оновлення: мені довелося змусити систему вимкнути живлення. Після перезавантаження система зупиняється на Importing zfs filesystems. Це вже 2 години.

Це було вирішено. Вони важливі в тому, що перед видаленням дедуфільованих томів потрібно вимкнути прапор дедупірування. Це слід робити на рівні пулу, а також на рівні zvol або файлової системи. В іншому випадку видалення по суті дедублюється. Процес потребує часу, оскільки посилається на таблицю дедупликації ZFS. У цьому випадку допомагає оперативна пам’ять. Я тимчасово додав 16 додаткових гігабайт оперативної пам’яті в систему і повернув сервер в Інтернет. Зоопарк імпортувався повністю протягом 4 годин.

Мораль, мабуть, полягає в тому, що дедуп не надто відшліфований і що оперативна пам'ять має важливе значення для його роботи. Я пропоную 24 Гб або більше, залежно від середовища. В іншому випадку залиште вирахування ZFS вимкнено. Це точно не доцільно для домашніх користувачів або менших систем.

Як давно користувач приладів серії Sun / Oracle ZFS 7000, я можу вам сказати, без сумнівів, дедуп не відшліфований. Ніколи не плутайте продажу з доставкою! Продавці скажуть вам "О, це було виправлено". У реальному житті - моєму реальному житті - я можу сказати, що вам не вистачає 24 Гб для обробки "таблиць DDT". Тобто індекс заднього кінця, який зберігає таблицю дедупінгу. Ця таблиця повинна знаходитися в системній пам'яті, щоб кожен вхід / вивід перехоплювався під час польоту, щоб зрозуміти, чи потрібно його записати на диск чи ні. Чим більший пул вашої пам’яті, тим більше змін даних, тим більша ця таблиця - і більший попит на системну пам’ять. Ця пам’ять надходить за рахунок ARC (кеш-пам'яті), а часом і самої ОС - саме тому ви відчуваєте висі, як певні команди трапляються на передньому плані, деякі на задньому плані. Здається, видалення пулу відбувається на передньому плані, якщо ви не скажете це інше в CLI. Майстри GUI цього не робитимуть.

Навіть масове видалення даних NFS у межах загальної частки, визначеної на виведеному томі, призведе до того, що ваша система буде наполовину, якщо у вас немає достатньої пам’яті для обробки «запису» до ZFS, що дозволяє їй видалити дані.

Загалом, якщо ви не збільшите свою пам'ять і навіть тоді, знайдіть спосіб резервування пам'яті для ОС, обмеживши ARC і DDT (і я не думаю, що ви можете обмежувати DDT за своєю природою, це просто індекс, прив'язаний точно до вашого вводу / виводу) - тоді ви піддаються шлангу під час великих делетів або золотових басейнів.