С толкова много различни части, които съставляват типичен стек за съхранение, е чудо, че изобщо всичко работи. Нещата обаче работят добре през повечето време. Няколко пъти, когато нещата се объркат, се нуждаем от помощни програми като xfs_repair, за да ни измъкнат от бъркотията.
Нещата могат да се объркат, когато пишете файл и захранването изчезне или има паника в ядрото. Дори данните, които стоят в латентно състояние на диск, могат да се разпадат с течение на времето поради физическата структура на елементите на паметта могат да се променят, това е известно като малко гниене. Във всички случаи се нуждаем от механизъм за:
- Проверката на данните, които се четат, е същата, която е била записана за последно. Това се изпълнява чрез наличие на контролна сума за всеки блок данни и сравняване на контролната сума за този блок, когато се четат данни. Ако контролната сума съвпада, данните не са променени
- Начин за възстановяване на повредени или изгубени данни, или от огледален блок, или от паритетен блок.
Настройка на пясъчника
Нека да настроим testbench да изпълнява рутинна поправка на xfs, вместо да използваме действителни дискове с ценни данни върху него. Ако вече имате счупена файлова система, можете да пропуснете този раздел и да преминете надясно към следващия. Този testbench е съставен от виртуална машина на Ubuntu, към която е свързан виртуален диск, осигуряващ сурово съхранение. Можете да използвате VirtualBox за създаване на виртуална машина и след това да създадете допълнителен диск, който да прикачите към виртуалната машина.
Просто отидете в настройките на вашата VM и под Настройки → Съхранение раздел можете да добавите нов диск към SATA контролера можете да създадете нов диск. Както е показано по-долу, но се уверете, че вашата виртуална машина е изключена, когато направите това.
След като създадете новия диск, включете VM и отворете терминала. Командата lsblk изброява всички налични блокови устройства.
$ lsblksda 8: 0 0 60G 0 диск
├─sda1 8: 1 0 1M 0 част
└─sda2 8: 2 0 60G 0 част /
sdb 8:16 0 100G 0 диск
sr0 11: 0 1 1024M 0 rom
Освен основното блоково устройство sda, където е инсталирана операционната система, сега има ново sdb устройство. Нека бързо да създадем дял от него и да го форматираме с файлова система XFS.
Отворете разделителната програма като основен потребител:
$ разделен -оптимално / dev / sdbНека първо създадем таблица на дяловете с помощта на mklabel, последвано от създаване на един дял от целия диск (който е с размер 107GB). Можете да проверите дали дялът е направен, като го изброите с помощта на командата за печат:
(разделен) mklabel gpt(разделен) mkpart първичен 0 107
(разделен) печат
(разделен) напусна
Добре, сега можем да видим с помощта на lsblk, че под устройството sdb има ново блоково устройство, наречено sdb1.
Нека форматираме това хранилище като xfs и го монтираме в директорията / mnt. Отново направете следните действия като root:
$ mkfs.xfs / dev / sdb1$ mount / dev / sdb1 / mnt
$ df -h
Последната команда ще отпечата всички монтирани файлови системи и можете да проверите дали / dev / sdb1 е монтиран на / mnt.
След това пишем куп файлове като фиктивни данни за дефрагментиране тук:
$ dd ако = / dev / urandom на = / mnt / myfile.txt брой = 1024 bs = 1024Горната команда ще напише файл myfile.txt с размер 1MB. Ако искате, можете автоматично да генерирате повече такива файлове, да ги разпространите в различни директории във файловата система xfs (монтирани на / mnt) и след това да проверите за фрагментация. Използвайте bash или python или който и да е от любимите ви скриптови езици за това.
Проверка и поправяне на грешки
Повредените данни могат безшумно да се промъкнат във вашите дискове без ваше знание. Ако даден блок данни не бъде прочетен и контролната сума не е сравнена, грешката може просто да се появи в грешното време. Когато някой се опитва да получи достъп до данните, в реално време. Вместо това е добра идея да провеждате цялостно сканиране на всички блокове с данни, за да проверявате често гниене на битове или други грешки.
Помощната програма xfs_scrub трябва да изпълни тази задача за вашия. Вдъхновена отчасти от командата за почистване на OpenZFS, тази експериментална функция е достъпна само за xfsprogs версия 4.15.1-1ubuntu1, което не е стабилна версия. Ако погрешно открие грешка, може да ви подведе, че причинявате повреда на данните, вместо да я коригирате! Ако обаче искате да експериментирате с него, можете да го използвате на монтирана файлова система, като използвате командата:
$ xfs_scrub / dev / sdb1Преди да се опитате да поправите повредена файлова система, първо трябва да я демонтирате. Това е, за да се спре приложението от неволно писане във файловата система, когато се предполага, че тя ще бъде оставена на мира.
$ umount / dev / sdb1Поправянето на грешки е толкова просто, колкото и стартирането:
$ xfs_repair / dev / sdb1Основните метаданни винаги се съхраняват като множество копия, дори ако не използвате RAID и ако нещо се обърка със суперблока или inodes, тогава тази команда може да поправи този проблем за вас по всяка вероятност.
Следващи стъпки
Ако често виждате повреда на данните (или дори веднъж, ако изпълнявате нещо критично важно), помислете за подмяна на дисковете, тъй като това може да е ранен индикатор за диск, който е на път да умре.
Ако контролерът се провали или RAID картата се е отказала от живота си, тогава никой софтуер в света не може да поправи файловата система вместо вас. Не искате скъпи сметки за възстановяване на данни и не искате дълги престои, така че наблюдавайте тези SSD и въртящи се плочи!