Компрессор — это разновидность динамического процессора. Динамика звука — это как меняется его интенсивность со временем.
Компрессор громкие делает значительно тише, тихие делает немножко тише, в результате уровень выравнивается, но некоторая разница всё равно остаётся. Кроме компрессора бывают лимитер (просто ограничивает громкость не выше определённой), гейт (всё, что тише определённого уровня, убирает), экспандер (компрессор наоборот), комбинации перечисленных.
забыл про тяжёлую артиллерию. Поверх образа убитой ФС — mkfs -S с теми же параметрами какие были, он создаст ФС, но не инициализирует таблицы инод. После этого fsck может найти «внезапно уже имеющиеся в новой ФС данные».
Потому что так работает block allocator. Весь диск разбивается на блок-группы (по умолчанию 128 Мб), и каждый файл система старается разместить целиком в одной block group, и пытается выбрать именно ту группу, в которой расположена его inode и директория, и только если block group заполнена — то уже блоки идут в другую.
А теперь представьте, как будут расположены файлы, записанные в почти полную ФС.
Итак, рассмотрим сценарий внимательнее.
Мы сделали 150 Гб e4, забили её под завязку. Она фрагментировалась.
Теперь её всю, не изменяя, мы переносим «назад».
Потом мы «растягиваем» её, т.е. добавляем к концу ещё 150 ГБ новых block groups. Теперь у нас ФС выглядит так: 150 ГБ в начале фрагментировано и забито под завязку, а 150 Гб в конце свободно.
Свободное место мы снова забиваем под завязку — при этом занятые части ФС, естественно, никак не меняются, а новые фрагментируются. Процесс повторяется.
В конце концов мы будем иметь 6 независимо заполненных и фрагментированных групп блоков объёмом 150 ГБ каждая. По уровню фрагментации это в шесть раз хуже, чем если бы мы сразу с нуля под завязку забили терабайтник.
Такая ФС однозначно будет тормозить, поскольку потребуются лишние перемещения головок диска и ожидания поворота шпинделя. Вкупе с проблемами I/O в Linux типа пресловутого бага 12309, это приведёт к низкой производительности системы в целом.
Кто сказал, что они будут дефрагментироваться? «Влево» переносится вся ФС, а потом «растягивается» обычным способом. По крайней мере GParted делает так. И если вы скажете что-то про partition magic, я вам не поверю — реально там и в resize2fs один и тот же код, написанный одним и тем же человеком — Теодором Цо, так что и работает он одинаково.
> К тому же пример с 80 портом и пользователем «user» неработоспособен, т.к. порт привилегированный и пользователь не сможет его слушать.
Ну, не всё так страшно, есть CAP_NET_BIND_SERVICE, и программа, обладающая такой способностью, имеет право вешаться на любые порты, даже не будучи запущенной от рута. В данном случае, видимо, setcap 'cap_net_bind_service=+ep' /usr/bin/ssh или что-то в этом роде.
Да, если отключить требование сертификата, то окошко логина-пароля выдаёт. Тогда вопрос звучит теперь так: как сделать, чтобы PyCharm всё-таки посылал клиентский сертификат?
Во-первых, вероятность одновременного отказа дисков из одной и той же партии в одних и тех же условиях весьма высока, и raid может не спасти. Поэтому как раз рекомендуется брать диски из разных партий, чтобы они одновременно не отказали.
Во-вторых, речь про программный RAID, а его можно сделать из чего угодно. Например, если взять взять три диска — на 80, 160 и 250 Гб — то можно сделать два зеркала суммарным объёмом 240 Гб.
В Linux это делается разбиением дисков на соответствующих размеров разделы, делания mdadm-ом raid-ов из разделов, и по желанию — последующим склеиванием полученных raidов в одну lvm vg.
В Windows все диски переводятся в динамический формат, а потом для нужных томов выбирается желаемый уровень отказоустойчивости. Грузиться система будет только с одного из дисков, но данные хранятся как положено, на всех.
Также подобные фокусы позволяет fake-raid от intel, который Intel Matrix RAID (дисковый формат imsm). Более современный, Intel использует дисковый формат snia ddf, в котором подобные фокусы недоступны (ну или просто Intel их не умеет).
Ну и про процессор. В работе RAID1 = mirror процессор не нагружается никак, от слова вообще. Нечего там считать. Вся «двойная нагрузка» ложится на шину SATA, а SATA-контроллер подключен чере PCIe. По этой шине через DMA (т.е. помимо процессора) пересылается двойной объём данных.
Пропускная способность шины PCIe x1 — 2 гбит/с в одну сторону, а там скорее всего x4. При этом, винты вряд ли умеют работать быстрее чем 100 мбайт/сек. Соответственно, шину просадить они не смогут.
И вывод — тормоза могут быть из-за того, что винты существенно разные по свойствам, и ОС не удаётся так разрулить операции ввода/вывода, чтобы всё не тормозило, либо из-за более прозаических причин — фрагментация ФС, директории с огромным числом файлов, нехватка ОЗУ и жёсткий своппинг и т. п…
Нужно смотреть загрузку дисковой подсистемы, кажется, Sysinternals Process Explorer умеет.
shogunkub, не вводите людей в заблуждение. BCC вырезает сервер отправителя, который обрабатывает саму рассылку, а уже серверу получателей и в ящики получателей оно достаётся обработанное. Например, Postfix его полностью вырезает. В полученных письмах просто нет поля BCC. Никакой Bat там принципиально не может ничего посмотреть — письмо выглядит как «оно не мне, непонятно, как оно вообще ко мне попало».
Компрессор громкие делает значительно тише, тихие делает немножко тише, в результате уровень выравнивается, но некоторая разница всё равно остаётся. Кроме компрессора бывают лимитер (просто ограничивает громкость не выше определённой), гейт (всё, что тише определённого уровня, убирает), экспандер (компрессор наоборот), комбинации перечисленных.