>>214935
Никак, в стандарте это не заложено.

Можно извращаться с редактированием списка загружаемых файлов и приоритетами.

>>214956
В стандарте и приоритеты файлов не заложены как бы.

Насчет автоматизаций и существующих решений не подскажу, но я просто ставлю первые две серии, первую с макс. приоритетом, вторую с нормальным, остальные не качать. Потом включаю так же следующие две. Не знаю конечно, успеет ли у тебя оно так, но вот.

>>214950
Mushoku Tensei.

> надеюсь, здесь нету всяких, кто смотрит через плееры на сайтах с русской озвучкой

Привет, котёнок! А ты знаешь, как смотрят аниме в космосе? И мы не знаем…

>надеюсь, здесь нету всяких, кто смотрит через плееры на сайтах с русской озвучкой
>качает торрент с русской озвучкой

Ох, вот так ирония.

>>214966
Там же внутри нормальный английский релиз к которому сбоку сабы приложены. Ну не нашёл оригинальный торрент или нашёл но там сидов нету.

>>214967
Английского там и близко нет по описанию, которое гуглится.

>>214967
Всё так. Не знаю зачем впихивать прямо в .mkv это всё. Обычно русский звук идёт отдельно, и я сильно экономлю время, не скачивая его.

Как вы уже поняли тайтл старый, где найти ещё его скачать, чтобы сиды были, я не знаю.

Смотрю с русабом, русскую озвучку не воспрнимаю в принципе.
Кто-то советует тут труъ-перевод и смотреть с ансабом, но кто смотрел это, знает что и с русабом то не особо понимаешь что происходит особенно концовку.
Хотя, это наверное одно из лучших аниме, просмотренных мной.

>>210466
То что имея возможность править код ядра все это в принципе решаемо очевидно, но это примерно как считать что любой софт можно написать на ассемблере.
Железо значительно ушло вперёд, и уже нельзя, например, считать что 0х378 всегда попадет на параллельный порт, с одной стороны, с другой, код должен поддаваться переиспользованию.
Времена тупого роста мегагерц и гигабайт безлатентной памяти прошли, бизнес-логика и вычисления требуют противоположных подходов, и настоящее и ближайшее будущее - это неоднородный доступ к памяти, зоопарки специализированных шин, аппаратные модули и целые сопроцессоры под специализированные задачи (видео, нейросети, роутинг пакетов...).
Все это, во-первых, стоит денег за готовые IP-блоки (микроэлектроника тоже не стоит на месте и описывается все более высокоуровневыми языками и библиотеками, с разделением фирм на писателей библиотек базовых блоков того что может делать фаб, абстрактных кирпичиков логических функций, больших блоков вроде процессорных ядер и собственно производите,), во-вторых, занимает площадь кристалла, повышая риск брака и цену, в-третьих, вредит производительности.
В результате фрагментация soc-ов неизбежна, и даже в рамках одного типа запускается одновременно лишь небольшая часть ресурсов, потому что все равно есть узкие места (тепловыделение, пропускная способность внутренних шин, требования по выравниванию и разруливанию доступа к памяти, ограниченное число внешних выводов...). А это значит, что должны быть удобные и быстрые способы конфигурировать работу периферии под конечные задачи, и делаться это должно на стороне ядра, это его задача все это эффективно использовать и абстрагировать от приложений.

Сообщение слишком длинное. Полный текст.

>>210468
Чисто объективный подход говорит нам, что все известные операционные системы то ещё, не осмелюсь вслух сказать что. Выбирайте из чего дают или GTFO. Конечно с точки зрения конечного пользователя оно должно, но объективно никогда ни разу. Просто что то в чём то лучше, что то хуже. Попытки наверное предпринимались, но все заканчивались либо сползанием в традиционное русло, либо просто заканчивались. В любом случае, любая операционка в любой рандомный период времени от самого зарождения балансирует на грани выживания. Даже виндоус. Взять и сделать всё по уму? Да вы наверное шутите!

>>210468

> Винда ... прибита гвоздями к х86

Вовсе нет. Под ARM Windows есть, под Itanium тоже относительно недавно была, не говоря уж про поддержку зоопарка архитектур в середине девяностых.

>>210470
В том то и дело что была. Потому что даже со всей системой лобби и финансовой поддержки, микрософт не смогла убедить разработчиков портировать свои приложения под новую версию винды. Другими словами, винда жива только своим наследием. Это её крест, ей с ним жить.
По большому счёту это конечно задача операционки создавать универсальную среду для выполнения и взаимодействия софта независимо от железа. Но про это уже выше писали - имеем что кое-как само-собою получилось, или не имели бы вообще. Даже микрософт не может взять и написать нормально работающую OS. Им бы кое как конкуренцию выдержать, поддержку свежего оборудования на скотч мотать да успевать заплатки лепить. И чтобы весь этот карточный домик в процессе не навернулся.

Имея некоторый опыт с линуксами, попробовал поставить десктоп в виртуалке для общего развития. Впечатления следующие:
1) У меня лично не возникало потребности, но инсталлятору явно не хватает подсказок для ньюфагов, в духе что пробелом ставятся чекбоксы, а квадратные скобки подразумевают ввод списка значений.
2) скудный выбор вариантов разметки диска. Неплохо бы иметь варианты дуалбута и/или выноса /home из коробки, потому что иначе в ознакомительных целях фряху можно ставить только в виртуалку.
3) установка иксов и кде из портов и запуск кое-как проблем не вызвал, в базовом виде завелось сразу после сюрпвки и включения vty, но вот настроить разрешение и полноценная интеграция с virt-manager похоже миссия невыполнима. В сочетании с предыдущим пунктом, непонятно, как к фряхе предполагается приобщаться в принципе, как у неё обстоят дела с поддержкой гостевых сред других гипервизоров? На невозможности без боли работать с полученными тормозами, знакомство с десктопной частью было остановлено.
4) в процессе сборки портов, я внимательно смотрел на зависимости, и к своему удивлению заметил там d-bus, pulseaudio, gnu тулчейны под C и C++, и отличную от базовой системы версию LLVM. Не хватает разве что glibc и systemd для полноты картины.
5) я поспешил с установкой 13й версии, и потому не смог опробовать обновление, но ручная синхронизация с пакетами, и отсутствие из коробки средств синхронизации с портами вообще выглядит дикостью. Я не перепутал порядок - софт поверх базовой системы важнее, потому что именно с ним взаимодействует пользователь на десктопе, или именно он определяет назначение сервера. В последнем случае проблему бы решило наличие докера иди чего-то подобного прямо в базовой системе, но этого нет.

Сообщение слишком длинное. Полный текст.

>>214738
Самодостаточность сейчас это жирный минус. Потому что ее мало запилить, ее надо поддерживать во всем многообразии. Нужно переписывать кучу системного софта, гвоздями прибитую к возможностям линукса и систимди. Причем прибита она не потому, что разработчики плохие и у них NIH - а чтобы не городить собственный велосипед для более низкоуровневого функционала, который тоже придется поддерживать...так и до TempleOS недалеко. С соответствующим юзабилити.

За примером далеко ходить не буду. Десктопную фрю довелось потыкать в виде 10 версии, где вместо всяких пульс были древние common unix велосипеды, которые в линуксе были в ходу во времена 2.6 - типо OSS или HAL. Что приводило либо к полной невозможности использовать свежий софт, либо к использованию мутных врапперов, написанных фряшниками на коленке и работающих соответственно. Которые, де-факто, функционал новомодных линуксовых сервисов и реализовывали.

В итоге докупил ОЗУ с рук и накатил Windows 7 Starter. Нафиг такой геморрой.

>>214739

>Потому что ее мало запилить, ее надо поддерживать во всем многообразии.

Я скучаю за временами ХР, когда ничего никуда поддерживать было не надо, и нескольких пиратских сборников софта хватало хоть для ядерного япокалипсиса без интернета. Собственно, чего-то такого от фряхи и ожидал, что системный уровень дубовый и стабильный, а приложения стоят поверх него, не городя неофициально весь линуксовый юзерленд.

>>214740
Если ты согласен жить на приложениях эпохи XP, то так и будет.

Создателям приложений нет смысла страдать и писать платформонезависимо ради крайне малой юзербазы.

>>187438
Есть выжившие пользователи? Такое ощущение, что даже Haiku нынче шире известно, а ведь были же времена.

>>210471

>В том то и дело что была.

Так Итаниум все убили, даже на Линупсах уже капут.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Orphans-Itanium-IA64

>>211808
Как я понимаю, SoC в этом планшете — это MediaTek.
Их поддержка очень ограничена в мэинлайне, если вообще существует для конкретной модели в этом планшете, так что начинать придется с портирования современных ядер, ибо на порезанной китайской древности современные дистрибутивы не заведутся.
А так схема обычно заключается в том, чтобы заставить работать нормальный загрузчик вроде того же U-Boot, потом заставить работать ядро и хорошо если базовое железо заведется без каких-нибудь бинарных блобов, одновременно нужно составить DeviceTree с необходимой периферией, а дальше уже ядро запустит юзерспейс.
В процессе придется писать и/или портировать с старых исходников, если они вообще доступны, кучу необходимых драйверов.

В общем если портирование ядра — это не хобби или заработок, то проще купить железку, которая основана на SoC с хорошей поддержкой в мэинлайне и гарантированно поддерживается тем или иным дистрибутивом.

>>211808
Проблема в драйверах для устройств. Если нет сборки линя конкретно под твою модель, вплоть до мелких буквочек в конце номера модели, о которых традиционно забывают в магазинах, то вряд ли тебе удасться собрать ее самому. Если сборка есть, то ее установка не сложнее заливки любого кастома. Сборок как правило не больше одной-двух, и выбирать дистрибутив не получится - ставь то, во что удалось запихнуть поддержку устройств.
Если нужен линь на планшетиках - смотри в сторону х86 моделей. Они обычно с виндой на борту. Но и там оче многа сложностей с драйверами, особенно на свежих Атомах, которые уже чуть ли не смартфонные однокристальные системы. Самый оптимальный вариант - пробивать конкретную модель на возможность установки линуха еще до покупки.

postmarket os / termux.

Угоню тред. У меня есть легендарный Nexus 7 2013. ЛинягаОСь 18.1 надоела, хочется trve Линупс. Какой современный дистр на нём заведётся (поверхностное гугление не находит ничего, кроме протухшей Бубунты Тач)?

>>214808
Ещё бы посчитать отдельно - фрагментацию, и отдельно - реальные нужды пользователей. ДЦ анонсируют сотни префиксов, которые на самом деле принадлежат их клиентам и не могут быть объединены. Есть и географические разделения. IPv6 ждёт то же самое, только префиксов будет больше просто в силу количества желающих и фактического отсутствия ограничений.

>>214811
Как ты их разделишь-то?
В IPv6 все-таки лучше должно быть за счет меньшей фрагментации и возможности легко выделять большие блоки клиентам от хостера.

По IPv6 аналогичный график количества BGP-записей.
В 2010 году их было всего 2500, а сейчас 150 000.
Так что адаптация идет, что бы там кто не говорил.

>>214812
Я говорю про то, что рост количества префиксов - это следствие роста сети, и фрагментация является одним из, и при этом далеко не самым значимым фактором.

Спасибо за бампы вашим дерейлом.
>>214789
Кстати, о "тут". Тред бы начат человеком, которому именно это и надо было объяснить. Может, другими словами, может, другому человеку с такими же проблемами (>>213066).
Вообще-то я хочу показывать это на примере. Собрать лабораторный стенд в настольной стойке из нескольких свичей, роутеров, серверов, и показать на практике, как и зачем работает сеть. Ну да ладно. Буду дальше искать людей вроде ОПа.

О, кстати, есть задача. На будущее, но уже таки есть.
Предположим, имеется три сетевых устройства: роутер, NAS с беспроводной карточкой и компьютер. Компьютер и NAS подключены к роутеру по гигабитной витой паре, NAS с компьютером дополнительно соединён десятигигабитной оптикой. Задача: как правильно сконфигурировать сеть, чтобы и компьютер, и NAS выходили в интернет через роутер, а между собой общались по оптике?

>>214820 А, и ещё: вайфай, раздаваемый NAS-ом, не должен включать в себя возможность выхода в интернет, только доступ к файлам на дисках.

>>214820
А в чём проблема?

Можно сделать статику в другой подсети и ходить напрямую оптикой. Грубо говоря в медной сети - 192.168.0.0/24, роутер - .1, комп - .2, нас - .3, а в оптической соответственно поставить 192.168.1.2/24 на компе и 192.168.1.3/24 на насе.

Можно ещё добавить маршруты через оптику и ходить по адресам из основной сети. Т.е. на компе добавляем маршрут до 192.168.0.3/32 через 192.168.1.3, и то же самое на насе с 192.168.0.2 через 192.168.1.2.

Раздаваемый насом вайфай с конфигурацией по умолчанию не будет иметь доступ в интернет (рассматриваем нетронутый линукс и hostapd в режиме точки без моста). Правильная конфигурация так же должна запрещать маршрутизацию без явного разрешения, т.е перед sysctl net.ipv4.ip_forward=1 делается iptables -P FORWARD DROP.

При необходимости использования ipv6 всё вышеописанное делается ещё раз.

>Cisco Packet Tracer

Как это добро ещё не закопали, когда есть GNS3?

>>214845
На GNS3 нельзя тесты из netacad проходить. Ну и собирать GNS под линукс это тот еще кошмар.

>>214742
-12V должен быть на разъеме питания материнской платы (синий проводник).
Только не превышай ток, положенный по маркировке БП, он там довольно низкий.

Тащемта, у тебя уже есть -12 В в блоке питания ATX. Только это легаси, которое уже почти не используется, поэтому вряд ли с него удасться снять больше пол ампера. Смотри характеристики своего блока.
Впрочем, вторичных источников на рынке как грязи, и ты легко найдёшь под свои заморочки. Только во всех случаях крайне желательно поставить между источником и усилком фильтр.

>>214742
Тебе это не нужно:
1) на раскачку 32 ом больше пары вольт не надо, избыточный запас по питанию - это только лишние проблемы с охлаждением
2) однополярное включение, смещение усилителя до половины напряжения питания и развязка выхода усилителя электролитом на 1000+мкФ дадут качество звука не хуже.
3) гораздо большей проблемой для звука будет рваное потребление на шине питания, с наводимыми сигналами в земляных петлях и излучением проводов, без специальных мер у тебя будет слышен скрежет указателя мышки по экрану от обработчика прерываний и прочие звуковые галлюцинации.

>>213622
А починить никак? Немного странно видеть в треде подобной тематики такое, мягко выражаясь вольнопотребительское отношение к ретродеталям и софту.

>>213623 Починить можно, нужно и будет сделано, но тут удобно подвернулась причина прикупить ещё одну железку.
Пока слушаю музыку через китайскую usb-затычку на PCM2902.

>>213623
Там наверняка тройная гребенка, ее фиг найдешь.

>к ретродеталям

Этого, кхм, "ретро", сейчас как известной субстанции за баней за копейки. Настоящее ретро, которое начало расти в цене по причине своей редкости - это PI и слотовые PII. В случае с железом оп-поста можно лет 20 не заморачиваться даже с простейшим ремонтом.

На самом деле, услышав про саундбластер и ретросборку, сразу представил себе нечто на подобии этого https://www.youtube.com/watch?v=wENB2egaDMs совсем забыл, что речь о железе 2010 года, моя вина.

Занятно.
Поставил саундбластер, распределив одновременно пыль из системника по конмате, квартире, городу, планете. И ничего.
Выхлоп lspci применительно к карточке даёт положительный результат:

05:01.0 Multimedia audio controller [0401]: Creative Labs EMU10k1 [Sound Blaster Live! Series] [1102:0002] (rev 07)
05:01.1 Input device controller [0980]: Creative Labs SB Live! Game Port [1102:7002] (rev 07)

А вот в микшере не показывается.

>>213679

>linux

Ничего занятного, настраивайте сами asound.conf

>>213679
Модуль emu10k1 загружен? У классического PCI SBLive! очень хорошая поддержка в alsa. Бортовой DSP и аппаратное микширование поддерживается.

>>213693
Ну так себе, на самом деле. Помню как руками патчил ядро для работы MIDI.

>>213482

>Ретроигры сейчас сносно работают что на десятке, что на линуксе.

Увы, не все. Solt Lake City 2002 не завелась ни на одном опробованном наборе железа/виртуалок/ОС, ближе всего была виртуалка в qemu-kvm с ХР SP1 и эмуляцией одного ядра Р3, но работал только звук, чёрный экран вместо видео.

Слоупок врывается в тред.
>>213693
Да.
У меня достаточно своеобразная вариация дебиана, со звуком у неё свои, особые геморрои.
Зато ничего не пердит.

>>214047
Чистую переустановку драйверов nvidia попробуй.

>>214048
Уже, так-же ошибка

>>214049
Тогда полагаю искать проблему будет дольше чем перенакатить ось. А если и после этого будут проблемы - то как бы не оказалось что это железо чудит.

>Games

Не все игры одинаково работают со всеми видеокарточками. Вылет отдельно взятых игр на отдельно взятых видеокартах - норма. И хотя клея официально требует NVIDIA GeForce GTX 660 против твоей 830M, возможна несовместимость. Тем более, что твоя при прочих равных в 3 раза слабее и ноутбучного класса, на поддержку которой разработчики могли забить.

>Мама и папа проводили эксперименты над служителями хаоса, но те вырвались на свободу.

Ох, май!

>>214050
А чего там перекатывать? Должна штатно обновиться до 10 если в принципе её поддерживает. Другое дело есть ли в этом смысл, учитывая что десятка тоже скоро станет историей.

>>214051
Не то чтобы отдельновзятых, вечером проверю что-то поинтереснее.
>>214052
Недолжна, если недавать, невижу большого смысла в обнлвлении до 10 или 11

Всем спасибо за подсказки, ос была обновлена с диска с 8.1, что сбросило глубигные параметры ос и обовления.
Результат - 0.
Запуск FlatOut 2 вполе хорошо прошел с видяхой nvidia, так что жело в играх которые неподдерживали видяху

>>214061
Справедливости ради, восстановление с диска =/= чистой переустановке. Это не призыв форматировать диск если что, просто констатация факта. Тебе скорее всего не поможет, так что не стоит.
Запуска другой игры было более чем достаточно для теста. Если было жалко данные, надо было забекапить образ диска перед переустановкой или не трогать.

ОП, приди на мой зов, пожалуйста! У меня такая же проблема. Я могу лишь подкинуть идейку, что всё это возникло после обновления не DirectX.

Решил не заниматься химией. Разобрал полностью оба левых наушника. Один таинственным образом сломал, а вот другой удалось оставить в живых.
Очистил канал звуковода, и всё заработало, почти как надо — почти, потому что забыл удалить серу с поролонового звукового фильтра, и левый всё же играет чуть тише правого.

Там обычно не в грязи дело, а в обрывании припаянных волосков что идут от клеенной катушки к контактам на магните. Ещё часто бывает что у них протирается изоляция и они коротят на железку по которой идут. Приходится разбирать их полностью, расклеивать остро наточенным ножом катушку, зачищать и изолировать провод, по новой паять и тогда всё зашибись во вки веков с этим ухом. Единственное что шанс сломать в процессе своими руками-брёмнами растущими из неправильного места выше 90%.
В целом конструкция что у копеечных, что у дорогущих наушников одинаково сопливая. Поэтому нужно брать либо наушники дешевле 50 рублей представив себе что ты играешь в гачу, либо действительно дорогие и как следует вникнуть в технические особенности того что покупаешь, чтобы не купить пустые понты.

>>214571
Тащемта, дешовые затычки это расходный материал, который при малейшей поломке попросту заменяется целиком. Покупай себе какие-нибудь TRN, KZ, и прочую китайчатину с претензиями. Там обычно встречаются чудесатые решения типа заменяемых кабелей, съемных патрубков и сеточек, которые можно открутить и промыть.

>>214580
Учитывая что ломаются обычно не в перечисленных тобой местах и правда чудные решения. Сеточки я и у копеешных менял.
Наушники нужно брать такие, чтоб у них динамики конструктивно не ломались в принципе. Тогда, возможно, ты им однажды нечаянно порвёшь провод, сломаешь штекер или расколешь корпус.

>>214622
Нуненаю... Я обычно провода рву...

>>214625
Странно. Я конечно знаю, что провода специально делают хлипкими чтобы люди себя во сне не душили, но последнее время как то попадались с достаточно крепкими, чтобы выдержать вырывание из ушей. В любом случае, провода чинить очень легко. Можно даже поменять на человеческие. Даже штекер, по сравнению с динамиком.

>>214629
Провода чинить легко, но нелегко не сломать наушник-затычку в процессе разборки.

Android general нет, спрошу пожалуй тут по аналогии. А пользуется кто-нибудь китайским QuickPic? Программа не поддерживается уже несколько лет, есть тормоза с прогрузкой картинок.
На что переходить с сохранением такой же минималистичности интерфейса? Как-то интерфейсы других ФП и галерей не нравятся, полностью заутятился тут.

>>214533
*ФМ

>>214533
На 4П был сильно допиленный вариант, якобы версии 8.х (официальный закончился на 5.0х). Посмотри в его сторону. У меня к нему нареканий вообще не возникает.

>>214536
Хе, была кстати перед постом такая мысль, что найдутся умельцы. Спасибо.

>>214533
Может что-нибудь такое? - https://f-droid.org/packages/com.simplemobiletools.gallery.pro

Сам пользуюсь, мне нравится.

>>214522
Ирфан не ставят ради минимализма, это вполне себе комбайн, причём довольно шустрый.

>>214566
А зачем комбайн на смотрелке фоток?

>>214567
Чтоб ради преобразования форматов (которое можно делать через консоль, BTW) и базового редактирования изображений не ставить совсем лютый комбайн типа Гимпа, Криты или Адобоподелия. Ну и ещё ряд плюшек, типа удобных сканирования и работы с многостраничными тифами, но это, конечно, не всем надо.

>>214568

>Чтоб ради преобразования форматов (которое можно делать через консоль, BTW) и базового редактирования изображений не ставить совсем лютый комбайн типа Гимпа, Криты или Адобоподелия.

JPEGView в это могёт, но результат надо сохранять отдельно.

Так, стоп, речь про винду? На десятке конечно уже не работает, но до этого до упора использовал PicaView 2.0 ещё с 98 винды. Очень удобно в контекстное меню встраивался, можно было в нём даже видео смотреть. Жаль больше не работает, кот бы форкнул.

>>214526
Если бы оно так и работало, то спустя некоторое время все бы диски начинали виснуть на элементарных файловых операциях как сагейт. Однако у других производителей хватило ума не создавать ещё один источник безграничной фрагментации физического расположения данных на поверхности. Да, реальное расположение данных отличается от виртуальной картины тома которую диск отдаёт наружу, однако в свободное время блоки возвращаются на место. Эту процедуру несведующие и путают с автоматической дефрагментацией данных.

>Дефрагментировать десятки часов многотеррабайтную помойку ради выигрыша в пару MBPS удовольствие сомнительное.

Старые заслуженные дефрагментаторы любой бардак меньше чем за сутки в порядок приводили. И продолжали незаметно его поддерживать. Утерянные технологии, блин. На самом деле нет. Просто перекочевали туда откуда простому юзеру не светит. А так же в некоторых свежих файловых системах алгоритмы подозрительно похожи.

>Данные в буфере не обрабатываются, иначе это не буфер.

Ну вот они не понимают, что там уже не правила файловой системы действуют, а контроллер диска работает с разметкой как с RAW-датой. Думают файлы последовательно считываются как при переносе с диска на диск.

Сообщение слишком длинное. Полный текст.

А что произойдет, если у SMR-диска, натужно в "свободное" время разгребающего записанное (ведь ОС уже полагает, что операция записи полностью завершилась), внезапно пропадёт питание?

>>214532
Data loss с неплохой вероятностью.

И это источник отдельной боли ниже спины.

>>214537
Не будет никакой потери данных.

Контроллер SMR диска по умолчанию пишет в быстрый не-SMR буфер размером несколько десятков гигабайт. Когда место в буфере кончается, контроллер вынужден начинать писать непосредственно в SMR. Это в целом тоже не проблема, пока есть полностью свободные зоны. А когда свободные зоны с кэшем кончаются и диску надо переписывать уже имеющиеся данные, начинается веселье вида последовательной записи со скоростью в 1-2МБ/с. По крайней мере, так себя ведут сигейты.

>>214540
У сигейтов ужасная проблема с физической фрагментацией, которая не лечится даже форматированием. Реальное местоположение лент всё больше отличается от виртуальной картины тома и в определённый момент начинает напоминать расположение данных на SSD. И они никак не борются с этим, в отличии от конкурентов. Во всяком случае до недавнего времени так было.

Тут недавно произошла приинтереснейшая ситуация. Потребовалось временно скопировать на SSD довольно крупный файл (примерно 60% от свободного места). Соответствующий объём был откушан почти моментально, после чего процесс завис где-то на 30% на скорости 7мб\с, постепенно продолжая откушивать дальше, пока не скушал всё. Вот теперь сижу, думаю что это было. Раньше ничего подобного не было. Правда и файлы такого объёма на SSD не помещались. Логично было бы провести проверку с искусственно созданными файлами разного размера и пройтись по логам, но очевидно что проще начать философствовать на ычане.

>>214540
Нет, будет. При перемещении данных из кеша на постоянное место хранения при условии закончившегося кеша и записи на дальние области пластин. Запаса питания на дозапись и парковку может не хватить, поскольку число элементарных операций значительно больше, чем в CMR.

>>214546

>При перемещении данных из кеша на постоянное место хранения

Невозможно переместить данные из кэша. Можно их прочитать в буферную память, прочитать туда же содержимое зоны SMR куда они должны быть записаны, произвести перезапись зоны теми данными что лежат в буфере, обновить таблицу местоположения блоков, и только после этого можно будет перезаписать данные в кэше чем-нибудь другим.

>>214540>>214546
Мне кажется, тут многое зависит от реализации конкретного производителя. Никто не мешает использовать одну из устоявшихся схем перемещения через копирование, когда последней операцией снимается метка с записанного блока данных и помечается как пустой старый. Что впрочем не означает, что не будет выбран самый простой или самый быстрый способ.

>>214543
Причина, внезапно, оказалась в крайне сильной фрагментации SSD. Причём виндовый дефрагментатор, перезагрузка и trim не помогли. Только сторонний дефрагментатор, который пол часа лопатил SSD. После чего объём отображаемого свободного места разительно увеличился, а проблема с пропаданием оного вникуда при записи файлов сверхбольшого объёма более не повторялась.