Про эффективный менеджмент
Сегодня суббота, а поэтому будет одна поучительная история из жизни. Середина нулевых, один местечковый районный провайдер, тогда таких было много.
Мы одно время работали в одном здании с ними, а поэтому хорошо друг друга знали. Потом у них дела пошли в гору, и они переехали в отдельное здание и наши пути потихоньку разошлись.
Ребята там были неплохие, кроме директора, был он, мягко скажем, немного скуповатым, хотя если честно, то далеко не немного. Но была у него еще вторая негативная черта характера. Все, кто имел сомнительное удовольствие с ним долго общаться не именовали его иначе чем чудак на букву М.
Я тоже жил в том районе и пользовался их интернетом и вскоре начал замечать, что проблемы только растут и множатся. То скорости нет, то связь пропала, то еще что-нибудь.
Хотя были иногда и приятные моменты, скажем, на майские праздники отключился биллинг и каждый качал-закачивался. А интернет в ту пору тарифицировался, если кто не помнит или не знает, помегабайтно.
Потом я как-то спросил ребят провайдера, а что это за аттракцион невиданной щедрости был?
Выяснилось, что шеф расплевался с их давним сисадмином, который стоял еще у истоков конторы и тот ушел, хлопнув дверью и назвав шефа чудаком. За серверами с диковинной FreeBSD никто не следил, так как не понимал, как следить, и в один прекрасный день место на дисках просто закончилось.
Биллинг прилег и народ все праздники резвился, попутно загоняя контору в долги. После чего из конторы ушел второй человек, который также стоял у ее основания и понимал в сетях.
Но шефа ничего не смутило, подумаешь, сисадмин, ну и подумаешь сетевой инженер. Больно нужны, у нас же все хорошо. Были приглашены специалисты со стороны и был внедрен новый биллинг, уже на Linux.
Между тем качество услуг стремительно падало, но во всем оказались виноваты пользователи, мол это они положили сеть широковещательными чатами и DC++ обменом. После чего эти приложения попытались просто запретить. Мол у кого обнаружим – отключим.
Но отключить пришлось бы решительно всех, поэтому такая инициатива сошла на нет. Лучше, естественно, не стало. Да и как оно станет в отсутствие сетевого инженера.
Прошло еще года полтора, звонит мне их шеф, мол ты же в Linux понимаешь? Понимаю. Приезжай, дело есть.
Приехал. Новый биллинг лежит. Начинаю разбираться. В наличии неплохой по тем временам сервер и RAID 5 с запасным диском. В RAID 5 выпали два диска из трех, а запасной кто-то свистнул, поставив вместо него неисправный диск бытовой серии.
Ну что тут было сказать? Только похлопать по плечу и сообщить, что медицина бессильна. Особенно если в штате не было ни одного следящего за инфраструктурой сотрудника.
Пошарившись по серверной нашли сервер с бекапами, но там был только бекап БД биллинга.
Ну вот, не все так плохо, можно восстановить.
Он спрашивает меня, смогу ли я это сделать. Отвечаю, что нет, я этот биллинг первый раз в жизни вижу и лучше всего обратиться к его разработчикам.
Выяснилось, что это не вариант, так как он им денег должен и за поддержку не платил два года. А зачем, ведь все работало.
В общем, принес ему свои соболезнования и сказал, что мне пора и было бы неплохо дать мне денег.
На что услышал, а за что тебе денег, ты же ничем мне не помог. В итоге, пояснил ему, что он чудак, развернулся и ушел.
Провайдеру тут же настал карачун, народ разбежался. А шеф? Шеф продал сети одному из федеральных провайдеров.
А что же теперь? А он теперь начальник в местном отделении федерального провайдера. До чего-то важного его не допускают, но теплое кресло выделили. Ну и репутация чудака на букву М за ним числится до сих пор.
Он же, в свою очередь, особенно после пары рюмок, любит поучать молодежь и рассказывать как у него давно был свой бизнес и как он его удачно продал, поняв, что не может тягаться на равных с федералами.
Сегодня суббота, а поэтому будет одна поучительная история из жизни. Середина нулевых, один местечковый районный провайдер, тогда таких было много.
Мы одно время работали в одном здании с ними, а поэтому хорошо друг друга знали. Потом у них дела пошли в гору, и они переехали в отдельное здание и наши пути потихоньку разошлись.
Ребята там были неплохие, кроме директора, был он, мягко скажем, немного скуповатым, хотя если честно, то далеко не немного. Но была у него еще вторая негативная черта характера. Все, кто имел сомнительное удовольствие с ним долго общаться не именовали его иначе чем чудак на букву М.
Я тоже жил в том районе и пользовался их интернетом и вскоре начал замечать, что проблемы только растут и множатся. То скорости нет, то связь пропала, то еще что-нибудь.
Хотя были иногда и приятные моменты, скажем, на майские праздники отключился биллинг и каждый качал-закачивался. А интернет в ту пору тарифицировался, если кто не помнит или не знает, помегабайтно.
Потом я как-то спросил ребят провайдера, а что это за аттракцион невиданной щедрости был?
Выяснилось, что шеф расплевался с их давним сисадмином, который стоял еще у истоков конторы и тот ушел, хлопнув дверью и назвав шефа чудаком. За серверами с диковинной FreeBSD никто не следил, так как не понимал, как следить, и в один прекрасный день место на дисках просто закончилось.
Биллинг прилег и народ все праздники резвился, попутно загоняя контору в долги. После чего из конторы ушел второй человек, который также стоял у ее основания и понимал в сетях.
Но шефа ничего не смутило, подумаешь, сисадмин, ну и подумаешь сетевой инженер. Больно нужны, у нас же все хорошо. Были приглашены специалисты со стороны и был внедрен новый биллинг, уже на Linux.
Между тем качество услуг стремительно падало, но во всем оказались виноваты пользователи, мол это они положили сеть широковещательными чатами и DC++ обменом. После чего эти приложения попытались просто запретить. Мол у кого обнаружим – отключим.
Но отключить пришлось бы решительно всех, поэтому такая инициатива сошла на нет. Лучше, естественно, не стало. Да и как оно станет в отсутствие сетевого инженера.
Прошло еще года полтора, звонит мне их шеф, мол ты же в Linux понимаешь? Понимаю. Приезжай, дело есть.
Приехал. Новый биллинг лежит. Начинаю разбираться. В наличии неплохой по тем временам сервер и RAID 5 с запасным диском. В RAID 5 выпали два диска из трех, а запасной кто-то свистнул, поставив вместо него неисправный диск бытовой серии.
Ну что тут было сказать? Только похлопать по плечу и сообщить, что медицина бессильна. Особенно если в штате не было ни одного следящего за инфраструктурой сотрудника.
Пошарившись по серверной нашли сервер с бекапами, но там был только бекап БД биллинга.
Ну вот, не все так плохо, можно восстановить.
Он спрашивает меня, смогу ли я это сделать. Отвечаю, что нет, я этот биллинг первый раз в жизни вижу и лучше всего обратиться к его разработчикам.
Выяснилось, что это не вариант, так как он им денег должен и за поддержку не платил два года. А зачем, ведь все работало.
В общем, принес ему свои соболезнования и сказал, что мне пора и было бы неплохо дать мне денег.
На что услышал, а за что тебе денег, ты же ничем мне не помог. В итоге, пояснил ему, что он чудак, развернулся и ушел.
Провайдеру тут же настал карачун, народ разбежался. А шеф? Шеф продал сети одному из федеральных провайдеров.
А что же теперь? А он теперь начальник в местном отделении федерального провайдера. До чего-то важного его не допускают, но теплое кресло выделили. Ну и репутация чудака на букву М за ним числится до сих пор.
Он же, в свою очередь, особенно после пары рюмок, любит поучать молодежь и рассказывать как у него давно был свой бизнес и как он его удачно продал, поняв, что не может тягаться на равных с федералами.
🔥11👍6😁4❤1🤮1
Кошмар на улице Вязов
Сегодня мне приснился страшный сон, от которого я проснулся буквально в холодном поту. На его фоне любые киношные монстры, маньяки и прочие ужастики кажутся невинным детским утренником.
Сон пересказывать не буду: местами он иррациональный, как и положено сновидениям. Но суть свелась к простой фабуле: в чужом городе у меня украли телефон, и я остался в незнакомом месте — без связи, без денег и без навигации.
И ведь это реальный кошмар современного мира. Сегодня смартфон — не просто средство связи, а цифровой центр человека, в котором сосредоточено практически всё. Оказавшись без него, чувствуешь себя буквально голым.
Начнём со связи. Сколько номеров помнит наизусть современный человек? Хорошо, если один — свой собственный. Люди старой закалки, возможно, удержат в памяти два-три номера самых близких. Но и то вряд ли: мы видим цифры один раз при сохранении, а дальше просто тапаем по записи в адресной книге.
К тому же основным средством общения давно стали мессенджеры. Они хоть и привязаны к номеру, но просто попросить телефон у прохожего и «быстро черкнуть в телегу» не выйдет. В итоге, даже если добрый человек протянет вам свой аппарат, звонить будет попросту некому. Память пуста. Но это лишь верхушка айсберга.
Деньги. Многие уже много лет назад отказались от наличных, а некоторые — и от физического пластика. Зачем носить с собой карты, если их можно потерять или забыть, когда всё и так в телефоне?
Тем более что у большинства карт больше одной: повседневная, для онлайн-покупок, для регулярных автосписаний. Деньги между ними перекидываются за секунду в банковском приложении.
Без смартфона вы рискуете остаться либо без копейки вообще, либо без доступа к основной части своих средств. А это уже проблема принципиально другого масштаба.
Третий момент — навигация. Мы намертво привыкли ориентироваться по экрану. Вбил адрес — тебе проложили маршрут или сразу вызвали такси. Причем можно даже без точного адреса: просто ткни «метро такое-то» или название торгового центра.
Спросить дорогу у прохожих? Большинство знает свой дом и пару соседних дворов. Если это не центральный вокзал, вам просто неопределенно махнут рукой: мол, идите вон до того угла, а там еще у кого-нибудь спросите. Да и до того же вокзала без денег и такси еще попробуй доберись.
Но и это не всё. Цифровизация окончательно поглотила сервисы: билеты, бронирования, документы. Недавно покупал билеты на поезд: на почту упало несколько PDF, в приложении РЖД всё подтянулось.
На посадку пустят по паспорту, но номер поезда, вагон и место надо где-то подсмотреть. Ладно, вокзал — полбеды: пришел пораньше, сел и жди, проводник через любой вагон разберется.
А как быть с арендой жилья? Сейчас повсеместно внедряют бесконтактное заселение. К моменту заезда вам в мессенджер просто скидывают код от кодового замка или сейфа с ключом.
Нет телефона — нет кода. И хоть головой в дверь бейся — никто не откроет, потому что на месте никого нет, а служба поддержки сидит в чате. Имея на руках полностью оплаченную бронь, вы запросто останетесь ночевать на лавочке.
Добавьте сюда страховки, справки, медицинский полис, который давно никто не носит на бумаге, — всё лежит на «Госуслугах». А ключ к ним — опять в кармане.
Конечно, можно по старинке распечатывать стопку бумаг, возить с собой заначку наличных и выбирать отели исключительно с круглосуточным ресепшеном. Но тренд неумолим: мы всё глубже уходим в стопроцентную цифру.
И смартфон в этой реальности стал единственной точкой присутствия человека. Потерял, разбил, украли или просто сел аккумулятор — и ты в ту же секунду выброшен на обочину жизни.
Сегодня мне приснился страшный сон, от которого я проснулся буквально в холодном поту. На его фоне любые киношные монстры, маньяки и прочие ужастики кажутся невинным детским утренником.
Сон пересказывать не буду: местами он иррациональный, как и положено сновидениям. Но суть свелась к простой фабуле: в чужом городе у меня украли телефон, и я остался в незнакомом месте — без связи, без денег и без навигации.
И ведь это реальный кошмар современного мира. Сегодня смартфон — не просто средство связи, а цифровой центр человека, в котором сосредоточено практически всё. Оказавшись без него, чувствуешь себя буквально голым.
Начнём со связи. Сколько номеров помнит наизусть современный человек? Хорошо, если один — свой собственный. Люди старой закалки, возможно, удержат в памяти два-три номера самых близких. Но и то вряд ли: мы видим цифры один раз при сохранении, а дальше просто тапаем по записи в адресной книге.
К тому же основным средством общения давно стали мессенджеры. Они хоть и привязаны к номеру, но просто попросить телефон у прохожего и «быстро черкнуть в телегу» не выйдет. В итоге, даже если добрый человек протянет вам свой аппарат, звонить будет попросту некому. Память пуста. Но это лишь верхушка айсберга.
Деньги. Многие уже много лет назад отказались от наличных, а некоторые — и от физического пластика. Зачем носить с собой карты, если их можно потерять или забыть, когда всё и так в телефоне?
Тем более что у большинства карт больше одной: повседневная, для онлайн-покупок, для регулярных автосписаний. Деньги между ними перекидываются за секунду в банковском приложении.
Без смартфона вы рискуете остаться либо без копейки вообще, либо без доступа к основной части своих средств. А это уже проблема принципиально другого масштаба.
Третий момент — навигация. Мы намертво привыкли ориентироваться по экрану. Вбил адрес — тебе проложили маршрут или сразу вызвали такси. Причем можно даже без точного адреса: просто ткни «метро такое-то» или название торгового центра.
Спросить дорогу у прохожих? Большинство знает свой дом и пару соседних дворов. Если это не центральный вокзал, вам просто неопределенно махнут рукой: мол, идите вон до того угла, а там еще у кого-нибудь спросите. Да и до того же вокзала без денег и такси еще попробуй доберись.
Но и это не всё. Цифровизация окончательно поглотила сервисы: билеты, бронирования, документы. Недавно покупал билеты на поезд: на почту упало несколько PDF, в приложении РЖД всё подтянулось.
На посадку пустят по паспорту, но номер поезда, вагон и место надо где-то подсмотреть. Ладно, вокзал — полбеды: пришел пораньше, сел и жди, проводник через любой вагон разберется.
А как быть с арендой жилья? Сейчас повсеместно внедряют бесконтактное заселение. К моменту заезда вам в мессенджер просто скидывают код от кодового замка или сейфа с ключом.
Нет телефона — нет кода. И хоть головой в дверь бейся — никто не откроет, потому что на месте никого нет, а служба поддержки сидит в чате. Имея на руках полностью оплаченную бронь, вы запросто останетесь ночевать на лавочке.
Добавьте сюда страховки, справки, медицинский полис, который давно никто не носит на бумаге, — всё лежит на «Госуслугах». А ключ к ним — опять в кармане.
Конечно, можно по старинке распечатывать стопку бумаг, возить с собой заначку наличных и выбирать отели исключительно с круглосуточным ресепшеном. Но тренд неумолим: мы всё глубже уходим в стопроцентную цифру.
И смартфон в этой реальности стал единственной точкой присутствия человека. Потерял, разбил, украли или просто сел аккумулятор — и ты в ту же секунду выброшен на обочину жизни.
😁15👍7❤4👀4🤮3
Современные файловые системы Linux
Выбор файловой системы в Linux может оказаться сложной задачей для новичка. На что смотреть? На тесты и бенчмарки, которые проводятся на пустом SSD и не отражают реальность?
Сегодня мы коротко разберем актуальный квартет: ext4, XFS, Btrfs и ZFS, подсветив все их основные плюсы и минусы.
1️⃣ ext4: Проверенная временем классика
Это классическая блочная журналируемая ФС с записью «на месте» (In-place update). Максимальная стабильность, предсказуемость и надежность, минимальное потребление ресурсов CPU и RAM. Все это проверено десятилетиями.
Но это именно классическая ФС и если вы хотите снапшоты, пулы, сжатие и проверку целостности – ничего этого нет.
Есть еще «родовая травма» - таблица индексных дескрипторов (inodes) размечается один раз на этапе форматирования и впоследствии изменена быть не может.
Если диск используется под сценарии с миллионами крошечных файлов (почтовый сервер с Maildir, кэш аватарок веб-сервера, мелкие сессии, очереди задач), наступает классический парадокс: свободное место есть , а записать файл нельзя.
2️⃣ XFS: Enterprise-стандарт
XFS - 64-битная высокомасштабируемая журналируемая ФС с аллокацией по экстентам (extents) и разделением пространства на независимые группы размещения (Allocation Groups).
Обеспечивает высокую производительность при параллельной многопоточной записи/чтении и работе с крупными файлами (видео, дампы, медиа).
Дефолтная ФС в enterprise-дистрибутивах (RHEL / Rocky / AlmaLinux).
Но есть и достаточно серьезные недостатки - раздел XFS нельзя уменьшить, вообще никак: система XFS умеет расти (xfs_growfs), но архитектурно не умеет уменьшаться.
А далее имеем классический случай, на смену одним дискам на 1 ТБ (честный двоичный байт 2^40 = 1024 ГБ) купили маркетинговый «терабайт» (10^12 байт ~ 931 ГиБ). И что? И все, приехали.
3️⃣ Btrfs: «Спасение» силами гигантов индустрии
На заре своего появления (конец 2000-х / начало 2010-х) Btrfs имела репутацию крайне нестабильной, «сырой» и опасной системы. Она регулярно теряла данные при падениях питания, страдала от критических багов в аллокаторе свободного места, а алгоритмы RAID5/6 были в целом неработоспособные.
Red Hat со временем и вовсе официально признала Btrfs устаревшей (deprecated в RHEL 7.4) и полностью вырезала её поддержку в RHEL 8, сделав будущее этой ФС очень туманным.
Поворотным моментом стал приход в Meta* новой команды инженеров (Крис Мейсон, Йозеф Бачик и прочие). Они переписали и довели до ума самые проблемные места, код работы со свободным пространством, асинхронную очистку, сжатие ZSTD и интеграцию с механизмами ядра Linux.
В итоге это превратило вечную «бета» в надежную систему, которая используется по умолчанию для SUSE и Fedora.
4️⃣ ZFS: Монолитная СХД в одном флаконе
Это не просто ФС, а связка: файловая система + менеджер томов + RAID с пулом накопителей и легкими датасетами. Полный сквозной контроль целостности: контрольные суммы на каждый блок, самовосстановление, снапшоты, репликация и собственный кэш ARC в RAM.
Но за это все приходится платить, в первую очередь высокими требованиями к RAM и высоким коэффициентом WAF (что характерно для всех CoW систем).
Хотя в грамотных руках это того стоит, вы получаете очень гибкое, настраиваемое и масштабируемое хранилище корпоративного уровня.
Выводы:
🔹Нужна железобетонная стабильность «поставил и забыл»? ext4.
🔹Высокие параллельные нагрузки, базы или огромные файлы без нужды сжимать раздел? XFS.
🔹Десктоп, снапшоты системы перед апдейтом и сжатие на лету? Btrfs.
🔹СХД, отказоустойчивые пулы, виртуализация и контроль целостности? ZFS.
* Meta признана экстремистской организацией в России.
Выбор файловой системы в Linux может оказаться сложной задачей для новичка. На что смотреть? На тесты и бенчмарки, которые проводятся на пустом SSD и не отражают реальность?
Сегодня мы коротко разберем актуальный квартет: ext4, XFS, Btrfs и ZFS, подсветив все их основные плюсы и минусы.
1️⃣ ext4: Проверенная временем классика
Это классическая блочная журналируемая ФС с записью «на месте» (In-place update). Максимальная стабильность, предсказуемость и надежность, минимальное потребление ресурсов CPU и RAM. Все это проверено десятилетиями.
Но это именно классическая ФС и если вы хотите снапшоты, пулы, сжатие и проверку целостности – ничего этого нет.
Есть еще «родовая травма» - таблица индексных дескрипторов (inodes) размечается один раз на этапе форматирования и впоследствии изменена быть не может.
Если диск используется под сценарии с миллионами крошечных файлов (почтовый сервер с Maildir, кэш аватарок веб-сервера, мелкие сессии, очереди задач), наступает классический парадокс: свободное место есть , а записать файл нельзя.
2️⃣ XFS: Enterprise-стандарт
XFS - 64-битная высокомасштабируемая журналируемая ФС с аллокацией по экстентам (extents) и разделением пространства на независимые группы размещения (Allocation Groups).
Обеспечивает высокую производительность при параллельной многопоточной записи/чтении и работе с крупными файлами (видео, дампы, медиа).
Дефолтная ФС в enterprise-дистрибутивах (RHEL / Rocky / AlmaLinux).
Но есть и достаточно серьезные недостатки - раздел XFS нельзя уменьшить, вообще никак: система XFS умеет расти (xfs_growfs), но архитектурно не умеет уменьшаться.
А далее имеем классический случай, на смену одним дискам на 1 ТБ (честный двоичный байт 2^40 = 1024 ГБ) купили маркетинговый «терабайт» (10^12 байт ~ 931 ГиБ). И что? И все, приехали.
3️⃣ Btrfs: «Спасение» силами гигантов индустрии
На заре своего появления (конец 2000-х / начало 2010-х) Btrfs имела репутацию крайне нестабильной, «сырой» и опасной системы. Она регулярно теряла данные при падениях питания, страдала от критических багов в аллокаторе свободного места, а алгоритмы RAID5/6 были в целом неработоспособные.
Red Hat со временем и вовсе официально признала Btrfs устаревшей (deprecated в RHEL 7.4) и полностью вырезала её поддержку в RHEL 8, сделав будущее этой ФС очень туманным.
Поворотным моментом стал приход в Meta* новой команды инженеров (Крис Мейсон, Йозеф Бачик и прочие). Они переписали и довели до ума самые проблемные места, код работы со свободным пространством, асинхронную очистку, сжатие ZSTD и интеграцию с механизмами ядра Linux.
В итоге это превратило вечную «бета» в надежную систему, которая используется по умолчанию для SUSE и Fedora.
4️⃣ ZFS: Монолитная СХД в одном флаконе
Это не просто ФС, а связка: файловая система + менеджер томов + RAID с пулом накопителей и легкими датасетами. Полный сквозной контроль целостности: контрольные суммы на каждый блок, самовосстановление, снапшоты, репликация и собственный кэш ARC в RAM.
Но за это все приходится платить, в первую очередь высокими требованиями к RAM и высоким коэффициентом WAF (что характерно для всех CoW систем).
Хотя в грамотных руках это того стоит, вы получаете очень гибкое, настраиваемое и масштабируемое хранилище корпоративного уровня.
Выводы:
🔹Нужна железобетонная стабильность «поставил и забыл»? ext4.
🔹Высокие параллельные нагрузки, базы или огромные файлы без нужды сжимать раздел? XFS.
🔹Десктоп, снапшоты системы перед апдейтом и сжатие на лету? Btrfs.
🔹СХД, отказоустойчивые пулы, виртуализация и контроль целостности? ZFS.
* Meta признана экстремистской организацией в России.
1👍18❤6🥱2
Какую ФС на серверах с Linux вы используете? (Можно выбрать несколько значений)
Anonymous Poll
78%
ext4
15%
XFS
12%
BtrFS
32%
ZFS
0%
Свой вариант (в комментариях)
13%
Просто посмотреть ответы
👍3
Подключаем диск из NAS в Linux, или монтирование RAID и LVM разделов
Всем нам знакомы и привычны аппаратные NAS, они используются дома и на работе для хранения самых различных данных. Но любое оборудование может выходить из строя, обычно неожиданно и перед администратором может встать задача копирования данных с дисков NAS.
На первый взгляд в ней нет ничего сложного: в основе прошивки Linux, а значит берем любую Linux систему, подключаем, монтируем, сливаем...
Однако не все так просто и для выполнения этой задачи могут потребоваться достаточно глубокие знания систем хранения Linux и навыков работы с ними.
Разбирать подобные ситуации лучше на примерах, тем более в нашем случае он как будто специально, достаточно показательный.
На днях к нам обратился коллега с просьбой помочь достать информацию с диска, вышедшего из строя NAS Synology DS216. На наш вопрос в чем там проблема он уклончиво ответил, что как-то все сложно и он боится сделать что-нибудь не так и испортить данные.
Ну что же, давайте разбираться. Итак, перед нами следующие вводные: есть диск из двухдискового NAS, работавшего с зеркальным RAID-массивом, в качестве файловой системы использовалась ext4.
✅ Читать далее: https://interface31.ru/post/podklyuchaem-disk-iz-nas-v-linux-ili-montirovanie-raid-i-lvm-razdelov/
Всем нам знакомы и привычны аппаратные NAS, они используются дома и на работе для хранения самых различных данных. Но любое оборудование может выходить из строя, обычно неожиданно и перед администратором может встать задача копирования данных с дисков NAS.
На первый взгляд в ней нет ничего сложного: в основе прошивки Linux, а значит берем любую Linux систему, подключаем, монтируем, сливаем...
Однако не все так просто и для выполнения этой задачи могут потребоваться достаточно глубокие знания систем хранения Linux и навыков работы с ними.
Разбирать подобные ситуации лучше на примерах, тем более в нашем случае он как будто специально, достаточно показательный.
На днях к нам обратился коллега с просьбой помочь достать информацию с диска, вышедшего из строя NAS Synology DS216. На наш вопрос в чем там проблема он уклончиво ответил, что как-то все сложно и он боится сделать что-нибудь не так и испортить данные.
Ну что же, давайте разбираться. Итак, перед нами следующие вводные: есть диск из двухдискового NAS, работавшего с зеркальным RAID-массивом, в качестве файловой системы использовалась ext4.
✅ Читать далее: https://interface31.ru/post/podklyuchaem-disk-iz-nas-v-linux-ili-montirovanie-raid-i-lvm-razdelov/
👍9🔥3
Как изменить SID в Windows 10/11 и Server 2025
О проблеме дублирующихся SID мы писали в нашей прошлой заметке, сегодня расскажем о том, как изменить его без переустановки системы.
❗️Важно! Данный способ является неофициальным и потенциально может привести к нарушению работы системы и/или потере информации. Поэтому все действия вы производите исключительно на свой страх и риск!
Для работы мы будем использовать утилиту SIDCHG, которую следует скачать с официального сайта, там же расположен лицензионный ключ пробной версии, который представлен в качестве изображения и меняется каждый месяц, на октябрь 2026 года ключ такой:
После чего узнайте текущий SID машины, например, при помощи PsGetsid64 от Sysinternals.
‼️ Если система использует BitLocker (а Windows 11 использует его по умолчанию), то шифрование нужно отключить, а диски расшифровать.
Статус можно узнать командой:
Отключить:
Если дисков несколько – повторить для каждого, после чего следует дождаться процесса расшифровки и перезагрузить ПК.
‼️ Если вы используете EFS, то скопируйте зашифрованные файлы в другое место, а также не забудьте экспортировать сертификат с ключами.
Будьте готовы к тому, что некоторое программное обеспечение может потребовать повторной активации.
🔹 Затем отключите службу UCPD — это User Choice Protection Driver
Перезагрузитесь, иначе защита полноценно отключена не будет.
Выключите онлайн-защиту антивируса, включая Defender и запустите скачанную утилиту с ключом R:
Введите лицензионный ключ и подтвердите свои действия, утилита завершит сеанс, и вы окажетесь на экране блокировки. Не входите в систему до завершения ее работы, особенно это важно для сервера, где могут быть удаленные сеансы.
По завершении работы компьютер автоматически перезагрузится. После чего первым делом включаем обратно службу UCPD и снова перезагружаемся.
После чего убедитесь, что SID действительно изменился.
👉 В некоторых случаях могут начать нестабильно работать современные приложения и меню Пуск, в этом случае нужно выполнить сброс их настроек, для этого снова запустите утилиту:
Данная команда сбросит все современные приложения, либо, если хотите действовать точечно:
Где App_1 – имя современного приложения, можно перечислить несколько значений через запятую.
При соблюдении всех указанных подготовительных мер данный способ работает, но не нужно забывать, что он не является официальным и Microsoft такой сценарий не поддерживает. Поэтому обязательно делайте бекапы, а по возможности лучше переустановите систему.
О проблеме дублирующихся SID мы писали в нашей прошлой заметке, сегодня расскажем о том, как изменить его без переустановки системы.
❗️Важно! Данный способ является неофициальным и потенциально может привести к нарушению работы системы и/или потере информации. Поэтому все действия вы производите исключительно на свой страх и риск!
Для работы мы будем использовать утилиту SIDCHG, которую следует скачать с официального сайта, там же расположен лицензионный ключ пробной версии, который представлен в качестве изображения и меняется каждый месяц, на октябрь 2026 года ключ такой:
77JAY-XcFfv-2OiLw-2f
После чего узнайте текущий SID машины, например, при помощи PsGetsid64 от Sysinternals.
‼️ Если система использует BitLocker (а Windows 11 использует его по умолчанию), то шифрование нужно отключить, а диски расшифровать.
Статус можно узнать командой:
manage-bde -status C:
Отключить:
manage-bde -off C:
Если дисков несколько – повторить для каждого, после чего следует дождаться процесса расшифровки и перезагрузить ПК.
‼️ Если вы используете EFS, то скопируйте зашифрованные файлы в другое место, а также не забудьте экспортировать сертификат с ключами.
Будьте готовы к тому, что некоторое программное обеспечение может потребовать повторной активации.
🔹 Затем отключите службу UCPD — это User Choice Protection Driver
sc config UCPD start=disabled
schtasks.exe /change /Disable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
Перезагрузитесь, иначе защита полноценно отключена не будет.
Выключите онлайн-защиту антивируса, включая Defender и запустите скачанную утилиту с ключом R:
SIDCHG64.exe /R
Введите лицензионный ключ и подтвердите свои действия, утилита завершит сеанс, и вы окажетесь на экране блокировки. Не входите в систему до завершения ее работы, особенно это важно для сервера, где могут быть удаленные сеансы.
По завершении работы компьютер автоматически перезагрузится. После чего первым делом включаем обратно службу UCPD и снова перезагружаемся.
schtasks.exe /change /Enable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
sc config UCPD start=auto
После чего убедитесь, что SID действительно изменился.
👉 В некоторых случаях могут начать нестабильно работать современные приложения и меню Пуск, в этом случае нужно выполнить сброс их настроек, для этого снова запустите утилиту:
SIDCHG64.exe / RESETALLAPPS
Данная команда сбросит все современные приложения, либо, если хотите действовать точечно:
SIDCHG64.exe /RESETAPPS=App_1
Где App_1 – имя современного приложения, можно перечислить несколько значений через запятую.
При соблюдении всех указанных подготовительных мер данный способ работает, но не нужно забывать, что он не является официальным и Microsoft такой сценарий не поддерживает. Поэтому обязательно делайте бекапы, а по возможности лучше переустановите систему.
👍10🤔2🤮1
Режимы выделения виртуальной памяти в Linux
Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.
Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.
Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).
И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса.
Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.
Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.
Режим работы этого механизма можно задать при помощи опции
Которая может принимать одно из трех значений: 0, 1 и 2
🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.
В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.
Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.
Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой.
🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).
Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer.
🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:
Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:
По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.
Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.
Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.
В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.
Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.
Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.
Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).
И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса.
Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.
Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.
Режим работы этого механизма можно задать при помощи опции
vm.overcommit_memory
Которая может принимать одно из трех значений: 0, 1 и 2
🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.
В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.
Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.
Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой.
🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).
Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer.
🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:
vm.overcommit_ratio = 100
Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:
CommitLimit = swap_total + (RAM_total × vm.overcommit_ratio / 100)
По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.
Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.
Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.
В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.
👍8❤1
Как в Linux узнать скорость USB-портов и их текущий режим работы
Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных.
Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться.
Первый приходящий на ум вариант – заглянуть в документацию, но это не всегда возможно, тем более документация не покажет нам реальный режим работы устройства.
Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:
Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств.
Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:
▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2
Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.
Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных.
Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться.
Первый приходящий на ум вариант – заглянуть в документацию, но это не всегда возможно, тем более документация не покажет нам реальный режим работы устройства.
Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:
lsusb -t
Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств.
Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:
▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2
Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.
👍6🔥4