Comments 19
Вопрос, что им мешало оптимизировать в клауде, где пользователь даже и не узнал бы, что они хранят одну копию. Или даже локально, но чтобы системный API воспринимал файлы нормально.
Иначе есть опасение, что перестанут работать приложения, которые предполагают зависимости между хранимыми файлами. Например, html странички с картинками, css и т.п.
Опять таки, если файлы автоматически заменены на ярлыки, а ты копируешь папку на флэшку, а потом там оказываются ярлыки.
Справа "Диск Цэ" и слева "Диск Цэ".
Я подумал, "а зачем мне ДВА диска Цэ", ну и удалил один из них.
А что будет, если я буду редактировать файл в одной папке, исходя из того что у меня в другой папке есть резервная копия?
Будет автоматически создана "физическая" копия изменённого файла и он из общего ярлыка станет индивидуальным файлом или же изменения будут глобальными и затронут все варианты отображения данного файла?
А история правок как будет храниться?
Нет. Будет новый файл. Логично же.
А вообще статья про "о божечки они подключили hard link к своему облаку". Не рекламы ради, но то же Облако Маил.ру, уже давно перед загрузкой файла считает его хеш и если такой хеш уже есть в облаке, то файл "моментально создаётся"(ну конечно же создаётся hard link).
А вообще статья про "о божечки они подключили hard link к своему облаку".
Только не совсем hard link, а дедупликацию. Вот только не понимаю, что мешало им ее включить на блочном уровне сразу и без громких анонсов про ярлыки?
Думаю, что отсутствие у облака хранения непосредственно на блочном устройстве с дедупликацией. Ведь на блочном уровне хранит каждый из десятков тысяч узлов и попытка дедуплицировать на этом уровне должна породить ужасающий оверхэд при записи.
Ведь на блочном уровне хранит каждый из десятков тысяч узлов и попытка дедуплицировать на этом уровне должна породить ужасающий оверхэд при записи.
Не до конца понял вашу мысль.
Каждый узел имеют свою дедупликацию. При синхронизации данных с другим узлом самый простой и надежный вариант, когда мы синхронизируем данные на файловом уровне и дедупликация производится на получающей стороне.
Я говорил о том, что дедупликация на блочном уровне на каждом конкретном узле поможет слабо. Просто прикиньте вероятность того, что одинаковые файлы двух клиентов случайно попадут на одну ноду. А синхронизировать хэши между десятком тысяч нод, ну не знаю. На самой ноде, скорее, полезно потоковое сжатие, но не слишком агрессивное.
А вот дедупликация на уровне распределённой ФС уже может работать очень хорошо. Но тут нетривиальности добавляет отказоустойчивость. И она уже не на блочном уровне получается.
P.S. перечитал источник. Возможно, я не прав и файлы одного пользователя/группы стремятся быть на одной ноде. Тогда именно блочная дедупликация становится чуть более уместной.
Я говорил о том, что дедупликация на блочном уровне на каждом конкретном узле поможет слабо. Просто прикиньте вероятность того, что одинаковые файлы двух клиентов случайно попадут на одну ноду.
Именно на блочном уровне нам не нужны одинаковые файлы, нам достаточно иметь одинаковые последовательности в них (идентичные блоки). Поэтому на блочном уровне дедупликация значительно эффективнее, чем на файловом, но более ресурсоемка. Грубо говоря обычный документ Word имеет массу одинаковых блоков (стандартные стили и формы и форматы) при абсолютно разном текстовом содержании, поэтому данные документы всех пользователей именно на блочном уровне будет прекрасно дедуплицироваться.
Надо как-нибудь попробовать. Особенно с word-овскими файлами, которые, с некоторых пор zip-архив.
Я очень хорошо вижу, как блочная дедупликация может работать с загрузочными LUN'ами, например. Или образами виртуальных машин для VDI. Но вот с пользовательскими файлами. Наверное, мне пользователи подходящие не попадаются...
Особенно с word-овскими файлами, которые, с некоторых пор zip-архив.
А какая разница? Одинаковые блоки внутри архива не могут встречаться? Вы точно правильно понимаете термин "блочная"? Например на Symbols storage одинаковых файлов нет - все символы уникальные. А вот одинаковых блоков в этих файлах - множество, поэтому деудплицируются они просто отлично.
Наверное, мне пользователи подходящие не попадаются...
У меня дедупликация пользовательских файлов в среднем 15-30%. На дисках с билдами или символами это значение 50%+. И даже диск с рабочими данными видяшников, дает 15%, ЧЯДНТ?
Нет. Будет новый файл. Логично же.
А из чего, простите, следует данная логика? Из статьи только известно, что одинаковые файлы будут сокращены до, как уже тут сказали, хардлинков. А если это так, то поведение введённых хардлинков будет совсем не такое, как по вами приведённой логике. И остался открытым главный вопрос: как теперь создавать намеренные копии файлов?
А история правок как будет храниться?
Если все сделано по уму, то "реальный" файл вообще не в "папке". А в папке один и папке два хранится условный линк на файл + дельта изменений. Поэтому при правке файла в папке 1 изменяется только значение дельты.
Т.е., у безразмерных(*) облаков стало внезапно кончаться место?
(*) По заверению менджеров по продажам.
IT-гигант отметил, что в результате перехода на удаленный формат работы юзеры начали чаще полагаться на облачные сервисы хранения данных и совместной работы. В итоге это привело к увеличению количества файлов, что вызывает проблемы с упорядочиванием и навигацией в рабочих пространствах.
И вообще, зачем IT-гиганту порядок в личной папке пользователя? Ведь пользователь платит за выделенное ему место. Тот, по мнению IT-гиганта, хаос в папке пользователя может быть результатом напряжённой работы этого самого пользователя и к которому этот пользователь стремится.
Т.е., напрашивается только один логичный вывод из новости: IT-гиганту очень хочется анализировать файлы пользователя, но не может по причине неструктурированного бардака, который эти самые пользователи устроили в своих папках.
Внезапно пришло осознание, что облачное хранилище это как отель: ты можешь жить в комнате со своими личными вещами, пока ты платишь за номер, но раз в какой-то период времени в твой номер будет нагло вторгаться горничная/уборщица чтобы привести номер в какой-то установленный отелем правилами порядок. Неприкосновенность твоих личных вещей при этом сильно под вопросом.
Или папка проекта со "снапшотом" того, что было отправлено заказчику, в ридонли режиме, в отличие от основной папки проекта, которая и дальше может правиться. Адекватный контроль версий в случае автокада, например, денег стоит, да и громоздкий, для маленькой проектной конторы с основными проектировщиками пред и постпенсионных возрастов - не вариант.
Иногда хранение копий файлов - наиболее удобный способ организации рабочего пространства. Правда, наверное, не в кейсах гугл драйва
Хочу такую же фичу, но только для локальных дисков. hard / sym - линки вручную неудобно создавать
Обновление Google Drive: дубликаты файлов, хранящиеся в разных местах, будут заменены на ярлыки