Перейти к основному содержимому

Стандарты оформления

Рекомендации по структуре и оформлению страниц технической wiki в этом проекте. Единый стиль упрощает навигацию и правки.

Структура каждого файла и основы Markdown описаны в руководстве по Markdown. Здесь — пример хорошо оформленной страницы и перечень использованных приёмов.

Пример хорошо оформленной страницы

Ниже приведён полный код страницы на техническую тему («Проверка диска в Linux»). В ней использованы основные элементы Markdown и фичи Docusaurus. Как эта страница выглядит на сайте, можно посмотреть на странице-примере.

Код страницы

---
sidebar_position: 7
title: Страница-пример оформления
description: Пример технической страницы wiki с идеальным оформлением по правилам проекта.
---

# Проверка диска в Linux

Краткая шпаргалка по проверке состояния дисков и файловых систем в Linux. Подходит для быстрого поиска команд и типовых сценариев.

## Когда нужна проверка

- После сбоев питания или принудительного выключения.
- Перед важными обновлениями или миграцией данных.
- При появлении сообщений об ошибках в логах (например, `dmesg`).
- По регламенту обслуживания (ежемесячно/ежеквартально).

:::tip
Проверку файловой системы лучше выполнять при **размонтированном** разделе. Для корневого раздела — с загрузочного носителя или в режиме восстановления.
:::

## Основные команды

### Проверка диска (SMART)

Команда `smartctl` из пакета *smartmontools*:

```bash
# Краткая информация о диске
sudo smartctl -i /dev/sda

# Быстрый тест
sudo smartctl -t short /dev/sda

# Результаты теста (через несколько минут)
sudo smartctl -a /dev/sda
```

:::note[Разделы и диски]
`/dev/sda` — весь диск; `/dev/sda1` — первый раздел. Для NVMe диски обычно называются `/dev/nvme0n1`, разделы — `/dev/nvme0n1p1`.
:::

### Проверка файловой системы

| ФС | Команда | Примечание |
|----------|----------------|--------------------------------|
| ext4 | `e2fsck` | С размонтированным разделом |
| XFS | `xfs_repair` | Только с размонтированного |
| btrfs | `btrfs check` | Возможна проверка при монтировании (read-only) |

:::danger
Не запускайте `e2fsck` на **смонтированной** в режиме записи файловой системе — возможна потеря данных. Для корня используйте `fsck` из recovery или live-носитель.
:::

Пример для ext4:

```bash
# Размонтировать раздел (если не корневой)
sudo umount /dev/sda2

# Проверка ( -n — только проверка, без исправлений; -f — принудительно )
sudo e2fsck -n /dev/sda2
# или с исправлением:
sudo e2fsck -f -y /dev/sda2
```

## Рекомендации

1. **Перед проверкой** по возможности сделайте резервную копию важных данных.
2. **Логи** сохраняйте: перенаправьте вывод в файл или используйте `tee`.
3. **После проверки** при необходимости перемонтируйте раздел или перезагрузите систему.

:::info
Подробнее о параметрах команд см. в `man smartctl`, `man e2fsck`, `man xfs_repair`.
:::

---

**См. также:** [руководство по Markdown](./markdown-guide), [стандарты оформления](./style-guide).

Что использовано в примере

ЭлементНазначение
Front mattersidebar_position, title, description — порядок в сайдбаре и метаданные.
Один H1Заголовок страницы «Проверка диска в Linux».
H2 и H3Логичная иерархия разделов.
Маркированные спискиПеречень ситуаций «Когда нужна проверка».
Нумерованный списокПошаговые рекомендации.
Admonitions:::tip, :::note[Заголовок], :::danger, :::info — подсказки и предупреждения.
Блоки кодаС указанием языка ```bash для команд.
Инлайн-код`smartctl`, `dmesg`, `e2fsck` и т.д.
ТаблицаСравнение ФС и команд.
ВыделениеЖирный и курсив в тексте.
СсылкиВнутренние ссылки на другие страницы в конце.
Горизонтальная линия--- перед блоком «См. также».

Оформление опасных символов (угловые и фигурные скобки в командах и путях) в примере не требуется — везде использованы обратные кавычки или обычный текст. Если в вашей теме встречаются плейсхолдеры вида `path` или `USER`, придерживайтесь правил из раздела про опасные символы в руководстве по Markdown.

Страница-пример на сайте

Отдельная страница-пример содержит тот же контент в виде готовой страницы. Откройте её, чтобы увидеть, как всё это выглядит в собранной документации. Её можно использовать как шаблон при создании новых статей.