Я понимаю, о чем вы. Причина в том, что OS X использует NFD-нормализацию, в которой композитные символы типа "й", "ё" раскладываются на "и" и " ̆ ", "е" и " ̈ ". Проблема в том, что по какой-то причине ваша операционная система не умеет в корректный рендеринг юникода. В этой строке — ab͡cd, над какими символами у вас дужка?
"пересохранение без потерь" — а вы точно альфа-канал не выбросили? Я открыл в PsCC, пересохранил и результат со сжатием меньше только на один процент от исходного. ЧЯДНТ?
Когда мне прилетело обновление до 2.90, я нажал на "обновить". Увы, обновление не поставилось с формулировкой "неправильная подпись пакета обновления". Я плюнул и остался на 2.84.
1) нет, вы не поняли. Вот у вас есть поддержка ГОСТ А и ГОСТ Б, реализованная в ядре ОС. Тут приходит к вам подлое ЦРУФСБ, протягивает мульярд долларов и говорит проникновенно "прифет, малшик, реализуй нам, пашалста, поддершку AES256CTR". Если бы у вас шифрование было отделено от ФС, то вы бы просто сделали еще одну, полностью независимую шифровалку, которая регистрирует себя, как прозрачный обработчик файлов определенного типа, связанного с AES256CTR. Т.е. для определенных конфигураций у вас идет только ГОСТ, а для других — и ГОСТ, и AES256CTR, а ФС одна и та же, и реализации ФС глубоко плевать на данные — ей главное их хранить, а что внутри — не ФСное это дело.
А вот если же у вас шифрование является частью ФС, а то и вообще ядра, то просто добавить шифрование уже не выйдет — придется выпускать новую версию драйвера или ядра, а это простой системы, перезагрузки, ошибки внедрения, ошибки обратной совместимости, и всякие прочие проблемы, о которых начинаешь думать, когда они уже произошли, все потерялось и поздно пить ბორჯომი. А оно вам надо? Вы ж вроде надежностью занимаетесь.
2) Нет, вы все еще не поняли. Повреждение FAT — это, конечно, неприятно, но давайте лучше посмотрим на примере.
Согласно документации MS, максимальное количество безопасно адресуемых кластеров в FAT32 не может превышать 4177918, что при максимально разрешенном официальном размере кластера в 32 KiB дает нам чуть меньше 128 GiB данных. На самом деле, спецификация FAT32 позволяет использовать разделы размером до 16ТиБ, но далеко не все реализации смогут себе это позволить — так что считаем, что у нас винт в 128 GiB. Примем размер сектора за 512, т.е. итого у нас 268435456 секторов (v). Для раздела такого размера FAT займет почти 16 MiB, или же 32768 секторов (f).
Теперь оценим вероятности. Вероятность того, что один сбойный сектор попадет на FAT — f/v ≈ 2-13.
Вероятность того, что два сбойных сектора окажутся в двух копиях FAT — f2/v2 ≈ 2-26.
Вероятность того, что оба сбойных сектора окажутся в двух копиях FAT с одинаковым смещением — f/v2 ≈ 2-41.
Вероятность того, что три сбойных сектора окажутся в трех копиях FAT с одинаковым смещением — f/v3 ≈ 2-69.
Последствия одновременного сбоя одного сектора во всех копиях FAT — временная недоступность 128 записей, при этом сами данные остаются на диске и их можно восстановить с большой долей достоверности путем поиска потерянных цепочек кластеров. 128 записей соответствуют 4 MiB данных. Последствия сбоя одного сектора в области данных — утеря 512 байт данных.
——
Теперь берем OMFS3. Раздел в 128 GiB содержит 2097152 кластеров по 64 KiB каждый. "Битовая карта" занимает 2 MiB, или 4096 секторов (b).
Вероятность того, что один сбойный сектор окажется в "битовой карте" — b/v ≈ 2-16. Последствия утери 512 байт в битовой карте — потеря 512 записей о состоянии кластеров без возможности восстановления, т.е. 32 MiB данных.
Вероятность того, что один сбойный сектор окажется в "FAT" — 1-b/v ≈ 99.9985%. Любое повреждение почти всегда будет попадать на область данных. Последствия одного сбойного сектора в области данных — необратимая утеря второй половины файла, т.к. в ФС нет механизмов, которые бы позволили обнаружить ошибку или исправить ее.
——————
Вы все еще уверены, что ваша ФС может называться "надежной", если она проигрывает даже такому говну, как FAT?
Что мешает хранить в FAT шифрованные данные? — алгоритм, сжатие, вид шифрования, степень секретности — это всё нужно либо в файле хранить либо ОС должна думать. Тут это на уровне ФС атрибутов.
Нужно поменять алгоритм шифрования — придется менять драйфер ФС?
«Я заметил, но это «не в лоб, так по лбу» — разницы никакой, ведь все равно хранятся цепочки кластеров.» — не совсем, это нужно для реального времени работы, нету лагов по чтению и поиску неизветно где находящегося в FAT кластера.
Почему же «неизвестно где»? Смещение записи в FAT всегда известно с точностью до байта, а работа с жестким диском и реалтаймовость в принципе не совместимы, т.к. обычный жесткий диск не дает абсолютно никаких гарантий по поводу того, сколько будет длиться чтение отдельно взятого кластера.
Тут время предсказуемо, т.к. сразу получаем №след. кластера.
NCQ? Недостатки я описал выше — необратимая утеря данных и отсутствие возможности восстановления даже в теории.
ExFAT — лицензия + всё же не все атрибуты…
Произвольные расширенные аттрибуты, как и ADS, можно хранить и в обычном FAT, используя зарезервированные комбинации битовых аттрибутов — заодно это сохранит обратную совместимость с другими ОС.
там задел длдя шифрования (пока реализовано только для Windows-монтера)
Что мешает хранить в FAT шифрованные данные?
другая система адресации последующих кластеров (они хранятся непосредственно вконце текущего кластера)
Я заметил, но это «не в лоб, так по лбу» — разницы никакой, ведь все равно хранятся цепочки кластеров.
в FAT нужно при чтении иметь ввиду (и в памяти) всю FAT с указателями на кластеры
Нет, с чего вы решили? Посмотрите спецификацию, саму FAT можно без каких-либо проблем читать on-demand. Просто держать ее в памяти удобнее, т.к. размер небольшой, а профиты в виде read ahead очевидны. В вашей же схеме read ahead сделать не получится.
некоторые мелочи (гирокие атрибуты, 64 бит timestamp и др.)
ExFAT? ;)
И да, если вы делаете упор на безопасность, подумайте о следующей ситуации — подлое ЦРУФБР уничтожило один кластер, который находится как раз посреди вашего файла. Что случится с FAT? В FAT файл будет с дыркой, но остальное прочитается. У вас, если же это был не самый последний кластер файла, хвост будет невозможно прочитать. Что будет, если повреждение придется на саму FAT? Ничего, т.к. в FAT есть возможность создавать теоретически неограниченное количество копий FAT (на практике, как правило, используются две). Т.е. при одинаковых условиях ваша ФС не сможет ни задетектить ошибку, ни исправить ее, ни предотвратить дальнейшую утерю данных.
Есть класс участников рынка, которые называются "агрегаторами ликвидности". Их работа заключается в том, что они собирают и исполняют заявки из нескольких разных источников, приоретизируя их при необходимости. К агрегаторам могут подключаться владельцы биржи напрямую, либо же агрегаторы могут участвовать в торгах как обычные участники.
Т.е. в принципе, стакан цен у ММВБ и у CHX в теории может частично пересекаться — у ММВБ и у CHX могут быть как полностью локальные заявки, которые исполняются исключительно в пределах соответствующих бирж (т.е. обе стороны контракта должны быть клиентами одной биржи), так и кросс-биржевые заявки, которые анонсируются и исполняются агрегатором (у каждой биржи второй стороной сделки является агрегатор). Кому отдавать приоритет и когда — дело исключительно самой биржи, как и то, к каким агрегаторам подключаться.
То, что вы описали, является естественной картиной рынка — предложения, как правило, не пересекаются в стакане, т.к. если пересечение присутствует, то соответствующие заявки в разных направлениях по одной цене должны быть погашены и снова возникнет дырка между bid и ask. В вашем примере 75.7-75.5=0.2 RURUSD и будет спредом. В любой момент времени есть две рыночных/биржевых цены — это цена наилучшего предложения по продаже (т.е. 75.7) и цена наилучшего предложения по покупке (т.е. 75.5).
Что имеется в виду под "синхронизацией"? Есть ли какое-то подтягивание RURUSD к EURUSD, чтобы доллар был там и там одним и тем же? Если так, то никаких подобных механизмов нет.
А вот если же у вас шифрование является частью ФС, а то и вообще ядра, то просто добавить шифрование уже не выйдет — придется выпускать новую версию драйвера или ядра, а это простой системы, перезагрузки, ошибки внедрения, ошибки обратной совместимости, и всякие прочие проблемы, о которых начинаешь думать, когда они уже произошли, все потерялось и поздно пить ბორჯომი. А оно вам надо? Вы ж вроде надежностью занимаетесь.
2) Нет, вы все еще не поняли. Повреждение FAT — это, конечно, неприятно, но давайте лучше посмотрим на примере.
Согласно документации MS, максимальное количество безопасно адресуемых кластеров в FAT32 не может превышать 4177918, что при максимально разрешенном официальном размере кластера в 32 KiB дает нам чуть меньше 128 GiB данных. На самом деле, спецификация FAT32 позволяет использовать разделы размером до 16ТиБ, но далеко не все реализации смогут себе это позволить — так что считаем, что у нас винт в 128 GiB. Примем размер сектора за 512, т.е. итого у нас 268435456 секторов (v). Для раздела такого размера FAT займет почти 16 MiB, или же 32768 секторов (f).
Теперь оценим вероятности. Вероятность того, что один сбойный сектор попадет на FAT — f/v ≈ 2-13.
Вероятность того, что два сбойных сектора окажутся в двух копиях FAT — f2/v2 ≈ 2-26.
Вероятность того, что оба сбойных сектора окажутся в двух копиях FAT с одинаковым смещением — f/v2 ≈ 2-41.
Вероятность того, что три сбойных сектора окажутся в трех копиях FAT с одинаковым смещением — f/v3 ≈ 2-69.
Последствия одновременного сбоя одного сектора во всех копиях FAT — временная недоступность 128 записей, при этом сами данные остаются на диске и их можно восстановить с большой долей достоверности путем поиска потерянных цепочек кластеров. 128 записей соответствуют 4 MiB данных. Последствия сбоя одного сектора в области данных — утеря 512 байт данных.
——
Теперь берем OMFS3. Раздел в 128 GiB содержит 2097152 кластеров по 64 KiB каждый. "Битовая карта" занимает 2 MiB, или 4096 секторов (b).
Вероятность того, что один сбойный сектор окажется в "битовой карте" — b/v ≈ 2-16. Последствия утери 512 байт в битовой карте — потеря 512 записей о состоянии кластеров без возможности восстановления, т.е. 32 MiB данных.
Вероятность того, что один сбойный сектор окажется в "FAT" — 1-b/v ≈ 99.9985%. Любое повреждение почти всегда будет попадать на область данных. Последствия одного сбойного сектора в области данных — необратимая утеря второй половины файла, т.к. в ФС нет механизмов, которые бы позволили обнаружить ошибку или исправить ее.
——————
Вы все еще уверены, что ваша ФС может называться "надежной", если она проигрывает даже такому говну, как FAT?
Почему же «неизвестно где»? Смещение записи в FAT всегда известно с точностью до байта, а работа с жестким диском и реалтаймовость в принципе не совместимы, т.к. обычный жесткий диск не дает абсолютно никаких гарантий по поводу того, сколько будет длиться чтение отдельно взятого кластера.
NCQ? Недостатки я описал выше — необратимая утеря данных и отсутствие возможности восстановления даже в теории.
Произвольные расширенные аттрибуты, как и ADS, можно хранить и в обычном FAT, используя зарезервированные комбинации битовых аттрибутов — заодно это сохранит обратную совместимость с другими ОС.
Я заметил, но это «не в лоб, так по лбу» — разницы никакой, ведь все равно хранятся цепочки кластеров.
Нет, с чего вы решили? Посмотрите спецификацию, саму FAT можно без каких-либо проблем читать on-demand. Просто держать ее в памяти удобнее, т.к. размер небольшой, а профиты в виде read ahead очевидны. В вашей же схеме read ahead сделать не получится.
ExFAT? ;)
И да, если вы делаете упор на безопасность, подумайте о следующей ситуации — подлое ЦРУФБР уничтожило один кластер, который находится как раз посреди вашего файла. Что случится с FAT? В FAT файл будет с дыркой, но остальное прочитается. У вас, если же это был не самый последний кластер файла, хвост будет невозможно прочитать. Что будет, если повреждение придется на саму FAT? Ничего, т.к. в FAT есть возможность создавать теоретически неограниченное количество копий FAT (на практике, как правило, используются две). Т.е. при одинаковых условиях ваша ФС не сможет ни задетектить ошибку, ни исправить ее, ни предотвратить дальнейшую утерю данных.
Т.е. в принципе, стакан цен у ММВБ и у CHX в теории может частично пересекаться — у ММВБ и у CHX могут быть как полностью локальные заявки, которые исполняются исключительно в пределах соответствующих бирж (т.е. обе стороны контракта должны быть клиентами одной биржи), так и кросс-биржевые заявки, которые анонсируются и исполняются агрегатором (у каждой биржи второй стороной сделки является агрегатор). Кому отдавать приоритет и когда — дело исключительно самой биржи, как и то, к каким агрегаторам подключаться.