Алготрейдинговый гигант открыл исходный код TernFS для Linux

Спасибо, там хоть прочитал нормально. Про разграничение прав доступа - интересно получилось. Интересно, неужели даже деления на чтение и запись нет.

Например, завышая цену продаваемого товара спекулянт заваливает торговую площадку ложными заявками,

Почему ложными, они реальны. Все заявки на площадке - реальны. Хош покупай, хош не покупай. Это поведение ничем не отличается от «не продавать». У владельца N есть N, он это N не продаёт и оно тихо лежит. Либо владелец N выставил заявку на продажу по цене 100500 и оно тоже тихо лежит. В обоих случаях результат какой? Он одинаков. Разве что, во втором случае N хотя-бы можно купить, если СИЛЬНО НАДО ПРЯМ ЩАС. А площадке пофиг, она железобетонная, рассчитана на тонну заявок в наносесекунду, она электричества жрёт одинаково дохрена в любой момент времени.

мешая остальным купцам выставлять свои заявки на продажу товара по более низкой цене

Чиво, карл? Как мешая? Никак. Любой, кто выставит заявку о продаже N по цене ниже чем 100500 сразу же будет видим всеми, причём в более приоритетной точке, чем лежит заявка по 100500 - наверху стакана. Заявки о продаже по цене 100500 никого не будут волновать и не волнуют.

По сабжу: я наверное туповат, но сделать ФС, которая хранит тыщи тонн неизменяемых файликов от нескольких мегабайт до произвольного объёма - это какая-то детская задача, как раз потому что никаких тебе проблем дефрагментации, переаллокации и прочей мутотени. Положил файлик в конец «арены» и он у тебя там просто лежит. Ты буквально берёшь диск и начинаешь выделять сектора начиная с нулевого каждому следующему файлу, которому нужно место, если место ещё есть. Арена-аллокатор поверх диска. В чём достижение? Ну да, ещё индекс где-то там, который по имени файла находит с какого он сектора начался и где закончился. Или эти файлики могут удаляться? Тогда да.

Делаю фреймворк для алготрейдинга, ищу единомышленников (Python/Rust) (комментарий)

Так это на их стороне сломано, пускай найдут себе студента-админа какого за пиво, нам-то зачем им что-то чинить

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

Так со многими, редко посещаемыми сайтами

ТТК в эту же копилку, обратил внимание, что бывают случаи, когда сайты открываются со второго и более раза

П.С. наверное правильнее говорить о ТСПУ-эффекте

бакап

В свете проблем с прочтением заголовка темы, прочитал это как «бокал». Много думал.

как раз потому что никаких тебе проблем дефрагментации, переаллокации и прочей мутотени. Положил файлик в конец «арены» и он у тебя там просто лежит. Ты буквально берёшь диск и начинаешь выделять сектора начиная с нулевого каждому следующему файлу, которому нужно место, если место ещё есть. Арена-аллокатор поверх диска.

«Ох уж эти сказки! Ох уж эти сказочники!..»

Это так «работает» на любой фс, пока достаточно свободного дискового пространства (СДП). Но СДП имеет свойство рано или поздно заканчиваться — вот тогда-то все вот эти ваши «никаких тебе проблем» заканчиваются и начинается... и начинается реальная жизнь. ;P ;)) :)))

Или эти файлики могут удаляться?

Прикинь, да?!.. ;D Эти файлики — они такие!.. ;))

детская она в общем ( впрочем как и всё в этом мире - теорема ферма ; abc-гипотеза ; emc2 ; уравнения максвела в нотации векторов ; ... )

не детская как раз на краях - масштабы «данные в эту эпоху не помещяются в одно хранилище но помещается в хранилище хранилищ» и вследсвии этого вылазит вопрос когерентности и доп надёжности при минимизации издержек на текущем железе

так то детская

зы. чел из нму

в таких случаях создаю папку to_del (где удобно), переношу туда удаляемо-переносимый материал и получается обычно, что в «следущий раз» содержимое папки to_del уже не актуально (обычно так).

с корзиной как-то не сдружился :о)

что либо то, либо другое.

Ты просто не смог нащупать пик Балмера :-)

Хотел бы я флэшку на эксабайтик :)

Мой первый носитель информации был размером, кажется, порядка мегабайта, это была магнитофонная кассета, на которую записывались программы для Микроши. Сейчас примерно в том же размере можно купить носитель информации объёмом в терабайт. То есть, можно сказать, в плане ёмкости носителей информации за этот период сделаны два больших «шага» - от мегабайта к гигабайту и, далее, к терабайту. До эксабайта тоже в принципе два таких «шага» - после терабайта идёт петабайт и, далее, эксабайт. Понятно, что нет никакой гарантии того, что это достижимо, но, в принципе, вполне возможно, что будут и такие флешки через десятилетия. Вот только как разбирать хлам на такой флешке, это сколько лет потребуется для того, чтобы решить, что нужное, а что нет?

У меня «важной» инфы гигов 15 за всю жизнь и то руки не дойдут подразобрать и старьё выкинуть. А всё что у меня на рабочих-домашних компах я по дефолту считаю ссаниной и не бекаплю никуда)

Я

микропроцессорная революция о которой так шумели в 75-89 гг

интенсивно происходит ща c ~2023 гг

ибо в 75-89(и до «2023») все излишки внедрения мп уходило «наверх»

а вот «ща» реально

Ты знаешь, что бесконечно уменьшать нельзя? Ты собрался уже на атомах гравировать свои данные, снутри и снаружи? Не будет эксабайта в таком размере. Клык соседа даю на это :)

А Микроши были у всех разные :) Тёплые воспоминания о холодных вечерах проведённых за написанием игр, программированием картинок на бейсике, первые спрайты псевдографикой... мммм... И когда ломался мафон, оставалось только смотреть на мигающее приглашение, ведь даже бейсики надо было загружать в память.

Накопитель на спинах электронов )

на спинах

Мне сразу вспомнился Яшка-Циган, из неуловимых мстителей. Ему там тоже на спину хлыстами «на память» записывали. Как мне стало жалко этих электронов :))

Если серьёзно, с развитием 5G - 6G сетей связи, накопители не понадобятся, в телефонах будет только память для ОС, а вообще всё сразу в облако. Незачем будет держать всё в аппарате. Так что свои эксабайты в ноутбук ты ещё можешь закинуть.

naked - графия

ну и ваще длина планка 10-41 так что место для битиков полно

Это не с развитием связи, а с развитием жадности производителей. А связь ради этого и подтягивали.

А чем такое писало сделать, чтобы прокорябывать надписи на этих ваших планках? :)

По ссылкам есть немного информации про вероятность потерь в зависимости от скорости падежа дисков и это хорошо. В качестве замены ленточных библиотек выглядит интересно.

Но к сожалению нет информации по скорости доступа к данным. Так же нет сравнения с другими распределёнными FS, например, Ceph, стабильная версия которой появилась почти десять лет назад. Так что запасаемся попкорном и ждём тестов.

«Как я перестал волноваться и полюбил экзабайт... » :)

Из ссылки с гитхаба:

The main obstacle when exposing TernFS as a 'normal' filesystem is that TernFS files are immutable. More specifically, TernFS files are fully written before being 'linked' into the filesystem as a directory entry. This is intentional: it lets us cleanly separate the API for 'under construction' files and 'completed files', and it means that half-written files are not visible.

However this design is essentially incompatible with POSIX, which endows the user with near-absolute freedom when it comes to manipulating a file. Therefore, the TernFS kernel module is not POSIX-compliant, but rather exposes enough POSIX to allow many programs to work without modifications, but not all.

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

Это потому что Линукс ненавидит пользователей.

норм. «и опыт - сын ошибок трудных…» надо нарабатывать на своей заднице.

More specifically, TernFS files are fully written before being ‘linked’ into the filesystem as a directory entry. This is intentional: it lets us cleanly separate the API for ‘under construction’ files and ‘completed files’, and it means that half-written files are not visible.

Я делаю гораздо проще: записываю данные файл на диск с именем «DateAndTime.tmp», сбрасываю буферы данных из ОЗУ на диск, а затем переименовываю расширение файла на «DateAndTime.txt». Недописанные до конца файлы будут иметь расширение «tmp», а полностью записанные и готовые к последующему чтению - «txt».

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

Так им распределенная ФС нужна жЫ! А GFS Гугл не открыл до сих пор, как я понимаю.

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

Байтики поэкономить. На журнал, на ещё что-то там.

Так им распределенная ФС нужна жЫ!

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

Если пренебречь «удобствами», то какой еще смысл в распределенной файловой системе?

Я не спец в теме, но из общепрограммистских соображений предлагаю спердобиться. То есть реализовать эту «детскую задачу» и выложить код на гитхаб, гитфлик, гит.орг.ру… куда угодно.

Если твоя ФС порвёт в клочья сабж – поздравляю, ты выиграл. Я, кстати, такого варианта не исключаю :)

// Да, это отсылка к «Talk is cheap. Show me the code».

Если пренебречь «удобствами», то какой еще смысл в распределенной файловой системе?

В том, что с каждого хоста, где она смонтирована, ее видно всю. И не надо думать, про то, в сколько мест и что надо писать. И дисковая емкость твоего хоста просто отдается в общий пул. Этакий распределенный NAS получается.

А если диски эти у тебя по всему миру размазаны и часть секторов в Гонконге, а часть в Нью-Йорке?

Для меня лично эта файловая система, как динозавру счёты. Для компаний да, но для локаничного пользователя она бесполезна. Я ценю ext4 и бтрфс. Раньше ещё рейзерфс, но и она испарилась из ядра.

для локаничного пользователя

Для какого??.. ;P ;))

И это тоже перепишут на Расте. Но потом. Как-нибудь.

Как-нибудь

И кое-как, да...

Wow! DNA could store Petabytes and is only 5 years away, new report says

Локана и его последователей стыдно не нать

«Как скажешь, начальник!» :)

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

Прочитал как «Алкотрейдинговый гигант открыл …».

Данные выстреливаются с дублежом где0то в 10**5
самое проворное данное вносится в репликатор

чё как малэнкий!?

Чуо? А говорю, дээнку ты эту напрограммируешь, а она тебя сожрёт мутировавши на твоих данных

эйволюцио!

Я когда-то считал, что писать код под пиво это круто и романтично. А когда попробовал (не по работе, естественно) – понял, что либо то, либо другое.

Вот соглашусь. Бывает что под пиво круто код писать, бывает что и романтично, но и совместить никак не удается…

А ты попробуй не на плюсах, а на перле :)

Ну, работать это, возможно будет. Но вот понять, как оно работает уже не удастся…

Накопитель на спинах электронов )

На фермионах делать накопитель нерационально - Ферми-Дирак против. А вот на бозонах - самое оно. Всю информацию мира можно в одно маковое зернышко упаковать, так что подумай о гравировке на фотонах