ИТ База знаний
Курс по Asterisk
Полезно
— Узнать IP — адрес компьютера в интернете
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Калькулятор инсталляции IP — АТС Asterisk
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Проверка файловой системы Linux
Цель данной статьи, чтобы разобраться с тем как поправить незначительные ошибки, возникающие в файловых системах. Файловых систем много, поэтому много различных инструментов для работы с ними. Поэтому будет рассказано об основных инструментах к основным стандартным системам Linux. И рассмотрим несколько инструментов к рекомендованным LPIC файловым системам.
Рассмотрим, так же журналируемые файловые системы и посмотрим индексные дескрипторы.
- Проверка целостности файловой системы;
- Проверка свободного пространства и индексных дескрипторов в файловой системе;
- Исправление проблем файловой системы.
- df , du , fsck , debugfs – общие утилиты для всех Linux систем
- mke2fs , e2fsck , dumpe2fs , tune2fs – утилиты для файловой системы ext
- xfs_check , xfs_repair , xfs_info , xfs_metadump – утилиты для файловой системы xfs
Совершенно понятно, что для других файловых систем есть свои утилиты для работы с данными файловыми сиcтемами.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Первая утилита 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
Данная команда показывает, что и сколько занимает у нас места на жестком диске, а именно размер папок в текущей директории. Если посмотреть вывод данной команды без ключей, то мы увидим список папок в текущей директории и количество блоков, с которым очень неудобно работать. Чтобы перевести данные блоки в человеческий вид, то необходимо дать ключ –h .
А для еще большего удобства, можно установить замечательную утилиту ncdu простой командой.
После установки нужно запустить ncdu . И мы увидим очень красивую картинку.
Но вернемся к стандартной утилите du . С помощью данной утилиты мы можем указать в какой папке необходим просмотр папок и вывод их размера.
К сожалению данная утилита умеет взвешивать вес только каталогов и не показывает размер файлов. Для того, чтобы посмотреть размер файлов, мы конечно же можем воспользоваться командой ls –l . А также если мы запустим данную команду с ключем –i мы увидим номера inode файлов.
Как вы видите у каждой папки и у каждого файла есть свой индексный дескриптор.
Далее команды, которые нам позволят проверить целостность файловой системы.
Как написано в описании утилиты она позволяет проверять и чинить Linux файловую систему.
Мы можем видеть, например, в oперационной системе Windows, что в случае некорректного завершения работы операционной системы, операционная система запускает утилиту проверки целостности checkdisk . В случае необходимости данная утилита исправляет найденные ошибки в файловой системе. Следовательно, в Linux данные операции выполняет утилита fsck , причем может работать с различными файловыми системами Linux операционных систем. Мы можем попробовать воспользоваться утилитой fsck /dev/sdc1 . В ответ от операционной системы мы получим следующее:
Как мы видим операционная система вернула в ответ на команду для работы с данным разделом, что данный раздел с монтирован и операция прервана. Аналогичную ситуацию мы будем наблюдать в операционной системе Windows, если мы будем пытаться рабочий раздел проверить на ошибки. Т.е возникнет следующая ситуация. Если мы будем проверять дополнительный логический диск, где не установлена операционная система Windows, то данный раздел на время проведения тестов будет отключен и будут идти проверки. А если мы попытаемся проверить основной раздел, куда установлена операционная система Windows, то операционная система не сможет запустить данную утилиту и попросит перезагрузиться для запуска данной утилиты. В нашем случае придется делать точно так же. Поэтому, чтобы проверить необходимо отключить (от монтировать раздел) и после уже этого запускать утилиту.
Из вывода можно заметить утилита пыталась запустить другую утилиту e2fsck , которая в данном случае отвечает за проверку файловых систем ext\ext2\ext3\ext4 . О чем достаточно подробно написано в описании данной утилиты. По сути fsck запускает утилиту ту, которая идет в пакете утилит для конкретной файловой системы. Бывает такое, что fsck не может определить тип файловой системы.
Для того, чтобы утилита все-таки проверила файловую систему, необходимо отмонтировать логический раздел. Воспользуемся командой umount /mnt .
И запускаем непосредственно саму проверку fsck –t ext4 /dev/sdc1
Проходит проверка моментально. Команда fsck запустилась и запустила необходимую утилиту для файловой системы. По результатам проверки файловая система чистая, найдено 11 файлов и 66753 блока. При обнаружении проблем, утилита предложила нам исправить.
Для того, чтобы посмотреть на проверку другой файловой системы, необходимо переформатировать раздел.
При попытке запуска проверки без указания типа файловой системы 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 и видим кучу опций.
Можно попросить данную утилиту вывести содержимое нашего тома.
В результате данной команды мы увидим 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
Мы получим следующий вывод информации.
Данный вывод был сделан на стандартный вывод – т.е экран. Сделаем вывод в файл, например:
Мы можем просмотреть информацию в выведенную в файл поэкранно с помощью less /tmp/output.txt
В выводе мы сможем увидеть основные опции данной файловой системы.
Переделаем файловую систему, текущую ext4 в ext2 . Это можно сделать 3-мя способами с помощью утилит: mkfs , mke2fs , mkfs . ext2 . Перед переформатирование необходимо отмонтировать файловую систему. После форматирования и перемонтируем. Опять снимаем дамп и передаем по конвееру на команду grep чтобы посмотреть features . Получаем следующее:
И видим, что файловые системы отличаются, более новая файловая система имеет фишку журналирования has_jounal . Данная опция так же присутствует в ext3 . Т.е в данных файловых системах имеются журналы с помощью которых удобно восстанавливать.
Есть интересная утилита tune2fs – настраивать файловую систему.
Данная утилита, как следует из описания настраивает настраиваемые параметры файловых систем. Например, у нас есть не журналируемая файловая система ext2 . Мы даем команду tune2fs –O has_journal /dev/sdc1 . Данная утилита добавляет опцию ведения журнала к файловой системе ext2 . Или можем наоборот сказать удалить опцию поставив значок ^ .
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Источник
stat(2) — Linux man page
stat, fstat, lstat — get file status
Synopsis
int stat(const char *path, struct stat *buf);
int fstat(int fd, struct stat *buf);
int lstat(const char *path, struct stat *buf);
Feature Test Macro Requirements for glibc (see feature_test_macros(7)): lstat(): _BSD_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
|| /* Since glibc 2.10: */ _POSIX_C_SOURCE >= 200112L
Description
These functions return information about a file. No permissions are required on the file itself, but-in the case of stat() and lstat() — execute (search) permission is required on all of the directories in path that lead to the file.
stat() stats the file pointed to by path and fills in buf.
lstat() is identical to stat(), except that if path is a symbolic link, then the link itself is stat-ed, not the file that it refers to.
fstat() is identical to stat(), except that the file to be stat-ed is specified by the file descriptor fd.
All of these system calls return a stat structure, which contains the following fields: The st_dev field describes the device on which this file resides. (The major(3) and minor(3) macros may be useful to decompose the device ID in this field.)
The st_rdev field describes the device that this file (inode) represents.
The st_size field gives the size of the file (if it is a regular file or a symbolic link) in bytes. The size of a symbolic link is the length of the pathname it contains, without a terminating null byte.
The st_blocks field indicates the number of blocks allocated to the file, 512-byte units. (This may be smaller than st_size/512 when the file has holes.)
The st_blksize field gives the «preferred» blocksize for efficient file system I/O. (Writing to a file in smaller chunks may cause an inefficient read-modify-rewrite.)
Not all of the Linux file systems implement all of the time fields. Some file system types allow mounting in such a way that file and/or directory accesses do not cause an update of the st_atime field. (See noatime, nodiratime, and relatime in mount(8), and related information in mount(2).) In addition, st_atime is not updated if a file is opened with the O_NOATIME; see open(2).
The field st_atime is changed by file accesses, for example, by execve(2), mknod(2), pipe(2), utime(2) and read(2) (of more than zero bytes). Other routines, like mmap(2), may or may not update st_atime.
The field st_mtime is changed by file modifications, for example, by mknod(2), truncate(2), utime(2) and write(2) (of more than zero bytes). Moreover, st_mtime of a directory is changed by the creation or deletion of files in that directory. The st_mtime field is not changed for changes in owner, group, hard link count, or mode.
The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.).
The following POSIX macros are defined to check the file type using the st_mode field: S_ISREG(m)
is it a regular file?
FIFO (named pipe)?
symbolic link? (Not in POSIX.1-1996.)
socket? (Not in POSIX.1-1996.) The following flags are defined for the st_mode field: The set-group-ID bit (S_ISGID) has several special uses. For a directory it indicates that BSD semantics is to be used for that directory: files created there inherit their group ID from the directory, not from the effective group ID of the creating process, and directories created there will also get the S_ISGID bit set. For a file that does not have the group execution bit (S_IXGRP) set, the set-group-ID bit indicates mandatory file/record locking.
The sticky bit (S_ISVTX) on a directory means that a file in that directory can be renamed or deleted only by the owner of the file, by the owner of the directory, and by a privileged process.
Return Value
On success, zero is returned. On error, -1 is returned, and errno is set appropriately.
Errors
Search permission is denied for one of the directories in the path prefix of path. (See also path_resolution(7).)
Too many symbolic links encountered while traversing the path. ENAMETOOLONG path is too long. ENOENT
A component of path does not exist, or path is an empty string.
Out of memory (i.e., kernel memory). ENOTDIR A component of the path prefix of path is not a directory. EOVERFLOW path or fd refers to a file whose size, inode number, or number of blocks cannot be represented in, respectively, the types off_t, ino_t, or blkcnt_t. This error can occur when, for example, an application compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size exceeds (1
Conforming To
These system calls conform to SVr4, 4.3BSD, POSIX.1-2001.
According to POSIX.1-2001, lstat() on a symbolic link need return valid information only in the st_size field and the file-type component of the st_mode field of the stat structure. POSIX.-2008 tightens the specification, requiring lstat() to return valid information in all fields except the permission bits in st_mode.
Use of the st_blocks and st_blksize fields may be less portable. (They were introduced in BSD. The interpretation differs between systems, and possibly on a single system when NFS mounts are involved.) If you need to obtain the definition of the blkcnt_t or blksize_t types from , then define _XOPEN_SOURCE with the value 500 or greater (before including any header files).
POSIX.1-1990 did not describe the S_IFMT, S_IFSOCK, S_IFLNK, S_IFREG, S_IFBLK, S_IFDIR, S_IFCHR, S_IFIFO, S_ISVTX constants, but instead demanded the use of the macros S_ISDIR(), etc. The S_IF* constants are present in POSIX.1-2001 and later.
The S_ISLNK() and S_ISSOCK() macros are not in POSIX.1-1996, but both are present in POSIX.1-2001; the former is from SVID 4, the latter from SUSv2.
UNIX V7 (and later systems) had S_IREAD, S_IWRITE, S_IEXEC, where POSIX prescribes the synonyms S_IRUSR, S_IWUSR, S_IXUSR.
Other systems Values that have been (or are) in use on various systems: A sticky command appeared in Version 32V AT&T UNIX.
Notes
Since kernel 2.5.48, the stat structure supports nanosecond resolution for the three file timestamp fields. Glibc exposes the nanosecond component of each field using names of the form st_atim.tv_nsec if the _BSD_SOURCE or _SVID_SOURCE feature test macro is defined. These fields are specified in POSIX.1-2008, and, starting with version 2.12, glibc also exposes these field names if _POSIX_C_SOURCE is defined with the value 200809L or greater, or _XOPEN_SOURCE is defined with the value 700 or greater. If none of the aforementioned macros are defined, then the nanosecond values are exposed with names of the form st_atimensec. On file systems that do not support subsecond timestamps, the nanosecond fields are returned with the value 0.
On Linux, lstat() will generally not trigger automounter action, whereas stat() will (but see fstatat(2)).
For most files under the /proc directory, stat() does not return the file size in the st_size field; instead the field is returned with the value 0.
Underlying kernel interface Over time, increases in the size of the stat structure have led to three successive versions of stat(): sys_stat() (slot __NR_oldstat), sys_newstat() (slot __NR_stat), and sys_stat64() (new in kernel 2.4; slot __NR_stat64). The glibc stat() wrapper function hides these details from applications, invoking the most recent version of the system call provided by the kernel, and repacking the returned information if required for old binaries. Similar remarks apply for fstat() and lstat().
Example
The following program calls stat() and displays selected fields in the returned stat structure.
Источник
