Разных файлов может и больше, но их суммарный объём скорее меньше, потому что уникальные файлы у пользователей это как правило личные фотки и документы, может ещё домашнее видео с выпускных да свадеб. А вот фильмы, сериалы, торренты у всех одинаковые и весят они в разы больше чем фотки с документиками..
Попробуйте дописать файл в конце не меняя начало. Если поменялось начало (добавилось или убавилось), вероятней всего сменились границы сегментов и как следствие все последующие хэши.
У меня ПО яндекса на вот этой штуке вертится AS7008T-3FBD там HDD диски в массиве, но в массиве они выдают до 350mb/s, но при работе с ПО диска, там CPU слабое звено при расчёте хэшей. Но в любом случае далеко не 1mb/s как тут ноют..
Ну не придирайтесь к словам, я знаю что копируется только мета информация в виде записи в бд. И что такое Copy-On-Write тоже знаю. Но не забывайте что большинство пользователей, всётаки пользователи, а не айтишники, для них понятным языком и пишу "копирует"..
Я тоже с вами не во всём соглашусь, да вы верно пишите, что файлы что есть у других не грузятся по факту (см. мой ответ на другое сообщение ниже), но я не соглашусь с этим: 1) >> ....... пространству нескольким юзерам. Что не есть хорошо. << А что простите в этом плохого? Зачем сохранять одни и те же данные много раз? Есть блоки данных, с байтами самой информации. Есть мета-данные, которые представляют из себя объект "файл" на диске пользователя. Мета данные можно разместить хоть у тысячи пользователей, и у всех у них будет тот же файл. Никаких рисков потери данных тут нет. При этом занимать он будет место на физических носителях всего 1 раз. К слову, это не ново, такой подход используется давно и очень много где. Например, у меня на NAS файловая система btrfs, она тоже использует такую технологию. Я могу 100500 раз скопировать какой нибудь фильм размером 20gb в кучу раных папок, или просто с разными именами. При этом размер свободного пространства на NAS не уменьшится. А если потом посчитать общий размер всех файлов в хранилище, он может превышать его физический объём. Это даже в какой то степени удобно, лично для меня.
2) >>Больше 42 МБ разогнать не удавалось<< Это лишь подтверждает то что я писал вчера ещё. Да, не удалось, потому что вы упёрлись в CPU. Когда файл есть у других в точности какой и у вас, процесс выглядит иначе, клиент бьёт файл на сегменты, вычисляет hash, далее он получает от YD ответ что все куски есть и создаёт метаданные о файле уже на вашем диске. И скорость загрузки (в данном случае по факту никакой реальной загрузки данных нету) состоит из того, как быстро он вычислит hash у вас в локальной системе, потому что после этого он просто ставит флажок что сегмент загружен. И получается по времени: начали обработку сегмента -> вычислили hash -> сделали запрос на YD и сразу моментально получили ответ что сегмент есть -> сегмент успешно "загружен" Т.е. скорость = объём сегмента / время И в виду отсутствия самой загрузки получается что скорость упирается в скорость рассчёта hash на вашем CPU.
3) на счёт того что он бьёт файлы на сегменты, это инфа тоже 100500% как минимум для linux клиента. Во первых, у яндекс клиента очень подробные логи, можете сами посмотреть Yandex.Disk/.sync/core.log Там всё очень отчётливо прослеживается, как он бьёт файлы на сегменты, как он вычисляет hash от каждого кусочка, как потом он в 8 потоков эти кусочки грузит на YD и пишет отчёт по каждому отдельному сегменту. Во вторых, это видно ещё и в htop, даже если не копаться в логах. Если резко ему подсунуть ОДИН большой файл, например 10gb, будет видно как 8 разных процессов грузят CPU. Если бы не было сегментирования, был бы один процесс который грузит одно ядро cpu, который вычислял бы hash от всего файла целиком. Но это не так. И в последствии, когда hash вычислены, у вас будет 8 процессов которые параллельно грузят сеть. Проверьте, сами увидите. Так что вопрос сегментирования это тоже инфа 100%
З.Ы. под сегментированием, может вы меня не так поняли, но физического разбиения файла на куски нету, я не зря писал "(виртуально)". Просто смотрите, скажем файл 8gb. Разбить файл на 8 кусков виртуально, это не значит сделать 8 маленьких файлов, это значит что создать 8 параллельных процессов, каждый из которых будет работать с этим одним файлом, но будет ограниченно читать из него данные, например первый процесс читает с файла данные с 0 по 1gb, второй процесс открывает этот же файл но читает данные начиная с 1gb от начала файла, и до 2gb от начала файла, и т.д. И каждый процесс со своими данными вычисляет хэш, загружает или и делает прочие операции параллельно и независимо от остальных.
Это всё верно, всё так, он не грузит файлы что есть у других пользователей, это я тоже заметил, когда 300gb загрузились практически за полчаса, при этом загрузка CPU была 100% а загрузка сети не поднималась выше 10% от ширины моего канала. Но это не отменяет того что я писал выше. Я на диск выгрузил 600gb данных, 300gb из них это папка с торрентами (фильмы, сериалы, коллекция музыки). Но кроме них, у меня там ещё 300gb бекапов. Этих данных, я могу с 100500% уверенностью сказать нет не у кого. Потому что я бекапы важных данных перед выгрузкой на YD прогоняю через утилиту aescrypt (я паранойик), она шифрует архивы моим персональным ключом, таких данных не может быть не у кого. И эти данные грузятся так же быстро.
На самом деле покопав глубже, я всё понял. Проблема не в том как он отличает, а в том как работает клиент. В общем суть, яндекс апи, это "Extended WebDAV". И "расширенный" тут ключевое слово. Если у разработчика альтернативного клиента руки не оттуда, или ему лень разбираться в "Extended WebDAV", то да, резаться будет всё. Короче, как работает нормальный клиент, это может быть и альтернативный в том числе: 1) бьёт большой файл на сегменты (виртуально) 2) вычисляет от каждого сегмента его hash 3) делает запрос на апи яндекса, подсовывая список hash этих сегментов 4) получает ответ от яндекса, каких сегменты у него уже есть, а каких нет 5) грузит только те сегменты файла которых у YD нету (по их id полученные от яндекса в п.4). —— Если не выполнять эти условия, скорость будет резаться.
Как работает "недо-клиенты", в том числе тот "curl" пример из первого поста: 1) пытается пропихнуть весь файл целиком без сегментирования и вычисления хэшей. 2) яндекс видит отсутствие хэшей и что ему пытаются пропихнуть огромный файл целиком, как итог яндекс такие клиенты режет.
И это вполне ОПРАВДАНО!
Поясню почему: Представьте, у вас есть большой файл, скажем 20gb, который вы загрузили на диск. Вы изменили в нём пару байт (а может и просто дату создания файла) ваш клиент видит что файл изменился и шлёт весь файл на диск. Скорость вашего канала 200 мегабит. И таких как вы ещё 1000 человек по все РФ, которые поставили себе эти "недо-клиенты". Что случится с каналом связи яндекс цода? Ляжет он. Потому что 200 гигабит канал нужен будет, нет таких каналов. До кучи, вы все, все 1000 человек, загрузите на YD 20 TB данных, ПРИ ТОМ что у файлов изменилось пару байт из 20TB (со всех в сумме), или вовсе могла просто дата поменяться.
Короче, для себя лично я решил проблему просто и быстро, я создал для своего NAS docker образ с yandex disk официальным клиентом. И смонтировал в него нужный мне каталог. Далее я создал ещё один docker образ, которому отключил сеть и дал лоступ к корневой системе в NAS, напихал всяких кронов, которые архивируют нужные мне папки и сервисы со всего NAS в тот каталог который доступен первому докер образу с яндексом. Итог, файлы выгружаются на яндекс диск на скорости 20 мегабайт в секунду (200 мегабит), это предел моего интернет канала.
В общем, у меня тоже возникла необходимость делать бекапы, а в текущей ситуации в мире все иностранные подобные сервисы я сразу отмёл, а отечественных выбор не так велик. Короче наткнулся я на это сообщение и засомневался. Но провёл свои собственные тесты, и в итоге купил себе подписку на год. Что хочу сказать, первое, читайте внимательно ответ от техподдержки яндекса. Они вам не соврали, но читайте внимательно! Ответ шаблонный, но составлен грамотными юристами, я в этом ответе увидел следующие: 1) яндекс гарантирует что скорость работы с диском не будет ограничиваться с их стороны при использовании ОФИЦИАЛЬНОГО клиентского ПО от яндекса. 2) Яндекс НЕ гарантирует что скорость работы с диском не будет ограничиваться при использовании альтернативного ПО из других источников. И прямо намекают что они оставляют за собой право это делать. (что и сделали) —— Собственно всё ——
По факту, после прочтения я провёл свои собственные тесты, которые подтвердили все вышесказанные подозрения, моя скорость интернета 200 мегабит. При загрузке файлов на яндекс диск и с яндекс диска, с использованием их официального ПО скорость была ограничена лишь моим каналом интернета. При использовании альтернативного не официального клиентского ПО, скорость загрузки с яндекс диска на локальный диск была НЕ ограничена, при загрузки с локального диска на яндекс диск да, был 1 мегабит. Скрины прилагаю ниже (первые два выгрузка на яндекс диск через официальное ПО, последний загрузка с яндекс диска на локальный через альтернативное ПО NAS для внешней синхронизации).
То что загрузка на яндекс при использовании стороннего ПО ограничена, это конечно не приятно, но лично для меня не критично. В моём случае, ситуация следующая, у меня есть сетевое хранилище, на котором я храню всё важное. Было бы конечно хорошо, если бы ПО на сетевом хранилище само синхронизировалось с яндексом, но, файлов у меня много и они большие. Нет, это не видео с фотками :) Это архивы с проектами, пофайлово копировать в реальном времени для меня не вариант, там файлов миллиарды, по этому я настроил задание по расписанию, которое архивирует проекты по папкам и до кучи прогоняет архивы через AES шифровалку, перед загрузкой на внешние хранилища, так на всякий случай. Потом эти архивы кладутся в папку которая расшарена по локальной сети на мой комп с виндой и установленным яндекс диском. Яндекс диск на винде сам видит изменения файлов на сетевом диске и выгружает файлы на максимальной скорости. В целом моя задача решается целиком и полностью, да без бубна с напильником не обошлось, но в итоге сервисом я доволен.
Поразительное сходство :D
Разных файлов может и больше, но их суммарный объём скорее меньше, потому что уникальные файлы у пользователей это как правило личные фотки и документы, может ещё домашнее видео с выпускных да свадеб. А вот фильмы, сериалы, торренты у всех одинаковые и весят они в разы больше чем фотки с документиками..
Попробуйте дописать файл в конце не меняя начало. Если поменялось начало (добавилось или убавилось), вероятней всего сменились границы сегментов и как следствие все последующие хэши.
А если почитать внимательно что я писал? У меня тариф у провайдера не позволит 800mb/s :)
У меня ПО яндекса на вот этой штуке вертится AS7008T-3FBD там HDD диски в массиве, но в массиве они выдают до 350mb/s, но при работе с ПО диска, там CPU слабое звено при расчёте хэшей.
Но в любом случае далеко не 1mb/s как тут ноют..
Ну не придирайтесь к словам, я знаю что копируется только мета информация в виде записи в бд. И что такое Copy-On-Write тоже знаю. Но не забывайте что большинство пользователей, всётаки пользователи, а не айтишники, для них понятным языком и пишу "копирует"..
Я тоже с вами не во всём соглашусь, да вы верно пишите, что файлы что есть у других не грузятся по факту (см. мой ответ на другое сообщение ниже), но я не соглашусь с этим:
1) >> ....... пространству нескольким юзерам. Что не есть хорошо. <<
А что простите в этом плохого? Зачем сохранять одни и те же данные много раз? Есть блоки данных, с байтами самой информации. Есть мета-данные, которые представляют из себя объект "файл" на диске пользователя. Мета данные можно разместить хоть у тысячи пользователей, и у всех у них будет тот же файл. Никаких рисков потери данных тут нет. При этом занимать он будет место на физических носителях всего 1 раз. К слову, это не ново, такой подход используется давно и очень много где. Например, у меня на NAS файловая система btrfs, она тоже использует такую технологию. Я могу 100500 раз скопировать какой нибудь фильм размером 20gb в кучу раных папок, или просто с разными именами. При этом размер свободного пространства на NAS не уменьшится. А если потом посчитать общий размер всех файлов в хранилище, он может превышать его физический объём. Это даже в какой то степени удобно, лично для меня.
2) >>Больше 42 МБ разогнать не удавалось<<
Это лишь подтверждает то что я писал вчера ещё. Да, не удалось, потому что вы упёрлись в CPU. Когда файл есть у других в точности какой и у вас, процесс выглядит иначе, клиент бьёт файл на сегменты, вычисляет hash, далее он получает от YD ответ что все куски есть и создаёт метаданные о файле уже на вашем диске. И скорость загрузки (в данном случае по факту никакой реальной загрузки данных нету) состоит из того, как быстро он вычислит hash у вас в локальной системе, потому что после этого он просто ставит флажок что сегмент загружен. И получается по времени:
начали обработку сегмента -> вычислили hash -> сделали запрос на YD и сразу моментально получили ответ что сегмент есть -> сегмент успешно "загружен"
Т.е. скорость = объём сегмента / время
И в виду отсутствия самой загрузки получается что скорость упирается в скорость рассчёта hash на вашем CPU.
3) на счёт того что он бьёт файлы на сегменты, это инфа тоже 100500%
как минимум для linux клиента. Во первых, у яндекс клиента очень подробные логи, можете сами посмотреть
Yandex.Disk/.sync/core.log
Там всё очень отчётливо прослеживается, как он бьёт файлы на сегменты, как он вычисляет hash от каждого кусочка, как потом он в 8 потоков эти кусочки грузит на YD и пишет отчёт по каждому отдельному сегменту.
Во вторых, это видно ещё и в htop, даже если не копаться в логах. Если резко ему подсунуть ОДИН большой файл, например 10gb, будет видно как 8 разных процессов грузят CPU. Если бы не было сегментирования, был бы один процесс который грузит одно ядро cpu, который вычислял бы hash от всего файла целиком. Но это не так. И в последствии, когда hash вычислены, у вас будет 8 процессов которые параллельно грузят сеть. Проверьте, сами увидите. Так что вопрос сегментирования это тоже инфа 100%
З.Ы. под сегментированием, может вы меня не так поняли, но физического разбиения файла на куски нету, я не зря писал "(виртуально)". Просто смотрите, скажем файл 8gb. Разбить файл на 8 кусков виртуально, это не значит сделать 8 маленьких файлов, это значит что создать 8 параллельных процессов, каждый из которых будет работать с этим одним файлом, но будет ограниченно читать из него данные, например первый процесс читает с файла данные с 0 по 1gb, второй процесс открывает этот же файл но читает данные начиная с 1gb от начала файла, и до 2gb от начала файла, и т.д. И каждый процесс со своими данными вычисляет хэш, загружает или и делает прочие операции параллельно и независимо от остальных.
Это всё верно, всё так, он не грузит файлы что есть у других пользователей, это я тоже заметил, когда 300gb загрузились практически за полчаса, при этом загрузка CPU была 100% а загрузка сети не поднималась выше 10% от ширины моего канала. Но это не отменяет того что я писал выше. Я на диск выгрузил 600gb данных, 300gb из них это папка с торрентами (фильмы, сериалы, коллекция музыки). Но кроме них, у меня там ещё 300gb бекапов. Этих данных, я могу с 100500% уверенностью сказать нет не у кого. Потому что я бекапы важных данных перед выгрузкой на YD прогоняю через утилиту aescrypt (я паранойик), она шифрует архивы моим персональным ключом, таких данных не может быть не у кого. И эти данные грузятся так же быстро.
Иначе объясните мне тогда, как я смог залить на диск 600gb данных за меньше чем сутки?
На самом деле покопав глубже, я всё понял. Проблема не в том как он отличает, а в том как работает клиент. В общем суть, яндекс апи, это "Extended WebDAV". И "расширенный" тут ключевое слово. Если у разработчика альтернативного клиента руки не оттуда, или ему лень разбираться в "Extended WebDAV", то да, резаться будет всё. Короче, как работает нормальный клиент, это может быть и альтернативный в том числе:
1) бьёт большой файл на сегменты (виртуально)
2) вычисляет от каждого сегмента его hash
3) делает запрос на апи яндекса, подсовывая список hash этих сегментов
4) получает ответ от яндекса, каких сегменты у него уже есть, а каких нет
5) грузит только те сегменты файла которых у YD нету (по их id полученные от яндекса в п.4).
——
Если не выполнять эти условия, скорость будет резаться.
Как работает "недо-клиенты", в том числе тот "curl" пример из первого поста:
1) пытается пропихнуть весь файл целиком без сегментирования и вычисления хэшей.
2) яндекс видит отсутствие хэшей и что ему пытаются пропихнуть огромный файл целиком, как итог яндекс такие клиенты режет.
И это вполне ОПРАВДАНО!
Поясню почему:
Представьте, у вас есть большой файл, скажем 20gb, который вы загрузили на диск. Вы изменили в нём пару байт (а может и просто дату создания файла) ваш клиент видит что файл изменился и шлёт весь файл на диск. Скорость вашего канала 200 мегабит. И таких как вы ещё 1000 человек по все РФ, которые поставили себе эти "недо-клиенты". Что случится с каналом связи яндекс цода? Ляжет он. Потому что 200 гигабит канал нужен будет, нет таких каналов. До кучи, вы все, все 1000 человек, загрузите на YD 20 TB данных, ПРИ ТОМ что у файлов изменилось пару байт из 20TB (со всех в сумме), или вовсе могла просто дата поменяться.
Короче, для себя лично я решил проблему просто и быстро, я создал для своего NAS docker образ с yandex disk официальным клиентом. И смонтировал в него нужный мне каталог.
Далее я создал ещё один docker образ, которому отключил сеть и дал лоступ к корневой системе в NAS, напихал всяких кронов, которые архивируют нужные мне папки и сервисы со всего NAS в тот каталог который доступен первому докер образу с яндексом. Итог, файлы выгружаются на яндекс диск на скорости 20 мегабайт в секунду (200 мегабит), это предел моего интернет канала.
Ничё там не режут
В общем, у меня тоже возникла необходимость делать бекапы, а в текущей ситуации в мире все иностранные подобные сервисы я сразу отмёл, а отечественных выбор не так велик. Короче наткнулся я на это сообщение и засомневался. Но провёл свои собственные тесты, и в итоге купил себе подписку на год. Что хочу сказать, первое, читайте внимательно ответ от техподдержки яндекса. Они вам не соврали, но читайте внимательно! Ответ шаблонный, но составлен грамотными юристами, я в этом ответе увидел следующие:
1) яндекс гарантирует что скорость работы с диском не будет ограничиваться с их стороны при использовании ОФИЦИАЛЬНОГО клиентского ПО от яндекса.
2) Яндекс НЕ гарантирует что скорость работы с диском не будет ограничиваться при использовании альтернативного ПО из других источников. И прямо намекают что они оставляют за собой право это делать. (что и сделали)
—— Собственно всё ——
По факту, после прочтения я провёл свои собственные тесты, которые подтвердили все вышесказанные подозрения, моя скорость интернета 200 мегабит. При загрузке файлов на яндекс диск и с яндекс диска, с использованием их официального ПО скорость была ограничена лишь моим каналом интернета.
При использовании альтернативного не официального клиентского ПО, скорость загрузки с яндекс диска на локальный диск была НЕ ограничена, при загрузки с локального диска на яндекс диск да, был 1 мегабит. Скрины прилагаю ниже (первые два выгрузка на яндекс диск через официальное ПО, последний загрузка с яндекс диска на локальный через альтернативное ПО NAS для внешней синхронизации).
То что загрузка на яндекс при использовании стороннего ПО ограничена, это конечно не приятно, но лично для меня не критично. В моём случае, ситуация следующая, у меня есть сетевое хранилище, на котором я храню всё важное. Было бы конечно хорошо, если бы ПО на сетевом хранилище само синхронизировалось с яндексом, но, файлов у меня много и они большие. Нет, это не видео с фотками :) Это архивы с проектами, пофайлово копировать в реальном времени для меня не вариант, там файлов миллиарды, по этому я настроил задание по расписанию, которое архивирует проекты по папкам и до кучи прогоняет архивы через AES шифровалку, перед загрузкой на внешние хранилища, так на всякий случай. Потом эти архивы кладутся в папку которая расшарена по локальной сети на мой комп с виндой и установленным яндекс диском. Яндекс диск на винде сам видит изменения файлов на сетевом диске и выгружает файлы на максимальной скорости. В целом моя задача решается целиком и полностью, да без бубна с напильником не обошлось, но в итоге сервисом я доволен.