mayton2019

Если ты хочешь программировать под Linux то тебе нужно знать функции ядра Linux.
Это так называемые syscalls. Системные вызовы. Работа с файлами. С сокетами.
С объектами мультизадачности (mutex). Языки могут быть любые но принципы
будут примерно одинаковые.

+Надо определиться с доменной областью. Вряд-ли вы будете писать системный софт.
Системщиков вообще мало и пишут они очень узко. Скорее всего это будет что-то прикладное
поэтому надо искать прикладные задачи и искать типичный профиль такой прикладной задачи.
FastCGI приложение например там или ETL процесс или какие-то сетевые штуки. Ищите
практические задачи. Иначе сам по себе вопрос потеряет смысл.

Попробуй запуск приложения в docker container. Потом поищи средства поиска
изменений в файловой системе контейнера. Кажется docker diff.

Speedtest не меряет скорость Интернета как таковую. Он имеет специальный
алгоритм разрешения хостов-провайдеров которые стоят физически максимально
близко к тебе. И меряет скорость к ним.

Поэтому результат Speedtest можно рассматривать как такой забавный частный случай.
Поэтому при "при загрузке какого либо файла" фактическая скорость
будет иметь мало связи с тем что Спидтест намерял.

Результаты спидтеста обычно показывает вам провайдер что-б вы просто не приставали
к нему с глупыми вопросами. Типа выж видите. У нас все хорошо.

Этот сценарий возможен. Но я-бы советовал сделать его через backup на внешнее устройство.
Объем - маленький. Можно сделать за несколько часов всю работу.

Как растягивать Windows я не знаю. Давно это было. Но были утилиты типа Acronis, которые
кажется это делали с загрузочного диска.

Все зависит от того как отформатирован Linux-диск. Во времена первых Linux Black Cat (я себе ставил)
почти все пользователи делали большой fat32 раздел чтоб шарить файлы между Windows 98 к примеру
и Black Cat. Другого способа перекинуть файло не было.

Потом я где-то находил драйвер ext2fsd который по идее должен был дать возможность Windows-системе
видеть разделы но я не помню чтоб я его успешно применял.

Современные версии Linux уже видять NTFS через ntfs-3g поэтому Linux неограничено видит почти все.

WSL - это вообще отдельная вселенная. Кажется он реализован как Докер контейнер. И видит Windows
через /mnt/c точку монтирования.

Непонятно, зачем тебе 2Тб под swap. Наверное цель - какая-то другая у тебя.

Я-бы разделил эту задачу на две разные части. Первое - это делать скриншоты любым опенсорцным софтом
и складывать их в локальный фолдер пользователя.

И второе - это забирать файлы с локального фолдера пользователя на сервер при необходимости.
Со второй задачей - справляться проще т.к. любая ОС в домене уже должна иметь такой коробочный
софт. И здесь проблема сертификации уходит т.к. ОС уже сертифицирована.

Современное ПО очень сложное в части гарантий сохранения транзакций например. В БД для того чтобы
сохранился commit, мы должны гарантировать что за секунду до аварии мы успели сделать FSYNC
для всех буферных операци I/O.

И эта проблема никак не решается заменой одной ФС на другую. Вы пишите хоть в ZFS, хоть в RAW,
но здесь эта гарантия дает сбой. База не смогла сохранить последний коммит. И при recovery будет
откат транзакций назад. И дальше надо на уровне приложений разбираться где какие платежи не прошли
и кому вернуть деньги.

Поэтому сервак БД должен быть хотя-бы застабилизирован на 5-10 минут чтобы успеть корректно сделать
shutdown. Либо дежурный админ это сделает либо ваш софт - неважно. Тоесть отключение энергии должно
быть плановым и контролируемым.

По поводу cannot read superblock - не знаю. Я такого в своей практике никогда не встречал. Надо поисследовать
вопрос глубже. Предполагаю что это не сама причина а следствие чего-то другого. Например виртуальные машины не нашли свою файловую систему.

Ошибка выглядит так.
Malformed VALUE header (0)
Я думаю что memcached тут не виноват. Он - слишком простой и примитивный. Скорее всего твое приложение
что-то делает сильно сложно.

В момент возникновения ошибки тебе надо взять telnet или putty и вручную подключиться к memcached
и воспроизвести проблему.

Еще документация пишет что Memcached поддерживает два протокола. ASCII и Binary. И такой эффект
может быть как будто ты в бинарный протокол толкаешь текстовые запросы. Но это мое предположение.
Просто надо проверить.

Нужно пойти от проблемы. Собственно я здесь никакой проблемы не вижу. Давайте доступ. Пускай студенты
рисуют почасовой план использования этого ресурса. Например Студент №1 с 10:00 до 12:00 по понедельникам.
Следующий... и так далее. Сами следят и самоорганизуются.

Проблема может быть в безопасности. Студенты могут хулиганить. И проблема может быть в накладках
графика использования. Например кто-то в пятницу запустил расчет и в ПН этот расчет еще не закончился.
Что делать? Убивать процесс пятничного студента?

Тут вобщем больше я вижу организационных вопросов чем технических. Вы сначала разработайте цели.
А уже от целей можно пойти к планировщикам.

Тут ничего нельзя сказать пока не будет известно что это за устройство и каким образом ОС его видит.

Попробуй поищи его через

$ lsusb

$ lspci

$ lshw

Обычно корневая папка защищена от любого пользователя. Делай сначала каталог и давай права.

$ sudo mkdir /Test1
$ sudo chown endless:endless /Test1

И потом уже копируй или клонируй.

Есть два подхода.

Нанести повреждения сырой файловой системе. Под суперпользователем открыть диск как блочное устройство
(файл по сути) и случайным образом внести изменения в случайные блоки (тут надо владеть информацией о размере блока) 512 байт или 4К или еще какие-то возможны варианты. Записать рандомный шум по сути. Только не трогай первый блок. Там может быть вайжная инфа о файловой системе. Иначе вообще не смонтируешь .. ну хотя может для тебя это тоже кейс.

Если изменение будет попадать в журналы - то они автоматом исправятся при старте. Насколько я помню ext4 хранит копии журналов в разных частях диска. Если изменения попадают внутрь тела файла то это мы не исправим никак. С точки зрения структуры ФС - все выглядит валидно. Структура - цела. Значит чекинг ничего не заметит.

Для некоторых параноидально-защищенных файловых систем (zfs) изменения в теле файла будут детектированы на основе контрольных сумм. Насколько я помню zfs пишет их для каждого файла. Но исправлены не будут
скорее всего. Избыточной информации для исправления нету.

UPD: Тут надо смотреть как собраны программные зеркала этой системы. Возможно исправить все таки можно но там будут куча условий. Целое дерево условие если это то это и так далее. Короче квест.

Вообще очень сильно зависит от цели задачи. И от чего мы пытаемся защититься. Если ты меняешь первый блок файловой.

Тоесть эксперимент похож на слепую стрельбу из пистолета в живого человека. Смотря куда попал. Если в башку - то смерть. Если там в мясо - то можно подлечить как-то.

Второй подход. Рассматривать обычный API файловой системы. Здесь можно просто проверить что будет когда inodes закончились. Ивестно что каждый файл (не hard-link) создает ровно 1 inode в таблице нодов. И эта таблица ограничена в ext3/ext4 кажется. Можно создавать миллионы файлов имеющих нулевой размер и мы постепенно заполним эту таблицу и получим какую-то ошибку. Эта ошибка технически имеет онлайн решение для XFS (там можно на ходу растягивать ФС и таблицы). Для ext3 нужно отмонтировать и что-то сделать в оффлайне.

Про коррапченые файлы мы уже говорили. Если это вопрос файловой системы - то она не видит ничего скорее всего. Рандомное изменение тела файла - это легальная операция файлового API. Увидит только софт который будет этот файл открывать. Например word документ не откроется. JPEG картинка может открыться наполовину. Будем видеть мозаику из поврежденных блоков начиная от места повреждения. Почти все файлы архивы перестануть распаковываться с места повреждения и до конца. Тоесть им
скорее всего смерть. Тестовые файлы - откроются но будем видеть "мусор" в месте повреждения.

Подобоный bash мониторинг может создавать ненужную нагрузку (например если ты ишешь через find)
а файлов очень много. Они мелкие и т.п. Вобщем если искать часто (каждые 5 минут - то это будет ненужная
нагрузка). А если искать редко - то какая польза в таком мониторинге?

Вобщем верную мысль подсказали выше - слушать события inotify. Правда там будет много флуда. Надо
еще поработать над фильтрацией нужных событий. Но это - рациональный инженерный подход. Не стоит
его отбрасывать.

Есть у меня мысль - поднять информацию не из файлового API (find/du/ncdu) а из таблиц inode.
Там как раз есть информация о размере. Оптимистично - это более быстрый метод. По крайней
мере факт превышения квоты будет виден. А вот кем - надо искать.

Еще есть мысль что контроль квот - это технология уходящего века. В мире современных файловых
систем никто давно уже не учитывает файлы. Создается толстое хранилище на базе zfs например.
Оно нарезается пользователям на кусочки по 16/32/64 Gb и отдаются в пользование. По ним-же
идет тарификация. Если пользователь захочет больше - на ходу ему растягивается кусочек до нужного
ему размера. Тариф соотв другой.

Диагностику протокола SSL/TLS можно сделать с помощью утилиты OpenSSL например
вот как тут пишут https://stackoverflow.com/questions/17742003/how-t...

Чтобы браузер полноценно работал с секретным протколом - ему нужен сертификат домена.
Я тут не уверен можно ли создать само-подписный сертификат для localhost но мои знакомые
девопсы хвастались что делали такое.

Для создания сертификатов полно инструкций.

Не отрезолвился потому что ближайший DNS выдал чепуху.
Попробуй вручную понаблюдать что отдает DNS по данному хосту
через утилиты nslookup, dig e.t.c.