В рамках проекта Zero (https://github.com/KonstantinSchubert/zero) ведётся разработка экспериментальной многослойной файловой системы с реализацией идеи хранения данных в локальной ФС с вытеснением давно не используемых данных во внешнее облачное хранилище. Код предлагаемого для тестирования прототипа написан на языке Python, использует подсистему FUSE и поставляется (https://github.com/KonstantinSchubert/zero) под лицензией MIT.
Первый слой, размещаемый в локальной ФС, выступает в роли кэша, в котором доступны только актуальные данные. Таким образом, на базе ограниченного по размеру локального накопителя можно создать архивное хранилище существенно большего размера, выглядящее как одна целостная ФС. В настоящее время из облачных хранилищ поддерживается только сервис Backblaze (https://en.wikipedia.org/wiki/Backblaze).
URL: https://news.ycombinator.com/item?id=17948287
Новость: https://www.opennet.me/opennews/art.shtml?num=49249
Вот и верь людям, что Питон меленный. :)
Где ты прочитал что прототип работает быстро? Желаемое за действительное не выдавай.
У говнокодеров и си с ассемблером медленные.
> У говнокодеров и си с ассемблером медленные.И это логично. Чтобы было быстро - надо понимать как работают компьютеры. Переклиненые на высоком уровне не понимают как работает компьютер. Они всячески избегают это знание. Ясен хрен что если сделать процессору, памяти и прочим подсистемам неудобно - эпикфэйл может выйти даже на си и ассемблере. Нормальные то программисты начинают с азов. Эффективных структур данных и алгоритмов и понимания во что это превращается в железе, все такое. Самые крутые оперируют весьма нетривиальными понятиями, типа "линии кэша". Они делают странные пасы руками, призывают очень странный подвид бабочек, а те взмахнув крыльями вызывают такие возмущения электромагнитного поля планеты что программа почему-то начинает работать в разы быстрее. Хотя, вроде бы, в тексте программы почти ничего не изменилось. Ну там подвинул пару переменных немного, размерность чуть поменял. Откуда бы там выигрыш в 2 раза наступает? Для тех кто не понимает как это работает - это выглядит как черная магия.
Воланд?
>Переклиненые на высоком уровне не понимают как работает компьютер
>программа почему-то начинает работать в разы быстрееБрэд оф сив кэйбл :) Ещё деда Кнут завещал не чинить то, что не сломано.
Если надежная распределенная система упирается в например сеть, то смысла упарываться над утрамбовыванием чего-то в L2-кэш ноль целых ноль десятых.Итого по "надо понимать как работают компьютеры"... Подавляющему большинству это не надо.
А что, с сетью таких факапов не бывает? Когда кодер меняет тип с int на short и вдруг все начинает передаваться в два раза быстрее - просто потому, что влазит в один пакет, а не два. Или выбирает правильный Endianness для кодирования данных и они не перекодируются туда-сюда при отправке. Да дофига такого.
>Когда кодер меняет тип с int на short и вдруг все начинает передаваться в два раза быстрееКакие фантазии. Напрямую TCP пакеты создаёшь? У нормальных пацанов по сети ходит XML over HTTP :D
Ты не понял. Главное - быстрее кодить. Взять какую-нибудь обертку над какой-нибудь оберткой, которая выполнена в виде обертки над оберткой, написанной на высокоуровневой обертке. И все это должно запуститься. Если размер будет большой, то сожмем архиватором, а его библиотеки тоже присобачим. А если будет медленно, то Intel пообещает еще более быстрые процессоры с новыми оптимизациями оптимизаций.
Он и есть медленный. Но для некоторых применений - вполне годится. Особенно для прототипов вроде этого.
> Особенно для прототипов вроде этого.Это отговорки слабаков и шkoлоты, неосиливших си и изначально грамотное проектирование.
Профессианальные разработчики опеннета подтвердят!
Изначально грамотное проектирование подразумевает отсутствие C в любом виде.
А что, ты уже переписал фирмвари, бутлоадер, ядро ОС и ключевой софт запускающий систему на чем-то еще? А то без этого компьютер вообще не запустится. И, кстати, булки на деревьях тоже не растут.
> для прототипов вроде этого.А в чем прикол делать прототип откровенно говняно, без перспектив его сделать нормальным, с заведомым попаданием на переписывание, если вдруг это вдруг заработает? Програмеры настолько лузеры что дают 9 из 10 что проект вообще не взлетит?
>> для прототипов вроде этого.
> А в чем прикол делать прототип откровенно говняно, без перспектив его сделать
> нормальным, с заведомым попаданием на переписывание, если вдруг это вдруг заработает?
> Програмеры настолько лузеры что дают 9 из 10 что проект вообще
> не взлетит?То ли дело анонимы опеннета, сразу знающие, как надо правильно и что и как взлетит!
Они бы наверняка и свою реализацию битторента на сишке вместо мерзкого бидoна накатали, да только были заняты комментированием на опеннете и какой-то Брэм, пользуясь ситуацией, их опередил. А так бы анонимы всем показали бы!
> Они бы наверняка и свою реализацию битторента на сишке вместо мерзкого бидoна
> накатали, да только...да только сишники тоже сцуко ленивые, поэтому возьмут готовую либу вместо этого. Которую до них накорябали другие сишники. Ну вон функциональность transmission - вынесена в libtransmission, например. Есть пара сторонних клиентов которые ими пользуются. Например, transmitter. Еще плюсатых несколько штук как минимум.
Собственно, именно оригинальной пыхтонреализацией торента как раз никто и не пользуется уж давно. Потому что нафиг кому это убогое тормозило? Единственное что на память об этом уроде осталось - дeбильные форматы данных в протоколе. Полутекст, полубинарь, на глаз малочитаемо, машине парсить не быстро. Сразу видно - питонист делал: мастерски хряпнул недостатки всех подходов и изящно их соединил.
Если кто не знает - убогую пыхтонподелку в свое время жестко замяла небольшая плюсатая прожка под винду. Бинарь всего кил на 200, чтоли. При этом в десятки раз быстрее, умеет в 100500 раз больше, качает параллельно кучу всего, и вообще - нормальная качалка. Плюсатую прожку звали uTorrent. И Кохему пришлось резко купить это и забить на питономакет болт. Под страхом кончины компании. В мире где для битторента написали на сях и плюсах реализаций питономакет просто пролетает.
>> Они бы наверняка и свою реализацию битторента на сишке вместо мерзкого бидoна
>> накатали, да только
> ...да только сишники опеннета тоже сцуко ленивые, поэтомуПоэтому предпочитали комментировать на опеннете, вместо ваяния _первой_ реализации. А так да, опеннетные анонимные сишники бы всем показали!
> Собственно, именно оригинальной пыхтонреализацией торента как раз никто и не пользуется
> уж давно. Потому что нафиг кому это убогое тормозило? Единственное что
> на память об этом уроде осталось - дeбильные форматы данных в
> протоколе. Полутекст, полубинарь, на глаз малочитаемо, машине парсить не быстро. Сразу видно - питонист делал:То ли дело аноним - он бы сделал все правильно, сразу! Если бы не более важные дела - кошечку с дерева снять, на опеннетике покомментировать.
> Если кто не знает - убогую пыхтонподелку в свое время жестко замяла
>
> питономакет болт. Под страхом кончины компании. В мире где для битторента
> написали на сях и плюсах реализаций питономакет просто пролетает.Ловкий перевод стрелок.
Но вопрос, почему сперва появился питономакет и только потом подвалили реализаторы (и сильно потом - анонимы опеннета, знающие как на самом деле нужно было делать сразу правильно) так и не раскрыт. Тайна анонимной вселенной, не иначе!
>А в чем прикол делать прототип откровенно говняноНу вот например есть носкль Cassandra которую лузеры накуякали на тормозной жабке, уже много лет назад. Она с тех пор съела хорошую долю рынка. Её прогеры щас в шоколаде. А могучие сишники всё рожают рожают свою Сцыллу, да дальше потуг и лживых воплей что это drop-in replacement не пошло.
Причём шансов догнать Касю у них ноль, т.к. развитие у Каси идёт быстрее, чем у сишного клона.
Итого прогеры Сцыллы так и будут всю жизнь дошираком питаться (пока не поумнеют).
> для некоторых применений - вполне годится.Нет
Прототип, который быстро сделан на python для посмотреть "ну вот как-то примерно так", вовсе и не обязан быть быстрым. Более того, даже полностью рабочим быть не обязан, хотя и желательно.
Зато надежно выдает авторов. Все слагаемые на месте: пермиссив, тормозной ЯП для быстрого создания макета, все баззворды собрали. В общем самое то чтобы слепить стартап и потом слить его лоху^W инвестору подороже. Главное чтобы тот не понимал какое гуано купил, а при достаточном пиаре - некоторая масса хомяков создаст видимость успеха.
Python действительно медленный если не применять оптимизации и вынос критичного ко времени исполнения кода на С. Но если все сделать правильно, то даже игры можно написать - как пример EVE Online.
>Но если все сделать правильно, то даже игры можно написать - как пример EVE OnlineТолько вчера читал, как EO люто тормозит во время более-менее крупных боёв. При том, что разрабы про это знают и теребонькают свои облака шоб расширились побольше, да не помогает.
Еще бы. Даже и не знаю, реально ли вообще сделать бои подобного масштаба без тормозов. Наверное... все-таки нет.
пихон, fuse, зеро...зеробрейн. "вытесняйте" уже сразу в /dev/null - меньше возни, все равно данные, к которым обращаются (точнее, уже перестали) через кривую пихоновую прослойку через fuse, нахрен не нужны.видимо, это попытка бэкблажи, неосилившей в webbdav, выдумать свою альтернативу fuse-davfs. Менеджер по антикачеству при этом старательно следил, чтобы она, ненароком, не оказалась не точно такой же тормозной, бестолковой и ненадежной, как оригинал, а то гугель засудит!
Сколько стонов. Ну нравится fuse-davfs - используй, кто запретит. Поглядим, как у этих получится, но лично мне идея явного отделения бакэнда нравится (и всегда нравилась, как и прочие плагинные подходы).Питон... что питон? Для прототипа - точно подходит, а там будет видно, вышло ли что-то вменяемое.
> Поглядим, как у этих получится, но лично мне идея явного отделения бакэндатут нет никакой новой идеи - davfs устроена точно так же.
"нового" тут только модная-современная концепция layered fs, и автоматика "вытеснения".
Но, поскольку оно явно будет тормозным как телега, запряженная ишаком (не вытеснение а сам доступ к чудо-fs), вряд ли кому-то понадобится.модные разработчики, видимо, не очень понимают, где "быстрое прототипирование" уместно, а где надо сразу делать правильно, а не пихоновый скрипт пропихивать через fuse.
Так привык к mount/umount, что отсутствие необходимости использовать их вызвало болезненные ощущения чуть пониже спины.
Как она устроена? У неё жёстко прибитый один бэкэнд - webdav. И если захочется поддержку того же balckblaze или вообще ftp прикрутить - делай отдельный проект и копипасти в него логику вытеснения, или как? Я бы, правда, дальше пошёл и реализовал ТОЛЬКО вытеснение, оставив релаьную работу нижележащим ФС - пофиг, FUSE или нет, но даже так лучше, чем один-единственный протокол.А для кучи сценариев тормозность чего-либо, кроме собственно сетки и чтения/записи большими кусками (чему ни fuse, ни его питоновский API вообще не мешают) проблемой не являются. Начиная с того же фотоархива, например.
А чем собственно webdav плох? Чем плох FTP и backblaze - понятно. Первый в половине конфигураций не работает и еще тормознее чем webdav во многих случаях, потому что новое соединение для каждого файла, так что заливка мелочи на FTP это полный трэш. Backblaze просто проприетарное нестандартное нечто, дергаться на причуды каждого пихтонраста с его личным Not Invented Here с своим самопальным сервисом - никаких ресурсов не хватит.
> А чем собственно webdav плох?а чем может быть хороша попытка приспособить гипертекстовый протокол под файловую систему?
ну да, ну да - ловко туннелится через корпоративные проксики. И все.
> потому что новое соединение для каждого файла
в новом-не-tls-соединении для каждого файла нет ничего ужасного.
Файл еще и создать надо, причем правльно - там в fs масса всего интересного, чтобы при крэше не получить вместо диска вермишель. И ничего, создается. Кода раз этак в тысячу поболее.> Backblaze просто проприетарное нестандартное нечто
да, диавольщина и бесовщина, срочно трижды переГНИсь, трижды поклонись иконе встолмана, и никаких больше соблазнов.
backblaze оптимизирован под совсем другую задачу. которую в целом решает неплохо.
Сделать на этой базе блочный уровень fs - вполне можно, и даже, наверное, будет эффективно.
Плох не webdav, ftp или backblaze, плохо, когжа пытаются прибить гвоздями к чему-то одному то, что вполне может работать с разными альтернативами.
> Плох не webdav, ftp или backblaze, плохо, когжа пытаются прибить гвоздями к
> чему-то одному то, что вполне может работать с разными альтернативами.С другой стороны когда начинается абстрагирование абстракций и модуляризация модулей, на всякий пожарный, авось пригодится - получается угробищный монстр, который толком не работает. Потому что запутался в своих нагромождениях абстракций.
Классический пример GIO и KIO, или как там это в кедах ща называют. Блин, не попадалось ни одной безглючной проги на этом. А если оно не дай боже по сети было - при первом намеке на проблему сильно повезет если прога не зависнет намертво или не грохнется целиком. Ну вот как-то так это на практике работает.
конкретно эта штука - не может, у нее заточка под интерфейс, предназначенный для хранения блобов, а не файлов, насколько я понимаю.
Там достаточно много ручной работы по имитации фс поверх всего этого.причем он у бэкблейзов, походу, свой, несовместимый с амазоновским.
И я не нашёл вообще никакой свзяи автора с backblaze. Ну выбрал человек то хранилище, которое ему наиболее удобно или которое лично использует - так это самый правильынй подход. Благо они нынче ещё и самые дешёвые среди живых.
fuse-davfs не умеет кешировать. Поэтому работает только в сферической сети в вакууме.
Шизика это не остановит от критики, у него в бреду свой собственый мирок.
~# umount /mnt/dav/
/sbin/umount.davfs: waiting while mount.davfs (pid 32292) synchronizes the cache ...довольно таки долго и печально.
Но кэширование и вытеснение редкоиспользуемых файлов - совсем разные вещи. Второе делается гораздо проще.
Это совсем другая задача, ага.
>"вытесняйте" уже сразу в /dev/null - меньше возни, все равно данные, к которым обращаются (точнее, уже перестали) через кривую пихоновую прослойку через fuse, нахрен не нужныКоннекты через 2.5G/3G ещё не исчезли, особенно за МКАДом. Так что, Python здесь не добавит тормозов.
>>"вытесняйте" уже сразу в /dev/null - меньше возни, все равно данные, к которым обращаются (точнее, уже перестали) через кривую пихоновую прослойку через fuse, нахрен не нужны
> Коннекты через 2.5G/3G ещё не исчезли, особенно за МКАДом. Так что, Python
> здесь не добавит тормозов.угу, оно просто работать не будет (это ж хоть и не дав, но вебня, там таймауты и обрывы сессии норма). Ну ты с ума сошел, автоматическое выдавливание неиспользуемых файлов/подкачку обратно если вдруг стал используемый, делать через "2.5g" ?
очевидно, это вообще не тот случай, когда можно использовать облачные хранилки, нет связи - ну так значит судьба тебе хранить все на точке (или наоборот, не хранить ничего вообще, по максимуму вытащив оттуда все поближе к нормальным каналам и большим дискам)
Ну так оборвалось - не вытеснил, какаие проблемы? Это уже ответственность пользователя - решать, что ему годится.
> Ну так оборвалось - не вытеснил, какаие проблемы?Да какие, обычные: питонятина стандартно забьет на ошибки - ведь на машине разработчика этот кал как-то работал же на 127.0.0.1. Про то что может еще и ошибка диска вылезсти - питонисты вообще не догадываются. И если не дай боже при ворочании терабайта всрется бэд, одному ктулху известно что будет дальше.
Так что как минимум такое добро на раз высадит трафик, как максимум порушит данные. Когда данные наконец потребуются обратно, сильно повезет если версия питона в системе окажется "та", это не обваливается с трехстраничным трэйсом, и в данных не вермишель. В общем это выглядит очень оверинженернутым вариантом rm -rf.
Да оно и на ста мегабитах ни хрена тормозить не будет, если /usr/portage или что-то подобное на него не совать.
> Да оно и на ста мегабитах ни хрена тормозить не будет, если
> /usr/portage или что-то подобное на него не совать.Главное запускать эту парашу на локалхосте разработчика и только правильной сети и файлах. Называя вещи своими именами, совершенно не обязательно пиарить очередной высер-макет для впаривания лох-инвесторам в новостях. Ну или пусть такие проекты как минимум платят за рекламу. Потому что макет программы по впариванию какого-то клауда занахаляву рекламить - жирно больно. Это спамом называется.
> Python здесь не добавит тормозов.Он уже добавил сотни тысяч торомозов - в IT.
Интересная идея.
Можно создать хранилище документов гибридное и в итоге обращаться к актуальным документам быстро, а то, что уже не нужно, будет автоматически в облако уходить, когда потребуется обратно затягиваться. Шарить удобно их между компьютерами (если синхронизация будет отлажена хорошо)Если винт грохнется, то всегда можно восстановится. Единственный минус. Это вирус шифровальщик - если зашифрует, то зашифруется и в облаке.
Вот и снова ФС Джорж, 40 лет прошло, а идеи теже )))))
Хотя есть и новое - теперь вместо лент - облако, все же прогресс не остановить
В нетвари оно вообще прям из коробки работало.
> Единственный минус. Это вирус шифровальщик - если зашифрует, то зашифруется и в облаке.в "нормальных" облаках есть версионность, так что не критично, имхо
Какая связь облачности и версионности? Ты какие облака называешь нормальными? S3?
> Какая связь облачности и версионности?а какая связь между моим комментарием и твоим вопросом :D
> Ты какие облака называешь нормальными? S3?
AWS:S3/GCP:cloud storage/gdrive/DO:Spaces, насчет dropbox и т.п. не в курсе.
Мой хипстометр сломался. Зачем они это делают??? Единственное логичное применение вижу только в больших кластерах, чтобы ненужное вытеснялось на более тормозные серваки. Но на десктопе-то это зачем?
Ну, например, у тебя маленький SSD и гигабитный канал к серверам хранения, тогда вполне оправдано.
Скорость HDD больше гигабитного канала. Для SSD нужно минимум 10 гигабит.
Для стирания границ между локальным, серверным и облачным хранением. Обычно это реализовывается путём создания папок, некоторые из которых локальные, а другие находятся где-то в сети. Данный механизм позволит ускорить работу с удалёнными файлами путём их копирования на локальный компьютер и наоборот, при недостатке места копировать файлы с локального диска на сервер или в облако. Это будущее...
> Это будущее...Нет, это наглухо забытое поколением пепси прошлое. Уже в третий раз за 40 лет этот велосипед изобретают.
>> Это будущее...
> Нет, это наглухо забытое поколением пепси прошлое. Уже в третий раз за
> 40 лет этот велосипед изобретают.но тогда мы эти хранилки располагали в своей серверной, а не в гуглевой-амазонской-бэксглазой.
А принцип тот же. Было быстрое хранилище и медленное, с файлы к которым редко идут обращения мигрировали на медленное хранилище, он деманд переезжали обратно. Стримак это или облако - не принципиально.
> А принцип тот же. Было быстрое хранилище и медленное, с файлы к
> которым редко идут обращения мигрировали на медленное хранилище, он деманд переезжали
> обратно. Стримак это или облако - не принципиально.ну, в принципе, да - правда, когда хвататель, в очередной раз промазав мимо кассеты, обламывал себе палец об полку (древние библиотеки были феерически атехнологичны), по гарантии ты отправлял только железку - кассеты продолжали лежать у тебя за надежно закрытой гермодверью.
А тут "будущее" - все ваши данные хранятся не у вас. Это вот принципиальная разница. А код тот же самый - ну еще раз на модном языке перепишут, подумаешь, пятый или десятый.
> все ваши данные хранятся не у васМожешь поднять облачный сервис у себя на домашнем файловом сервере.
У меня на рабочем ПК стоят бесшумные j5005 + SSD, а на домашнем файловом сервере 3 HDD-диска (зеркало + медиа). Сейчас я вручную гоняю файлы туда-сюда. Новое решение будет делать это автоматически по мере необходимости.
И для этого не нужно быть Рокфеллером или владеть усадьбой в центре Москвы, достаточно собрать файловый сервер из трёх шумных HDD в коробке из-под обуви и поставить её в шкаф подальше от спальни и комнаты, где у тебя компьютер, напр. в шкафу в прихожей. В качестве мат.платы подошла моя старая безвентиляторная Mini-ITX плата, благо что файловый сервер особой "прожорливостью" не отличается. Для эстетов (как я) - специализированные корпуса, напр. Lian Li PC-M25. Как вариант - half-depth half-width серверные корпуса, которые можно купить (очень сложно найти, хотя стандарт есть) или распечатать самому на 3D-принтере, оформив свои старые компы и RaspberryPi в элегантную серверную мини-стойку.
на домашнем файловом сервере я подниму банальную самбу на 10ge или вовсе rdma volume через infiniband - то и другое дешевле дисков и прочей требухи сервера, если за свитч не платить, ограничившись включениями порт-в-порт.И оно будет работать в разы быстрее даже локального ssd, потому что он один, а в хранилке их пять, поэтому гонять с нее файлы как таковые не придется. И да, для этого не надо быть рокфеллером.
эта же хрень придумана именно для хранения чего-то большего, чем уместно разместить дома-под-столом, но что не требует хороших скоростей доступа.
> А тут "будущее" - все ваши данные хранятся не у вас.Зато очень удобно. Вот смотри, бэкапался ты на амазон, бэкапался. Все было ЗБС и почти нахаляву. А тут тебе твой терабайт вдруг потребовался назад. А тебе и говорят: сантик^W двести баксов, чувак! Гостиница Экономическая - версия 2.0.
А раньше ты ToS не читал, конечно. Ну закономерно огреби. Кстати, амазоновские тарифные планы довольно просты.
Ну да. И в результате шанс их угробить от всяких стихийных бедствий включая местные власти довольно мал.А ещё - задолбали "или-или" выдумывать. Уж сколько раз твердили миру - один бэкап локальный, другой удалённый, и будет счастье. Если паранойя - шифруй.
> А ещё - задолбали "или-или" выдумывать. Уж сколько раз твердили миру -
> один бэкап локальный, другой удалённый, и будет счастье. Если паранойя - шифруй.В таком виде даже не бред, но сабж не про это, да и оголтелые впариватели очередной панацеи как-то забывают столь же оголтело верещать про локальные бэкапы. Так что уж простите но придется считать что они преследовали свои шкурные интересы. При том в этом случае - еще и довольно нагло, просто по головам. Они еще только "начали писать" - но уже наспамлено какой-то новостью ни о чем. Ну то-есть ребята обычные спамеры и продолжатели дела Билла Гейтса.
> но тогда мы эти хранилки располагали в своей серверной, а не в
> гуглевой-амазонской-бэксглазой.Ну вы то наверное догадывались что канал в интернет может и фигакнуться, а гугл может аккаунт все же и заблочить. Ну вот решит его автоматика что вы спамбот - и нифига вы ее не переубедите. И саппорт вам не поможет. Потому что там те же самые роботы и они уже решили что вы должны умереть. Вместе с вашими фоточками котят.
Для этого есть SLA - соглашение о качестве предоставляемых услуг, где написаны худшие варианты: максимально продолжительный простой без интернета не более 5 минут, максимальный суммарный простой в течении месяца не более 20 минут, минимальная скорость скачивания не менее 640 кбит/сек, и т.п.Google блочит только то, за что могут заблочить его. Поэтому постить Мстителей-4 на ютубчик нельзя. В своём платном и частном облаке можешь хранить сётакон и гуро - никто тебе слова не скажет.
> максимальный суммарный простой в течении месяца не более 20 минут, минимальная
> скорость скачивания не менее 640 кбит/сек, и т.п.А когда какой-то промежуточный роутер, не подконтрольный ни мегапрову, фирмочке с облаком вдруг на это положит с прибором, потому что его владелец вообще ничерта вам не обещал - мы узнаем что интернет работает немного не так как вещает ушлый маркетолог :)
> Google блочит только то, за что могут заблочить его.
Ага, щас. У гугла какая-то автоматическая система с чуть ли не AI. Железному интеллекту скучно и он иногда развлекается тем что банит юзеров по каким-то одному ему ведомым критериям. Которые не знает даже саппорт. Что следует дальше - несложно нагуглить в коментах довольных юзерей.
> Поэтому постить Мстителей-4 на ютубчик нельзя. В своём платном и частном облаке можешь
> хранить сётакон и гуро - никто тебе слова не скажет.Да понимаешь, гугл на моей памяти загасил несколько знакомых юзерей, которые мухи не обидят. И потом их саппорт... явно полагает что юзеров у гугла слишком много и что нагрузку на сервера надо снижать. Посылая этих неудачников в пешее эротическое путешествие. Вероятно саппорт гугля - просто пешки железного дровосека, тот лучше знает кому жить а кому умирать и переубедить его наверное не в власти саппортов. Большие автоматизированные системы с саппортом работают как-то так.
> Ага, щас. У гугла какая-то автоматическая система с чуть ли не AI.эта система на корпоративные акаунты, вообще-то, не распространяется.
Ну или по крайней мере - на старые корпоративные акаунты - гугль несколько раз менял TOS (старые могли его не принимать, ага).Но за денежку, кто не успел вскочить в халявный вагон еще в 2009м.
А, помните такую прогу от MS под DOS для увеличения размера дискеты - что-то типа Diskdrive или как там его. Данные частично копировались на HDD, а часть оставалась на дискете, но выглядело как будто бы все на дискете)
> А, помните такую прогу от MS под DOS для увеличения размера дискеты
> - что-то типа Diskdrive или как там его.drvspace? dblspace?
Помним. Скорбим^W.
> Данные частично копировались на HDD, а часть оставалась на дискете, но выглядело как будто бы все на дискете)Не частично, а вообще не копировались, т.к. это было прозрачное сжатие.
Это называлось "перетащить ярлыки на дискетку", ага. "Что бы диск не забивали!". Популярно было в win95, приходилось отучать
Чтобы твои данные были от тебя подальше, а к ним поближе. Такова логика всех этих услужливых сервисов. Да гляди ещё комп проапгрейдить придётся, чтобы тормозное питоноподелие на уровне файловой системы на нём как-то ворочаться могло.
Допустим, лежит у меня на харде размером 1 терабайт библиотека из epub, fb2, pdf и djvu общим размером гигов эдак на 250. Бывает и больше, кстати. Из этой библиотеки я регулярно держу под рукой единиц ~20 книг, из них ~10 новинки. Но терабайт всё же терабайт а не овердохуа и не резиновый. Соответственно то, что не требуется часто - архивы журналов, некоторые полные собрания сочинений и т.п. вполне можно "вытеснить" за приемлемую даже плату в надёжное облако, которое не пролюбит мою прелесссть, пока я с очередной зарплаты не обзаведусь еще одним толстым хардом для своего личного датабанка. Вот тебе один из множества возможных востребованных юзкейсов. Отнюдь не хипстерских.
> вполне можно "вытеснить" за приемлемую даже плату в надёжное облако, котороетут вопрос, насколько оно "надежное" за эти деньги.
> не пролюбит мою прелесссть, пока я с очередной зарплаты не обзаведусь
> еще одним толстым хардом для своего личного датабанка. Вот тебе одина, ну или так.
> из множества возможных востребованных юзкейсов. Отнюдь не хипстерских.
ну фиг знает - с терабайтом книжек я и вручную управлюсь (да и нету там терабайта)
такая автоматика нужна, когда данные и потребляет какой-нибудь автомат (или свора юзеров, которые непредсказуемей автоматики), и там терабайтов будет не один и не два, иначе все эти сложности дешевле решить таки диском.
А кто помнит, у бэкблейзов одна цена и на b2, и на архивный сторадж?
>насколько оно "надежное" за эти деньгиОценить можно - какое оборудование, какая квалификация сотрудников, какое ПО стоит (а вот тут как раз преимущества open source здорового человека проявляются во всей мощи).
>у бэкблейзов
По-моему да, одна и та же - пятьдесят зеленых за год на один комп просили.
50 баксов - это бэкап, там оно само шуршит (на твоём компе!), рещает, что бэкапить и особо не контролиуется, зато - безлимит.А архив, он же b2 (они не разделяют) - по объёму (сколько-то там за гиг в месяц) плюс за закачку от них - опять же за гиг, зато - всё, что ты хочешь, без магии и тупо через API (в том числе умеют амазоновский).
>у бэкблейзовКстати, а чего б не крэшплан?
А крэшплан вообще умел быть "просто хранилищем", а не бэкапилкой, шарящейся по твоим дискам? А сейчас вроде вообще только для бизнеса что-то предлагают
Да я давно не смотрел на то, чем крэшплан стал, помню только, был такой. Так-то в качестве вкусного по деньгам решения как раз в сторону бэкблейза и посматриваем. И уже в этом квартале, скорее всего, перестанем только лишь присматриваться.
Например, фотоархив - одна копия в этой штуке, вторая - оффлайн, как и положено.
Интересно, но для использования нужно еще encfs навесить: пишут, что backblaze поддерживает шифрование, но данные расшифровываются на стороне сервера, т. е. оно там бесполезное, для галочки (https://en.wikipedia.org/wiki/Backblaze).
У backblaze такие низкие цены как раз за счет механизма дедупликации: вычисляются контрольные суммы а-ля rsync, и одинаковый блок хранится только один раз (ну, ок, три раза), а при запросе на получение бэкапа файлы реконструируются из набора контрольных сумм блоков.Так что шифрование там по определению невозможно.
borgbackup умеет одновременно и шифровать, и сжимать, и дедуплицировать.
Предлагаете для всех пользователей backblaze шифровать одним и тем же ключом? Ооок:)
> Предлагаете для всех пользователей backblaze шифровать одним и тем же ключом? Ооок:)Почему? Шифруем данные на клиенте, у каждого клиента свой ключ. На сервер загружаем зашифрованные данные + хэш незашифрованных (с солью, общей для всех клиентов). На основе хэша вычисляем дубликаты.
Да? А что делать при коллизии хэшей? Приехали?
> Да? А что делать при коллизии хэшей? Приехали?Я не знаю, как эту проблему решили в borgbackup. Найдёшь - отпишись.
никак. авторы всех технологий дедапа верят, что коллизия хэшей невозможна.
Мысль о том, что по сути они заменяют блоки данных, предположим, в 128k, строкой в 256 бит - причем ВСЕ блоки неизвестного содержимого - ограниченным количеством строк (в зависимости от типа хэша может оказаться, что далеко не каждая строка - валидный хэщ чего бы то ни было) им, по-моему, в головы вообще не приходит, там некуда, там карри. Единственное исключение - zfs, там сановские инженеры еще головами думали, а не только ели - там есть verify, если не хочется проверять свое везение (разумеется, снижает скорость, но часто этим можно пожертвовать)то есть по сути, да, на наших глазах переизобретается архиватор del, только уже в глобальном масштабе.
оно бы и работало, даже, в масштабах локалхостов, даже достаточно больших - но в масштабах амазона или бэкблейза вопрос коллизии - только вопрос времени.
Окей, мы знаем, что у пользователей U1 и U2 зашифрованные блоки B1 и B2 имеют одинаковый sha512. Как теперь хранить только один из этих блоков?
> Окей, мы знаем, что у пользователей U1 и U2 зашифрованные блоки B1
> и B2 имеют одинаковый sha512. Как теперь хранить только один из
> этих блоков?зачем?
Если ты каким-то чудом (например, нанятый вменяемый разработчик понимал, для чего на самом деле существуют криптографические хэши - чудо!) вовремя об этом узнал - просто сохраняешь второй блок отдельно от первого. Ровно так же, как в случае, если бы эти sha оказались разными (точнее "поиск хэша B2 ничего не нашел").На момент, когда ты считал его хэш, он у тебя еще был, есть что сохранять.
внутри файла-то они не по хэшам ищутся, а банально по ссылке.
zfs dedup+verify примерно так и работает
Что даёт присутствие таких функций (вытеснение на облако и т.д.) на уровне ФС, а не утилит каких-нибудь?
чтоб утилиты пользовать это нужно что-то там в консоли писать и вообще мозгом думать. а тут все за тебя сделают.
щас так модно типа.
> что-то там в консоли писать и вообще мозгом думатьТак-то ковыряние в консольке нагружает мозг не больше, чем работа автомеханика в гараже.
Но и автомеханик в гараже Должен работать и головой, и руками. Конечно при условии что это нормальный гараж где действительно ремонтируют, а не стремятся "обуть" на лишнюю десятку, зачастую доламывая то, что можно было сделать с с гораздо меньшими затратами.
Хорош ли тот автомеханик по вине которого в машну вложено более 200 к рублей. Заменена половина подкапотной, а усилитель руля(проблема с которой обратились)так и не отремонтирован? И что самое интересное проблема была в предохранителе за 50 рублей!
збс чо...
P.S. Осторожнее в сравнениях...
Я не спорю, что автомеханик работает головой. Но там, как правило, действия по набору шаблонов. Просто ручное дрочево в консоли так превозносят, будто это чуть ли не написание книг или научных работ. Ничего особенно интеллектуального и почётного в ручной работе с софтом нет, в отличие от создания автоматизированных систем, на которые любители конcолинга и гонят постоянно XDD
Собственно по изначальной задумке консоль в *никсах это инструмент автоматизации, а не драчива. Ну то-есть накорябал на шелле скрипт по ситуации, и отправил его впахивать. А самому 100 раз вклацывать одну и ту же операцию для 100 машин где-то там - как бы и не надо. А то что некоторые возвели клап в консоли в ритуал - тупицы есть и в *nix'ах. Там тупицей быть сложнее, но у некоторых получается.
> Ты дважды ошибся за такой короткий коммент, кекМожет это он про себя? :)
>что-то там в консоли писать и вообще мозгом думатьАга, а глину для кирпичей ты тоже сам должен месить, железо для арматуры лично выплавлять, деревья рубить и распиливать на доски для пола тоже сам - а то щас модно типа квартиру покупать готовую.
И статистику тоже отдельно собирать и потом анализировать. То есть возни больше, а вот плюсов лично я не вижу. Ещё хинты какие-то - понятно, но зачем полностью закат солнца вручную делать?
я, конечно, понимаю что atime сейчас немодно и немолодежно, но "анализатор статистики" там, где его еще не добороли до полного факапа - find ... -atime +48
или ты думаешь, у пихоноподелия там космическая наука и искусственный интеллект? Вря-ааад ли...вот затолкать файл в чанки b2шного хранилища - это да, это победа добра над разумом. А тут... я тебе такое на слегка модифицированном dav напишу, пожалуй, за пару часов.
Интересно, что там по задумке авторов должна показать какая-нибудь df в плане кол-ва свободных блоков в ФС? Напишет, что свободного пространства хоть опой жри ( локальное свободное +(какая-нибудь облачная квота - занятое в облаке место) )?
напишет -1 и свалится по segfault.
у современных разработчиков оно примерно так обычно.> Напишет, что свободного пространства хоть опой жри ( локальное свободное +(какая-нибудь облачная
> квота - занятое в облаке место) )?ну да, конечно, мы же будем за тебя переписывать df (написанный на омерзительном C, даже без плюсов), делать нам больше нечего.
> напишет -1NaN сейчас модно
>> напишет -1
> NaN сейчас моднокстати, да (в gnu df floating арифметика вполне себе есть ;-)
> ну да, конечно, мы же будем за тебя переписывать df (написанный на омерзительном C, даже без плюсов), делать нам больше нечего."( локальное свободное +(какая-нибудь облачная квота - занятое в облаке место) )" - вроде очевидно, что это формула для подсчета свободного пространства, одна подсчитанная цифра (как для всех ФС), а не "легенда/расшифровка" в утилите для вывода на экран уникальной "Zero-информации".
И за меня переписывать df не надо, потому что я и сам, тоже, не собираюсь ее переписывать. Но Вы меня пугаете. Вы полагаете, что "( локальное свободное +(какая-нибудь облачная квота - занятое в облаке место) )" должна высчитывать df? Не получить откуда-то посчитанное и отобразить одной цифрой, а именно вычислить? Я, конечно, ни в зуб ногой, как там внутри устроена эта df, но вот Вы, похоже, разбираетесь - неужели для каждой новой ФС требуется переписывать df? Она что, самостоятельно на низком уровне (минуя драйвера файловой системы) разбирает on-disk-формат каждой новой ФС, что ее требуется переписывать? Не использует инфу, выложенную самими файловыми системами в унифицированном виде куда-нибудь в /proc/... или какие-то прослойки-абстракции уровня ядра типа VFS или что-то подобное? К каждой ФС у df уникальный подход? Вот это поворот.
> Не получить откуда-то посчитанное и отобразить одной цифрой, а именно вычислить?ну, в конечном счете, оно опирается на stat(), но там ни разу не предусмотрено сложных формул рассчета непойми чего, а вот полнота апи (поскольку оно прежде чем непосредственно спросить "сколько места", долго лазит по дереву, пытаясь угадать где там точка монтирования и кого на самом деле надо опрашивать) очень даже требуется.
поэтому в лучшем случае удастся вернуть какую-нибудь бессмысленную цифирь (вполне очевидно, что для данной задачи она ненужная и вредная, а на самом деле нужны раздельные данные по месту на локальном диске и месту в облаке) а в худшем запутается в этих stat и упадет. Ну или не успеет, ноль или -1 вернет, не успев на этот ноль ничего поделить. Но это должно повезти ;-)
В рамках этой задачи как раз раздельнцы значения - это полная чушь. Потому что весь поинт в автоматическом менеджменте. Так что по идее - локальная квота, выставляемая где-то в конфиге это ФС плюс квота в облаке (которую она либо время от времени спрашивает, либо из того же конфига) минус занятое (уже посчитанное на ходу) - самое то.
в смысле, тебе совсем неинтересно знать, ни сколько занято локально, ни сколько вытеснилось (и ты заплатишь денежек за попытку к этому обратиться, если не в курсе бизнес-модели b2), ни насколько удачно у тебя выбралось соотношение локального к облачному и не стоит ли увеличить вдвое локальное пространство, чтобы не платить вдвое больше за те же терабайты ?
Ну так зачем тебе тогда вообще df, облако же ж бездонное. NaN покажет, подумаешь.на самом деле тут нужна своя утилита, которая собирала бы гораздо более продвинутую статистику, никак в рамки обычного df не лезущую.
самбоводов вот ничто не остановило написать собственный cifsiostat, поскольку очевидно, что любоваться счетчиками на интерфейсе, непонятно к чему относящимися, довольно бесполезно, а обычный iostat работает слишком на низком уровне и с самбой помочь ничем не может - а информацию эту контролировать уметь нужно.
Йопт, я такое же за бабло писал, только вместо облака там была оптическая архивная хранилка. Если переписать на C, то +- 700MB/s на потоковую запись получить можно (на харды). Про SSD хз.
Так это ты тот чувак из bell labs, писавший plan9?
Нет.
Судя по названию их цель вытеснить всё, оставив локально только zero.
Только если будет поддерживать хранение на собственном подконтрольном сервере, тогда нужно.
Ответ ненавистникам Питона.PS Вовсе не утверждаю, что Python быстрый, но востребованный даже в системном ПО.
Вам ненавистники Питона скажут, что если Питон можно запихать в файловую систему, это не значит, что так _нужно_ делать.
И что характерно, будут правы.
вообще FUSE - от слова userspace, не такое оно уж и системное
> PS Вовсе не утверждаю, что Python быстрый, но востребованный даже в системном ПО.Востребован, на уровне зонтиков рыбками.
Востребован фриками для извращений? Так еще рекомендация.
Офигенно, мне как раз такое нужно. Думаю на одном сервере обработку гонять, на другом хранить. Думал davfs монтировать с кэшем, но на уровне ФС, по идее, надёжнее должно быть. А есть более готовые аналоги?
есть, samba, nfs, тыщи их. rsync еще есть.Кстати, учти что davfs2 over fuse - похоже, синглтредовая, и тормозит хз как, попутно вешая все в системе, что имеет несчастьте просто проходить мимо (например, просто перебирает точки монтирования)
то есть на более-менее серьезную нагрузку ни разу не рассчитана. Впрочем, протокол на это тоже не рассчитан.
> как, попутно вешая все в системе, что имеет несчастьте просто проходить
> мимо (например, просто перебирает точки монтирования)Если у тебя от активности одной программы клинятся другие - поздравления, операционка облажалась с шедулингом ресурсов.
- Пап, а правда что винда 95 многозадачная?
- Да, сына, подожди, сейчас дискетка доформатируется и я покажу тебе что такое многозадачность.
я ценю остроумие, но читать тоже надо уметь:> попутно вешая всё в системе, что имеет несчастьте просто проходить мимо
Или считаешь, что твой шутливый комментарий адекватен цитируемой фразе?
там надо уметь не читать, а понимать прочитанное, это два разных умения.
Короче, ничо вы не поняли. Кураторы из АНБ накрутили хвост менеджменту Бэкблэйза за то, что те мало данных у лошков собрали. Те нашли питонокодера, который за еду склепал им прототип "инновационной" файловой системы.
да ну, у них же архивы были?А тут в b2шную часть бэкблейза (она изначально под свалку всякого json мусора планировалась, выхлоп всяких bigdata и прочего, то есть это не файлы) поедут те же архивы, причем не все, а самые ненужные их части.
Ну и зачем бы это АНБ?
Скорее, действительно, автор пользовался бэкблейзой, захотел дав, дава там нет, зато есть хранение блобов мелкой россыпью - ну и сделал, как умел. И выкинул в опенсорс, авось помогут дописать. Без претензий на мировое господство и что оно вообще кому-то еще нужно.
> Ну и зачем бы это АНБА хз что и как они там анализируют. Ненужные файлы, которые не удалены, а позабыты-позаброшены. То же самое, что на антресолях или в гаражном хламе покопаться.
> захотел дав, дава там нетНу да, написать ФС проще, чем в самом начале сесть и перебрать десяток-другой хостеров. Хотя, если начальство рассуждает по принципу "чего ты там возишься, зарегать аккаунт на хостере - дело одной минуты", то запросто можно поиметь отдалённые проблемы, которые потом придётся решать написанием новой ФС.
> Ну да, написать ФС проще, чем в самом начале сесть и перебрать десяток-другой хостеров.ну если хотелось надежный, то их всего с пол-десятка, и ценник в 3-30 раз выше, то есть профит вполне понятен.
а если эта хрень до того еще и использовалась у тебя по прямому назначению, а не надо изучать api с нуля и писать к нему пихоновые binding'и вручную - то остается взять для примера какую-нибудь плохую fuse-либу, и переделать под свои хотелки.
просто кто-то такое доделав, молча вывалит на гитхаб, если не спрячет в стол, а кто-то, вишь "йа изобрел новую fs zero, на новом уникальном нанопринципе вытеснения!"
Заказная фигня наверное, идея конечно хорошая, но в цены на хранилище... Или если только личное создавать, возможно, но всё равно не заменит бэкапов, поэтому в теории хорошо на практике необходимость довольно спорная если не сказать ненужная))
Личное проще на Ceph с локальным кэшем нагородить.
Нужна поддержка s3, чтобы можно было на свой ceph натравить.
LeoFS?
я такое уже давно пльзую на телефоне, телефон синхронизируется с ПК, а на ПК фотки и видео после опредиленной даты сортируются по размеру, им назначаетс рейтинг, чем старше дата и больше файл тем больше вероятность что он уедет в облако на архивацию. Дальше при следующей синхронизации с ПК файл удалится на телефоне.
вот бы сделать обратный bcache для SSD+HDD
чтобы актуальные файлы жили на SSD (250GB) а неактуальные автоматом уезжали на медленный но ёмкий HDD(8TB).сяду сам на досуге напишу... если не забуду.
собственно, да iZEN тебе уже ответил - уже все написали до тебя, zfs arc2 называется.Причем работает он не с файлами, а с блоками, что более правильно - если там лежит, к примеру, архив из которого часто нужна только небольшая часть, или вовсе образ vm.
устроено внутри, кстати, весьма и весьма непросто, на коленке такое не выпилить.
дополнительный бонус - когда таки допилит твой ssd до дыры, есть неплохие шансы что ничего специально лечить не придется, а просто можно будет его выкинуть.
dm-cache / bcache / flashcache (имени фейсбука) - да вагон на чем сделать можно.
есть еще к слову fs-cache который к NFS прикручивается (да и можно к остальному) запись будет напрямую на диск - а r/o cache локальный.
bcache так и работает - не нужные блоки уезжают на hdd, а нужные живут на ssd.
размер складывается? Или на hdd всегда есть все данные?
В случае bcache HDD хранит все данные, а частоиспользуемые блоки зеркалируются на SSD.
имхо все блоки уезжают на HDD, на SSD продублированы частозапрашиваемые.
В этом принцыпиальное отличие от того, чтобы на ХДД уезжало только неиспользуемое.
Из ZFS тоже такое можно сделать: в облаках размещаем блочные устройства физического уровня, объединяем их в raidz3, а у себя на компе для этого пула используем кэш L2ARC на SSD. Данные пишутся непосредственно в облако и гарантированно сохраняются с избытоным кодированием и целостностью, а кэш работает исключительно на чтение часто запрашиваемых данных.
Вот разве что для этого ZFS и нужна. Оно реально будет работать? Или очень привередлива к качеству каналов? Скажем, если канал в облако - 20 МБит/c, а средняя нагрузка за час - 1МБит/c, не будет ли оно неюзабельно? Если что, я сейчас не о сабже, а о технической возможности сделать такое на базе ZFS
mbuffer + UDPspeeder
Я ниасилил или никто так и не предложил достойной альтернативы и вообще камменты как обычно не по "чистапаржать"?
ФС на гибриде питона с фюзой никаких ассоциаций, кроме как "чистапаржать", не вызывает.
А аналоги какие-нибудь есть на чем угодно?
Идея мне очень нравится.
Сейчас приходится реализовывать вручную. Хотелось бы автоматизации. Лучше между точками монтирования, но не блочными устройствами, как предлагают выше.Т.к. с блочными проблем побольше....
А так есть:
фс на быстром диске - там актуальные данные
фс на медленном диске/кластере/облаке - там много место и надежноПользователю нужно прозрачно, по возможности работать быстро. Как такое сделать?
> А аналоги какие-нибудь есть на чем угодно?наша zfs с arc2
> Сейчас приходится реализовывать вручную. Хотелось бы автоматизации. Лучше между точками
> монтирования, но не блочными устройствами, как предлагают выше.нет, такой фигней мы не страдаем
> Т.к. с блочными проблем побольше....у нас как-то не замечено.
> А так есть:
> фс на быстром диске - там актуальные данные
> фс на медленном диске/кластере/облаке - там много место и надежноименно так и есть, только без "облачков" (san сойдет тебе за "кластер"?)
для пользователя все прозрачно и быстро, для админа - zpool add...
Кто такая ZFS я вроде знаю. С ее плюсами и минусами. Не подходит. Она используется сейчас как шустрое/рабочее хранилище.>именно так и есть, только без "облачков" (san сойдет тебе за "кластер"?)
Не сойдет - сложности с изменением размеров/надежностью и т.д.. :-(
Сейчас используется MooseFS под архив и бэкап. Позволяет динамически менять размер и надежность хранения в любую сторону.По идее, хотелось бы верхним слоем, с которым оперативно работают - ZFS. А нижним MooseFs - под длительное хранение.
Только требуется автоматизацию телепортации. :-)
Backblaze рекламу неприкрытую в новости этой вижу я.А по теме - да, отличная тема, можно будет автоматически вытеснять архив куда-нибудь товарищу майору сразу.
>> во внешнее облачное хранилище.- Вот как теперь /dev/null называют.