Коли ви використовуєте ext4, ви можете перевірити наявність несправних блоків за допомогою команди e2fsck -c /dev/sda1 # or whatever. Це дозволить "заблокувати чорний список" блоків, додавши їх до неправильного блоку.
Що таке еквівалент фізичному об'єму LVM2? Файлова система в ній є ext4, але, імовірно, виявлені погані блоки стануть недійсними, оскільки базові установки LVM переміщують дані на фізичному диску.
Іншими словами, як я можу перевірити, чи не погані блоки не використовуються в LVM?
Відповіді:
Коли ви використовуєте ext4, ви можете перевірити наявність неполадок за допомогою команди
e2fsck -c /dev/sda1чи чого завгодно. Це дозволить "заблокувати чорний список" блоків, додавши їх до неправильного блоку.
e2fsck -cпрацює badblocksна базовому жорсткому диску. Ви можете використовувати badblocksкоманду безпосередньо на фізичному томі LVM (якщо припустити, що PV насправді - це жорсткий диск, а не якийсь інший вид віртуального пристрою, наприклад, пристрій RAID з програмним забезпеченням MD), так само як ви використовували цю команду на жорсткому диску що містить файлову систему ext.
Це не додасть будь-якої інформації про поганий блок у файловій системі, але я не думаю, що це корисна функція файлової системи; жорсткий диск повинен обробляти погані блоки.
Навіть краще, ніж badblocksзапускати SMART самотест на диску (замінити /dev/sdXна ім’я пристрою вашого жорсткого диска):
smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less
Тест займе кілька годин (він точно скаже, як довго). Коли це буде зроблено, ви можете запитувати результат smartctl -a, шукати журнал самотестування. Якщо на ньому написано "Успішно завершено", ваш жорсткий диск добре.
Іншими словами, як я можу перевірити, чи не погані блоки не використовуються в LVM?
Як я вже сказав, жорсткий диск сам забезпечить, щоб він не використовував пошкоджені блоки, а також перемістив дані з цих блоків; це не те, що має робити файлова система або LV. З іншого боку, коли на вашому жорсткому диску є декілька поганих блоків, ви не хочете, щоб щось перенесло їх, але ви хочете замінити весь жорсткий диск, оскільки він виходить з ладу.
dd. Частіше, ніж ви могли б подумати, носій насправді прекрасний, а дані просто зіпсовані, тому написання над ним працює добре без необхідності повторного перезапису.
dd" - але ви, мабуть, не повинні. Якщо у вас є mdрейд, він може вирішити питання про вас . @derobert, напевно, буде знати, що робити, коли диск не є частиною mdрейду :)
Я майже впевнений, що LVM не справляється з поганими блоками; він очікує, що базове сховище до. І більшість, якщо не все, сучасні жорсткі диски. Можливо, вам доведеться виконати запис до сектору, але диск повинен перезаписати його. (Можливо, вам знадобиться спочатку зробити офлайн-сканування поверхні, наприклад, smartctl /dev/sda -t offline).
Тим НЕ менше, LVM практично не переміщати дані , якщо ви запитаєте його, з , наприклад, pvmove. Таким чином, ви можете використовувати функцію поганих блоків ext4; вам просто доведеться повторно перевірити наявність поганих блоків, якщо вони запущені pvmove. Жодна загальна операція (наприклад, lvextend) не переміщує дані.
Extend не переміщує дані, оскільки LVM зберігає карту, що говорить "логічні розширення 0–99 - це фізичні розширення 200–299», а потім, коли ви розширюєте їх, він просто додає «логічні розширення 100–199 - це фізичні розширення 100–199». Або навіть "логічні розтяжки 100–149 є фізичними розтяжками 50–99; логічні розтяжки 150–199 - це фізичні розтяжки 140–189». LVM не байдуже, що фізичні розширення не в порядку або не є суміжними.
pvckможе перевірити метадані LVM, після цього послідовність - це завдання файлової системи. LVM стосується лише управління обсягом, тому не потрібно дбати, чи простір, що становить певну міру, поганий, оскільки програмне забезпечення вищого рівня вирішує ці проблеми. Метадані LVM в будь-якому разі займають лише перший (необов'язково і останній сектор) фізичного обсягу.
Якщо тільки перший і останній сектори досить великого ПВ (такого, як ви побачили у виробництві) просто трапляються невдало одночасно, у вас в основному є найкраща удача у світі, оскільки це так астрономічно малоймовірно. В іншому випадку, якщо адміністратор знає, що декілька секторів накопичувача вийшли з ладу, у більшості людей все гаразд із лише подачею таких речей, як це у розділі "жорсткий диск не вдався до кінця і його потрібно замінити".
Якщо pvckповертається помилка, ви можете перевірити, чи зберігаються ваші метадані LVM /etc/lvmдесь. Якщо це так, ви можете зробити pvcreateвказівку резервної копії--restorefile
Синтаксис:
pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>
Приклад:
pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2
Якщо відновлення не працює (наприклад, якщо перший сектор поганий), ви можете повторити вищезазначене, але встановіть --metadatacopies 2(або ви можете просто зробити це), що спробує записати метадані в перший і останні сектори на ПВ. Коли він pvscanпрацює під час завантаження, він перевірятиме обидва місця, і якщо знайде метадані, він перевірить їх на контрольній сумі. Якщо контрольна сума не працює на першому секторі, але успішна в останньому, ви отримаєте повідомлення про помилку.
Різновид ручного і больового характеру, але знову ж таки це є причиною, чому люди раді отримати скорочення управління обсягом за допомогою BTRFS. Здебільшого це не так вже й велика проблема з причин, згаданих деробертом, і тому, що люди, яким абсолютно позитивно потрібно забезпечити безперервність даних, зазвичай роблять RAID і мають стратегію резервного копіювання.
-cробити перед тим , як називати щось повне дурницею.