По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Цель данной статьи, чтобы разобраться с тем как поправить незначительные ошибки, возникающие в файловых системах. Файловых систем много, поэтому много различных инструментов для работы с ними. Поэтому будет рассказано об основных инструментах к основным стандартным системам Linux. И рассмотрим несколько инструментов к рекомендованным LPIC файловым системам. Рассмотрим, так же журналируемые файловые системы и посмотрим индексные дескрипторы.
Проверка целостности файловой системы;
Проверка свободного пространства и индексных дескрипторов в файловой системе;
Исправление проблем файловой системы.
Список утилит:
df, du, fsck, debugfs – общие утилиты для всех Linux систем
mke2fs, e2fsck, dumpe2fs, tune2fs – утилиты для файловой системы ext
xfs_check, xfs_repair, xfs_info, xfs_metadump – утилиты для файловой системы xfs
Совершенно понятно, что для других файловых систем есть свои утилиты для работы с данными файловыми сиcтемами.
Первая утилита df:
man df
Данная утилита показывает использование дискового пространства. У данной утилиты достаточно много ключей. Её особенностью является то, что она показывает дисковое пространство в 1 кбайт блоках.
Данные цифры не очень понятны и удобны, для того чтобы было удобно можно использовать ключ –h и тогда вид станет удобно читаемым. В выводе команды мы сразу видим размер, сколько использовано, процент использование и точка монтирования. Как мы видим на новом перемонтированном разделе /dev/sdc1 занят 1% дискового пространства. Если посмотреть в папку монтирования раздела, то мы увидим там папку lost+found. Данная папка пуста, но занимает 37 МБ. Есть такое понятие индексные дескрипторы в журналируемых файловых системах inode. Inode – это метка идентификатора файла или по другому индексный дескриптор. В этих индексных дескрипторах хранится информация о владельце, типе файла, уровне доступа к нему. И нужно понимать, что для каждого файла создается свой отдельный inode. Команда df –I может показать нам inode.
Число, например, inode напротив /dev/sda2 показывает сколько inode всего может быть на устройстве, далее сколько используется и сколько свободно. Обычно под inode отдается примерно 1% жесткого диска. И получается, что больше чем число inode на устройстве файлов и папок быть не может. Количество inode зависит от типа файловой системы. Далее мы рассмотрим, как пользоваться inode.
Следующая команда du
man du
Данная команда показывает, что и сколько занимает у нас места на жестком диске, а именно размер папок в текущей директории. Если посмотреть вывод данной команды без ключей, то мы увидим список папок в текущей директории и количество блоков, с которым очень неудобно работать. Чтобы перевести данные блоки в человеческий вид, то необходимо дать ключ –h.
А для еще большего удобства, можно установить замечательную утилиту ncdu простой командой.
sudo apt install ncdu –y
После установки нужно запустить ncdu. И мы увидим очень красивую картинку.
Но вернемся к стандартной утилите du. С помощью данной утилиты мы можем указать в какой папке необходим просмотр папок и вывод их размера.
du –h /home
К сожалению данная утилита умеет взвешивать вес только каталогов и не показывает размер файлов. Для того, чтобы посмотреть размер файлов, мы конечно же можем воспользоваться командой ls –l. А также если мы запустим данную команду с ключем –i мы увидим номера inode файлов.
Как вы видите у каждой папки и у каждого файла есть свой индексный дескриптор.
Далее команды, которые нам позволят проверить целостность файловой системы.
Команда fsck
man fsck
Как написано в описании утилиты она позволяет проверять и чинить Linux файловую систему.
Мы можем видеть, например, в oперационной системе Windows, что в случае некорректного завершения работы операционной системы, операционная система запускает утилиту проверки целостности checkdisk. В случае необходимости данная утилита исправляет найденные ошибки в файловой системе. Следовательно, в Linux данные операции выполняет утилита fsck, причем может работать с различными файловыми системами Linux операционных систем. Мы можем попробовать воспользоваться утилитой fsck /dev/sdc1. В ответ от операционной системы мы получим следующее:
Как мы видим операционная система вернула в ответ на команду для работы с данным разделом, что данный раздел с монтирован и операция прервана. Аналогичную ситуацию мы будем наблюдать в операционной системе Windows, если мы будем пытаться рабочий раздел проверить на ошибки. Т.е возникнет следующая ситуация. Если мы будем проверять дополнительный логический диск, где не установлена операционная система Windows, то данный раздел на время проведения тестов будет отключен и будут идти проверки. А если мы попытаемся проверить основной раздел, куда установлена операционная система Windows, то операционная система не сможет запустить данную утилиту и попросит перезагрузиться для запуска данной утилиты. В нашем случае придется делать точно так же. Поэтому, чтобы проверить необходимо отключить (от монтировать раздел) и после уже этого запускать утилиту.
Из вывода можно заметить утилита пыталась запустить другую утилиту e2fsck, которая в данном случае отвечает за проверку файловых систем extext2ext3ext4. О чем достаточно подробно написано в описании данной утилиты. По сути fsck запускает утилиту ту, которая идет в пакете утилит для конкретной файловой системы. Бывает такое, что fsck не может определить тип файловой системы.
Для того, чтобы утилита все-таки проверила файловую систему, необходимо отмонтировать логический раздел. Воспользуемся командой umount /mnt.
И запускаем непосредственно саму проверку fsck –t ext4 /dev/sdc1
Проходит проверка моментально. Команда fsck запустилась и запустила необходимую утилиту для файловой системы. По результатам проверки файловая система чистая, найдено 11 файлов и 66753 блока. При обнаружении проблем, утилита предложила нам исправить.
Для того, чтобы посмотреть на проверку другой файловой системы, необходимо переформатировать раздел.
mkfs –t xfs –f /dev/sdc1
При попытке запуска проверки без указания типа файловой системы fsck /dev/sdc1
Как мы видим, утилита fsck отказалась проверять или вызывать утилиту, а явно указала на ту которую необходимо использовать в данном случае. Для проверки используем xfs_ncheck /dev/sdc1. А для починки файловой системы xfs_repair /dev/sdc1.
Перемонтируем обратно наш раздел mount /dev/sdc1 /mnt
Теперь можно получить информацию по разделу xfs_info /dev/sdc1
Или сделать дамп файловой системы xfs_metadump /dev/sdc1 dump.db
Переформатируем файловую систему ext4 на разделе обратно /dev/sdc1. Перемонтируем в папку mnt. Создадим текстовый файл с текстом на данном разделе nano /mnt/test.txt
Далее мы можем посмотреть следующую утилиту man debugfs. Данная утилита умеет очень многое: очень много ключей и различных опций. Чистит, удаляет, чинит, работает с inodes.
Зайти в данную утилиту можно debugfs –w /dev/sdc1. Набираем help и видим кучу опций.
Можно попросить данную утилиту вывести содержимое нашего тома.
ls
В результате данной команды мы увидим 2 объекта с номерами их inode. Теперь мы можем сказать rm test.txt и файл будет удален, точнее не сам файл а его индексный дескриптор., если посмотреть опять с помощью команды ls. То будет видно, что количество объектов не изменилось. Следовательно, мы этот файл в журналируемых файловых системах можем восстановить, восстановив его индексный дескриптор. Но только до тех пор, пока на место удаленного файла не был записан другой. Именно поэтому если требуется восстановление информации на диске, рекомендуется немедленно отключить ПК и после этого отдельно подключать носитель информации для процедуры восстановления. Так же на данном принципе основано сокрытие информации в Информационной безопасности, когда на носитель информации в 2 или 3 прохода записываются псевдослучайные данные. Для восстановления данных мы можем использовать команду lsdel. Данная команда показывает удаленные файлы.
В принципе на данном debugfs и основаны многие программы для восстановления данных.
На скриншоте хорошо видно, что был удален 1 inode с номером 12 дата и время, другие параметры. Для выхода используем q. Для восcтановления используем undel test.txt, команда, номер индексного дескриптора и имя файла с которым оно восстановится. Убедиться, что файл на месте можно с помощью команды ls.
Утилита debagfs помогает восстанавливать файлы и вообще работать с файловой системой на низком уровне. Конечно восстанавливать по 1 файлу, это очень трудозатратно. Поэтому вот эти низкоуровневые утилиты используют более современные программы.
Еще одна утилита dumpe2fs. Можно вызвать справку по данной утилите man dumpe2fs
Данная команда делает дамп информации, которая хранится на данных томах. Выполним данную команду для /dev/sdc1
Мы получим следующий вывод информации.
Данный вывод был сделан на стандартный вывод – т.е экран. Сделаем вывод в файл, например:
dumpe2fs /dev/sdc1 > /tmp/output.txt
Мы можем просмотреть информацию в выведенную в файл поэкранно с помощью less /tmp/output.txt
В выводе мы сможем увидеть основные опции данной файловой системы.
Переделаем файловую систему, текущую ext4 в ext2. Это можно сделать 3-мя способами с помощью утилит: mkfs, mke2fs, mkfs.ext2. Перед переформатирование необходимо отмонтировать файловую систему. После форматирования и перемонтируем. Опять снимаем дамп и передаем по конвееру на команду grep чтобы посмотреть features. Получаем следующее:
dumpe2fs /dev/sdc1 | grep features
И видим, что файловые системы отличаются, более новая файловая система имеет фишку журналирования has_jounal. Данная опция так же присутствует в ext3. Т.е в данных файловых системах имеются журналы с помощью которых удобно восстанавливать.
Есть интересная утилита tune2fs – настраивать файловую систему.
man tune2fs
Данная утилита, как следует из описания настраивает настраиваемые параметры файловых систем. Например, у нас есть не журналируемая файловая система ext2. Мы даем команду tune2fs –O has_journal /dev/sdc1. Данная утилита добавляет опцию ведения журнала к файловой системе ext2. Или можем наоборот сказать удалить опцию поставив значок ^.
Уже прошло несколько лет с тех пор, как появился Kotlin, и он преуспевает. Так как Kotlin был создан в качестве замены Java, то его, как и следовало ожидать, во многом сравнивают именно с ним.
Чтобы помочь вам выбрать один из двух языков, я сравню основные аспекты каждого из них.
Вот 8 пунктов, которые я рассмотрю в этой статье:
Синтаксис
Лямбда-выражения
Обработка нулей
Классы предметной области
Глобальные переменные
Параллелизм
Функции расширения
Сообщество
Сравнение синтаксиса
Давайте сначала проведем сравнение базового синтаксиса. Я думаю, что многие из вас, кто читает эту статью, возможно, уже знают кое-что о Java и/или Kotlin, но я все же приведу пример, чтобы мы могли явно их сравнить:
Java
public class HelloClass {
public void FullName(String firstName, String lastName) {
String fullName = firstName + " " + lastName;
System.out.println("My name is : " + fullName);
}
public void Age() {
int age = 21;
System.out.println("My age is : " + age);
}
public static void main(String args[]) {
HelloClass hello = new HelloClass();
hello.FullName("John","Doe");
hello.Age();
}
}
Kotlin
class NameClass {
fun FullName(firstName: String, lastName:String) {
var fullName = "$firstName $lastName"
println("My Name is : $fullName")
}
}
fun Age() {
var age : Int
age = 21
println("My age is: $age")
}
fun main(args: Array) {
NameClass().FullName("John","Doe")
Age()
}
Код не сильно отличается, если не считать небольших различий в синтаксисе методов и классов.
Но реальное различие заключается в том, что Kotlin поддерживает вывод типов, где тип переменной не нужно объявлять. А еще там не нужны точки с запятой ( ; ).
Также можно отметить, что Kotlin не сильно придерживается принципов ООП, в отличие от Java, где все содержится внутри класса. Посмотрите хотя бы на функции Age и main в примере – они не находятся внутри класса.
Kotlin, как правило, имеет меньше строк кола, а вот Java придерживается традиционного подхода и, соответственно, является достаточно многословным.
Одно из преимуществ Kotlin перед Java – он может делать все, используя как традиционный ООП-подход, так и любой другой.
Лямбда-выражения
Если мы заговорили о Java и Kotlin, то мы, конечно же, должны поговорить об их знаменитых лямбда-выражениях. У Kotlin есть встроенная поддержка лямбда-функций (и всегда была), а вот в Java она появилась только в Java 8.
Давайте посмотрим, как они выглядят.
Java
//syntaxes
parameter -> expression
(parameter1, parameter2) -> { code }
//sample usage
ArrayList numbers = new ArrayList();
numbers.add(5);
numbers.add(9);
numbers.forEach( (n) -> { System.out.println(n); } );
Kotlin
//syntax
{ parameter1, parameter2 -> code }
//sample usage
max(strings, { a, b -> a.length < b.length })
В Java скобки не являются обязательными: если есть только один параметр, то они не нужны. Но в Kotlin скобки нужны всегда. Однако, в общем и целом, помимо синтаксиса, различий не так уж и много.
Как по мне, лямбда-функции используются только в качестве методов обратного вызова. Хоть они и имеют гораздо более широкий спектр применений, все же они не очень читабельны, в связи с чем их реже используют. Они, конечно, сократят объем вашего кода, но разобраться в нем потом будет достаточно сложно.
Это вопрос предпочтений, но мне кажется, что намного удобнее, когда скобки используются всегда, как в Kotlin, потому что так код становится более читабельным.
Обработка нулей
В объектно-ориентированном языке значения нулевого типа всегда были проблемой. Когда вы пытаетесь использовать содержимое нулевого значения, выпадает исключение нулевого указателя (NPE - Null Pointer Exception).
Поскольку NPE всегда были проблемой, то и у Java, и у Kotlin есть свой способ обработки нулевых объектов. Как они это делают, я покажу ниже.
Java
Object object = objServ.getObject();
//traditional approach of null checking
if(object!=null){
System.out.println(object.getValue());
}
//Optional was introduced in Java 8 to further help with null values
//Optional nullable will allow null object
Optional
Простое пошаговое руководство, предназначенное для того, чтобы вы поняли, что такое git stash.
Git – это один из обязательных навыков, который нужно иметь на своем счету. Если вы будете хорошо понимать концепции Git, это не только поможет вам эффективно управлять своими изменениями, но и повысит общую продуктивность и облегчит рабочий процесс. Цель этой статьи – рассмотреть одну из немалого числа полезных команд git, а именно git stash.
Я лично нашел для себя эту команду очень полезной.
Вслед за тем, что уже было сказано, давайте расколем этот git!
Возможное развитие событий
Вы когда-нибудь были в ситуации, когда
вы внесли изменения не в ту ветку, но еще не успели их зафиксировать, а теперь хотите как-то перенести эти изменения на нужную ветку?
вы находитесь в процессе добавления нового еще незавершенного изменения, но вам срочно нужно перейти к новой задаче, поскольку у нее более высокий приоритет?
вы хотите получить чистое рабочее дерево по той или иной причине, но не хотите сбрасывать свои изменения?
вы просто хотите сохранить незафиксированные изменения, чтобы иметь возможность потом их просматривать?
В таком случае, вы можете не беспокоиться, потому что git stash поможет вам в этом!
Что такое git stash?
Это команда, с помощью который вы можете сохранять незафиксированные изменения в стеке как в структуре данных. А затем, когда это будет необходимо, вы можете применить эти изменения к вашему рабочему дереву.
Такой подход обеспечивает гибкий рабочий процесс, когда вы работаете над несколькими задачами одновременно.
Команды, которые нужно запомнить
В следующем разделе содержатся различные команды для записи отложенных изменений и мельчайшие подробности, связанные с ними.
Список хранилищ
git stash list
В зависимости от того, есть у вас что-то в хранилище или нет, команда выдаст один из следующих ответов:
пустая строка: нет хранилищ;
проиндексированный список хранилищ: одно или несколько хранилищ.
Более подробная информация о том, как читать этот список, находится в следующем разделе.
Сохранение изменений в хранилище
Рассмотрим следующий вариант развития событий, в котором у нас могут быть два вида изменений, а именно:
изменения в отслеживаемых файлах;
изменения в неотслеживаемых файлах.
Для того, чтобы сохранить изменения в хранилище, нужно просто набрать
git stash
Это создаст следующее хранилище и вернет рабочее дерево к HEAD (заголовку).
Число в фигурных скобках – это индекс конкретного хранилища. В данном случае, так как стек хранилищ был пуст, то это хранилище находится
в верхней части стека, то есть имеет индекс 0.
По мере того, как будут сохраняться новые изменения, индекс предыдущих изменений будет увеличиваться. Все аналогично стеку (FIFO), где вершина стека всегда имеет индекс 0.
«
WIP om main
» означает, что работа проводится на ветке main.
А
eeefba5
и
commit 2
– это идентификатор и сообщение предыдущего коммита соответственно.
Следовательно, резюмируя, общий формат будет выглядеть примерно следующим образом:
stash@{}: WIP on :
Проблема 1
По умолчанию изменения, которые были внесены в неотслеживаемые файлы, не сохраняются. А значит, для того, чтобы добавить их в хранилище, нужно воспользоваться флагом
--include-untracked
. Таким образом вы сможете сохранить в хранилище как неотслеживаемые, так и отслеживаемыми изменениями.
git stash --include-untracked
Проблема 2
Предположим, что мы вносим еще одно изменение в рабочее дерево и сохраняем его в то же хранилище. В результате мы получим хранилище, которое выглядит следующим образом:
На первый взгляд они одинаковы. Это усложняет понимание того, какие изменения с каким отложенным элементом связаны. Появляется необходимость изучить фактические изменения для того, чтобы определить, какое хранилище было использовано.
Полезным будет добавить информативности сообщению. Для того, чтобы это сделать, можно создать свое собственное сообщение, и не использовать сообщение по умолчанию. Чтобы добавить свое собственное сообщение, воспользуйтесь следующей командой
git stash push -m "test message" --include-untracked
Наше хранилище теперь будет выглядеть вот так:
Важно упомянуть
Команда
git stash save
официально считается устаревшей с момента выпуска Git 2.16.0. По этой причине я не буду рассматривать ее в этой статье.
Команды
git stash create
и
git stash store
тоже.
Применение изменений к рабочему дереву
Теперь, когда у нас есть изменения в нашем хранилище, мы можем захотеть применить их где-то. Для этого просто нужно ввести следующую команду:
git stash pop
Есть несколько замечаний касательно поведения этой команды:
она применяет сохраненные изменения из верхней части стека, то есть с индексом хранилища 0;
она удаляет это изменение их хранилища. Следовательно, индексы всех остальных изменений уменьшаются на 1.
Если вы хотите применить изменение под индексом n, то воспользуйтесь следующей командой:
git stash apply stash@{N}
где
N
– это индекс сохраненного изменения, которое вы хотите применить. Один нюанс: эта команда не удаляет примененное изменение из хранилища.
Дополнительное примечание
git stash branch stash@{N}
создает и проверяет новую ветку с именем
, начиная с коммита, в котором изначально был создан
, и применяет изменения, который записаны в
, к новому рабочему дереву и индексу. Если все проходит успешно, и
является ссылкой формы
stash@{}
, то
удаляется.
Удаление сохраненных изменений из хранилища
Если вы считаете, что какое-то изменение, которое вы сохранили до этого в хранилище, стало бесполезным, и вы хотите его удалить, что вы можете воспользоваться следующей командой:
git stash drop stash@{N}
где
N
– это индекс сохраненного изменения, которое вы хотите удалить из хранилища.
Если вы хотите удалить все сохраненные изменения и полностью освободить хранилище, то воспользуйтесь следующей командой:
git stash clear