Как файловая система (ext4) «хранит» информацию TRIM?
Оба жестких диска ad0 и ad1 должны иметь загрузочный код boot0, а срез (раздел MBR) ad1, на котором находится FreeBSD, должен иметь boot1. Это несколько сбивает с толку, но является результатом назад архитектурного решения использовать метки дисков bsd внутри разделов MBR.
Boot0 действительно маленький и динамичный, что позволяет использовать достойные загрузчики других ОС. Обычно boot0 находится в MBR. Boot0 не может читать метки диска, поэтому он просто загружает первый блок (блоки) раздела (фрагмента) и переходит к выполнению этого кода.
Boot1 - это место, где действительно запускается специальный код FreeBSD, память настраивается в режимах, подходящих для ядра FreeBSD, а код boot1 может читать метку диска BSD, находить / и даже читать файловую систему достаточно, чтобы найти файл ядра по имени. Boot1 довольно сложен и выполняет множество операций, включая загрузку большего количества загрузочного кода, модулей, ядра и запуск ядра.
Я предполагаю, что у вас есть примерно такая структура диска:
ad0 - внутренний жесткий диск (boot0)
ad0s1 - первый и единственный раздел (часть) внутреннего жесткого диска, C: \
ad1 - внешний жесткий диск (boot0)
ad1s0 - раздел (фрагмент) FAT или NTFS на внешнем диске, D: \
ad1s1 - FreeBSD раздел (slice) (boot1)
ad1s1a - FreeBSD /
ad1s1b - FreeBSD swap
ad1s1c - FreeBSD / usr
{{1 }} ...
Я заметил, где вам нужны загрузчики boot0 и boot1.
Выполнение этого вручную дает полезные ценные уроки о том, как загружается FreeBSD.Следующие уроки на очереди - это настройка / boot / environment, изменение пользовательского образа, а также выбор и настройка модулей ядра перед загрузкой самого ядра.
Я предполагаю, что вы делаете это в основном в учебных целях и можете быть заинтересованы в сокращении установки. NanoBSD заслуживает внимания.
Я не знаю, хранит ли ext4 его где-нибудь. Другие файловые системы, конечно, нет.
ext4 избегает того, что уже было обрезано в текущем сеансе, только -, пока он еще смонтирован. Когда вы перезагружаетесь или -повторно монтируете файловую систему, она снова и снова удаляет пустое пространство.
Таким образом, это может быть in -структура памяти, которая вообще не сохраняется. Я не погружался в очень хороший исходный код, чтобы выяснить это.
Маленький тест:
# truncate -s 1G /dev/shm/foobar.img
# losetup --find --show /dev/shm/foobar.img
/dev/loop9
# mkfs.ext4 /dev/loop9
# mkdir /mnt/loop
Имея файловую систему 1G, давайте смонтируем и обрежем ее:
# mount /dev/loop9 /mnt/loop/
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed
# fstrim -v /mnt/loop
/mnt/loop: 0 B (0 bytes) trimmed
Итак, он сначала обрезает все... одно это уже подозрительно, ведь :mkfs уже обрезаны (ой ), так что он должен знать, что он все еще пуст и обрезан, верно? Ну, а если знает, то плевать:
# umount /mnt/loop
# mount /dev/loop9 /mnt/loop
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed
Таким образом, после повторного -монтирования все свободное пространство снова обрезается.
При создании и удалении файлов тоже нет точности:
# dd bs=1M count=10 if=/dev/zero of=/mnt/loop/zerofile
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0124641 s, 841 MB/s
# sync
# rm /mnt/loop/zerofile
# fstrim -v /mnt/loop
/mnt/loop: 117.5 MiB (123203584 bytes) trimmed
Таким образом, запись 10M приводит к -подрезке 117M. Это просто ничего не значит.
Только сам SSD действительно знает, что в данный момент обрезано, а что нет, и когда его попросят обрезать уже обрезанную область, он просто ничего не должен делать. Так что никакого вреда и никакой необходимости действительно хранить эту информацию в файловой системе.