Настройка Ubuntu для работы с SSD

[Sly_tom_cat]

werlock, я про ситуацию когда резерв рута не отключен, если вы не поняли.

[werlock]

werlock, я про ситуацию когда резерв рута не отключен, если вы не поняли.

Уже понял. В этом случае да - место вроде бы есть, но оно не ваше.

[Sly_tom_cat]

Так здесь на форуме уже не один десяток тем есть - "где мои гигабайты?"
Люди ходят по этим граблям с резервом рута регулярно и с наслаждением.

[thunderamur]

thunderamur, вот и объясни нам с werlock, что произойдет при выключении пространства для системных нужд EXT4 на не системном разделе? Что такого страшного случится с моей мусоркой?

5% места резервируется для противодействия фрагментации. Если раздел забить под завязку, отключив резервирование, на старых разделах возможны проблемы с производительностью.
Нафига EXT4 для больших разделов с данными, когда есть XFS, которая лучше подходит для этих целей. Зачем ковырять настройки ФС, которая не подходит под задачу (жрет место), вместо того, что юзать то, что работает без лишних телодвижений.

[Sly_tom_cat]

5% места резервируется для противодействия фрагментации.

Откуда такая информация? 

Фрагментация на EXT2-4 есть всегда и она естественно системная, так что про нее даже утилиты не сообщают (т.е. просто врут).

Все пространство EXT разбито на блоки, которые имеют фиксированный размер 32768 секторов (рудимент от самой первой EXT), вы никогда не сможете одним непрерывным куском записать файл длиннее чем эти самые 32768 секторов (на самом деле даже меньще - там в каждом блоке заголовок место отъедает), а для 512-байтного сектора этот размер начинается уже с 16 Мб !!!

Позже (в ext2) разработчики переиграли - не 32768 секторов в блоке, а 32768 кластеров (которые состоят из нескольких секторов) и подняли платку непрерывного пространства в блоке. Но увеличение размера кластера ведет к потерям "на хвостах" (пишешь в файл 4 байта, а он занимает 32Мб ). Поэтому увеличивать его до бесконечности нельзя.

На самом деле они даже дальше пошли - блоки назвали группами блоков, а кластеры - блоками

Таким образом сейчас на ext4, обычно, непрерывным куском можно записать до 2Gb (или меньше), но только сейчас уже HD фильм любой - больше 2Gb...

[thunderamur]

Откуда такая информация? 

Например отсюда
http://unix.stackexchange.com/questions/7950/reserved-space-for-root-on-a-filesystem-why/7965#7965
 

[Sly_tom_cat]

thunderamur, вот те раз, оказывается 5% для рута - это типа мне говорят - а нефиг тебе использовать те 10 гигов (которые и есть 5% от 2Тб раздела). Ай, ай, ай - как бы фрагментации не случилось - пусть лучше 10 гигов так просто пустуют, ага.

У меня только одни вопрос - а почему другие ФС так не поступают? Ведь фрагментация на почти полностью заполненном разделе - это угроза для любой ФС. Почему же остальные не "подстелили соломки" 5% резервом ?

[thunderamur]

Sly_tom_cat,
Ну да, разработчики ФС такие идиоты и просто так сделали 5% резерв по дефолту для EXT4, чтобы люди потом сами "настройкой" занимались. 

[Sly_tom_cat]

Для меня разрабы ext4 - не совсем авторитетные люди, т.к. они так и не смогли отказаться от наследия ext, которая писалась для совсем маленьких дисков. И тянуть внутреннюю структуру разбиения пространства, создававшуюся для небольших дисков, на много-терабайтные тома - это верх идиотизма.

Нет, уже то, что они наконец перешли к выделению места экстантами - это большой шаг (в направлении догнать тех кто к этой идее пришел ранее). Но решать за меня - как распределять место в ФС - это ИМХО уже через край. И таки - да - для корня этот резерв - самое то. Но, блин, кроме как на корень я ext4 никуда не советую использовать.... А еще чутка допилят btrfs - я вообще перестану советовать ext4 использовать, даже для корня - btrfs уже довольно окрепла и вполне надежно на ногах стоит уже сейчас.

[theurs]

Для меня разрабы ext4 - не совсем авторитетные люди, т.к. они так и не смогли отказаться от наследия ext, которая писалась для совсем маленьких дисков. И тянуть внутреннюю структуру разбиения пространства, создававшуюся для небольших дисков, на много-терабайтные тома - это верх идиотизма.

Нет, уже то, что они наконец перешли к выделению места экстантами - это большой шаг (в направлении догнать тех кто к этой идее пришел ранее). Но решать за меня - как распределять место в ФС - это ИМХО уже через край. И таки - да - для корня этот резерв - самое то. Но, блин, кроме как на корень я ext4 никуда не советую использовать.... А еще чутка допилят btrfs - я вообще перестану советовать ext4 использовать, даже для корня - btrfs уже довольно окрепла и вполне надежно на ногах стоит уже сейчас.

Что вам ext4 сделала Ж) у нее нет никаких ярко выраженных минусов и работает стабильно, в отличии от btrfs/ По-моему пока нет никакого смысла использовать что то кроме ext4 с параметрами по умолчанию, если сильно хочется забить диск на все 100% можно отменить резервирование 5% для рута.

[Sly_tom_cat]

theurs, я уже перечислили минусы - прочтите внимательно мои предыдущие посты. Из того, что я еще не упоминал - это 1,8% занятого пространства сразу под служебные нужды (у XFS - 0,06%, у btrfs - порядка 0,05%) и фиксированное при создании (можно только уменьшить, но нельзя увеличить) число inode (что означает, что их либо много лишних - неиспользуемых, либо вы не можете записать на ФС, где есть достаточно свободного места, но нет больше свободных inode). И у XFS и у btrfs - inode-ы выделяются по требованию и неиспользуемые утилизируются (место из под них помечается как свободное).

Но!, я кроме минусов, отмечаю, и продолжаю отмечать, что на данный момент, для корня, ext4 - наиболее оптимальный вариант (причем, именно с параметрами по умолчанию).

А вот для раздела с данными - меня не напрягают 5% резерва рута - я знаю как их отключить, но напрягают почти 2% под системные нужды: заголовки групп блоков, преалокированные inode и море резервных суперблоков (btrfs имеет только 2-е копии суперблоков и то, если ssd, то вторая копия отключается, у XFS формально 4 или 8 allocation groups в каждой есть копия общих данных о ФС, но там есть и свои данные группы распределения, так что там нет полноценных копий суперблока вообще). Напрягают и маленькие максимальные куски для распределения файлов 2GB или даже меньше на порядки (Xfs размещает одним куском файл размером 1/4 от размера ФС, а btrfs вообще почти на весь размер фс может файл непрерывным куском записать).

Но главное, что мне не нравится в EXT4 - это то вранье, которое выдают утилиты о дефрагментированности файловой системы.
Там любой файл больше 2GB просто не может быть записан единым куском - однако такое просто не считается при расчете фрагментации (проверял). И такой обман мне неприятен чисто по-человечески.

[theurs]

Хм... говоришь ext4 больше пустоты пожирает?

root@debian:/etc/apt# dd if=/dev/zero of=/mnt/500/ext4.img bs=1M count=2048
2048+0 записей считано
2048+0 записей написано
 скопировано 2147483648 байт (2,1 GB), 11,6293 c, 185 MB/c

root@debian:/etc/apt# dd if=/dev/zero of=/mnt/500/btrfs.img bs=1M count=2048
2048+0 записей считано
2048+0 записей написано
 скопировано 2147483648 байт (2,1 GB), 12,0298 c, 179 MB/c

root@debian:/etc/apt# mkfs.ext4 -m 0 /mnt/500/ext4.img
mke2fs 1.42.5 (29-Jul-2012)
/mnt/500/ext4.img is not a block special device.
Proceed anyway? (y,n) y
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
131072 inodes, 524288 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=536870912
16 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

root@debian:/etc/apt# mkfs.btrfs /mnt/500/btrfs.img

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /mnt/500/btrfs.img
        nodesize 4096 leafsize 4096 sectorsize 4096 size 2.00GB
Btrfs Btrfs v0.19

root@debian:/etc/apt# mount /mnt/500/ext4.img /mnt/1
root@debian:/etc/apt# mount /mnt/500/btrfs.img /mnt/2

root@debian:/etc/apt# df -h
Файловая система                                       Размер Использовано  Дост Использовано% Cмонтировано в
rootfs                                                    71G         4,6G   63G            7% /
udev                                                      10M            0   10M            0% /dev
tmpfs                                                     99M         8,9M   90M            9% /run
/dev/disk/by-uuid/efba35d8-e697-408f-bbc3-2505a0434f86    71G         4,6G   63G            7% /
tmpfs                                                    5,0M            0  5,0M            0% /run/lock
tmpfs                                                    825M            0  825M            0% /run/shm
/dev/sdb1                                                459G         337G  123G           74% /mnt/500
/dev/loop0                                               2,0G          56K  1,8G            1% /mnt/2
/dev/loop1                                               2,0G          67M  2,0G            4% /mnt/1

root@debian:/etc/apt# dd if=/dev/zero of=/mnt/1/test.bin bs=1M
dd: запись «/mnt/1/test.bin»: На устройстве кончилось место
1949+0 записей считано
1948+0 записей написано
скопировано 2043482112 байт (2,0 GB), 14,8819 c, 137 MB/c

root@debian:/etc/apt# dd if=/dev/zero of=/mnt/2/test.bin bs=1M
dd: запись «/mnt/2/test.bin»: На устройстве кончилось место
1816+0 записей считано
1815+0 записей написано
скопировано 1903427584 байта (1,9 GB), 13,5653 c, 140 MB/c

Как жи так то а?

[thunderamur]

И таки - да - для корня этот резерв - самое то. Но, блин, кроме как на корень я ext4 никуда не советую использовать.... А еще чутка допилят btrfs - я вообще перестану советовать ext4 использовать, даже для корня - btrfs уже довольно окрепла и вполне надежно на ногах стоит уже сейчас.

Так и я о том же, ext4 только для корня. А для данных и чего-то там отключать - нафиг! Лучше другую ФС заюзать.
А я уже btrfs использую, но пока для серверов не стал бы использовать, все-таки нужно время, чтобы убедиться.
Пользователь решил продолжить мысль [time]28 Декабрь 2015, 14:03:28[/time]:

Что вам ext4 сделала Ж) у нее нет никаких ярко выраженных минусов и работает стабильно, в отличии от btrfs/ По-моему пока нет никакого смысла использовать что то кроме ext4 с параметрами по умолчанию, если сильно хочется забить диск на все 100% можно отменить резервирование 5% для рута.

1. У тебя были проблемы с btrfs на ядрах 4.х ?
Я, пока что не долго пользую btrfs, всего несколько месяцев, но зато на нескольких устройствах - без проблем. Несколько лет назад проблемы были, но ЕМНИП там больше всего бесила тупизна при работе пакетной системы.
2. Смысл есть хотя бы в том, что btrfs умеет сжатие на лету и место экономит. А также быстрее работает. Та же загрузка с ЖД на btrfs со сжатием занимает 14 секунд, на ext4 - 20 (я на форуме создавал тему с отчетом)? Т.е. в 1.5 раза быстрее. Соответственно и другие операции с ФС во время работы будут проходить быстрее. Читал пост на форуме, где товарищ сообщал, что библиотека в аудиоплеере создается значительно быстрее на btrfs.
3. Кроме того, это тема про SSD. А btrfs имеет специальный алгоритм работы с SSD (даже не считая сжатия).
Пользователь решил продолжить мысль 28 Декабря 2015, 07:12:50:

root@debian:/etc/apt# dd if=/dev/zero of=/mnt/2/test.bin bs=1M
dd: запись «/mnt/2/test.bin»: На устройстве кончилось место
1816+0 записей считано
1815+0 записей написано
скопировано 1903427584 байта (1,9 GB), 13,5653 c, 140 MB/c

Как жи так то а?

EXT4 значит тюнил, а для btrfs даже сжатие не включил. С /dev/zero результаты будут очень интересные
Ну а если серьезно, то, например, корень сжимается в 1.5 раза.

[theurs]

И таки - да - для корня этот резерв - самое то. Но, блин, кроме как на корень я ext4 никуда не советую использовать.... А еще чутка допилят btrfs - я вообще перестану советовать ext4 использовать, даже для корня - btrfs уже довольно окрепла и вполне надежно на ногах стоит уже сейчас.

Так и я о том же, ext4 только для корня. А для данных и чего-то там отключать - нафиг! Лучше другую ФС заюзать.
А я уже btrfs использую, но пока для серверов не стал бы использовать, все-таки нужно время, чтобы убедиться.
Пользователь решил продолжить мысль [time]28 Декабрь 2015, 14:03:28[/time]:

Что вам ext4 сделала Ж) у нее нет никаких ярко выраженных минусов и работает стабильно, в отличии от btrfs/ По-моему пока нет никакого смысла использовать что то кроме ext4 с параметрами по умолчанию, если сильно хочется забить диск на все 100% можно отменить резервирование 5% для рута.

1. У тебя были проблемы с btrfs на ядрах 4.х ?
Я, пока что не долго пользую btrfs, всего несколько месяцев, но зато на нескольких устройствах - без проблем. Несколько лет назад проблемы были, но ЕМНИП там больше всего бесила тупизна при работе пакетной системы.
2. Смысл есть хотя бы в том, что btrfs умеет сжатие на лету и место экономит. А также быстрее работает. Та же загрузка с ЖД на btrfs со сжатием занимает 14 секунд, на ext4 - 20 (я на форуме создавал тему с отчетом)? Т.е. в 1.5 раза быстрее. Соответственно и другие операции с ФС во время работы будут проходить быстрее. Читал пост на форуме, где товарищ сообщал, что библиотека в аудиоплеере создается значительно быстрее на btrfs.
3. Кроме того, это тема про SSD. А btrfs имеет специальный алгоритм работы с SSD (даже не считая сжатия).
Пользователь решил продолжить мысль [time]28 Декабрь 2015, 08:12:50[/time]:

root@debian:/etc/apt# dd if=/dev/zero of=/mnt/2/test.bin bs=1M
dd: запись «/mnt/2/test.bin»: На устройстве кончилось место
1816+0 записей считано
1815+0 записей написано
скопировано 1903427584 байта (1,9 GB), 13,5653 c, 140 MB/c

Как жи так то а?

EXT4 значит тюнил, а для btrfs даже сжатие не включил. С /dev/zero результаты будут очень интересные
Ну а если серьезно, то, например, корень сжимается в 1.5 раза.

4.+ ядра в дебиан завезут лет через 5 наверное Ж)

Так мы говорим о системном разделе или о данных? Если все же о данных то там 99% лежат несжимаемые данные, фото, видео, музыка, архивы.

/dev/zero на btrfs с сжатием пробовал, несколько раз точка монтирования повисла, то есть при любом обращении к ней любое приложение повисало на неопределенное время. Нестабильная штука однако.

EXT4 не тюнил, всё по умолчанию кроме объема зарезервированного для рута, на диске с данными оно не нужно.

зы попробовал всё то же самое но размер 10гб и файл не один с нулями а много размером от 16кб до 8мб с случайным содержимым из генератора случайных чисел, получился тот же результат. EXT4 не отжирает 1.8% и даже наоборот более эффективно размещает данные на диске.

Код: [Выделить]

Файловая система                                       Тип      Размер Использовано  Дост Использовано% Cмонтировано в
rootfs                                                 rootfs      71G         4,6G   63G            7% /
udev                                                   devtmpfs    10M            0   10M            0% /dev
tmpfs                                                  tmpfs       99M         8,9M   90M            9% /run
/dev/disk/by-uuid/efba35d8-e697-408f-bbc3-2505a0434f86 ext4        71G         4,6G   63G            7% /
tmpfs                                                  tmpfs      5,0M            0  5,0M            0% /run/lock
tmpfs                                                  tmpfs      825M            0  825M            0% /run/shm
/dev/sdb1                                              ext4       459G         354G  105G           78% /mnt/500
/dev/loop1                                             ext4       9,9G         9,9G     0          100% /mnt/1
/dev/loop0                                             btrfs       10G         8,1G     0          100% /mnt/2
Пользователь решил продолжить мысль 28 Декабря 2015, 08:29:25:И еще раз с сжатием. Никакой разницы для несжимаемых данных.

mount -o compress=lzo /mnt/500/btrfs.img /mnt/2

Код: [Выделить]

/dev/loop0                                             btrfs       10G         8,1G   72K          100% /mnt/2


[thunderamur]

А btrfs даже не пытается жать не сжимаемые.

Для данных потести ещё XFS