Comments 60
В последние пару недель некоторые пользователи стали сообщать, что в их аккаунтах начали появляться прежде удалённые файлы и папки.
Намного неприятнее было бы, если произошло бы наоборот — с исчезновением живых и нужных файлов.
Когда у компании хранится по настоящему много данных, их дешевле пометить удаленными, но не удалять физически. Потому что винчестеры стоят все меньше, емкость их все больше, а фрагментация, которая возникает при физическом удалении файла, потеря скорости при доступе к фрагментированным данным и время работы дефрагментирующей программы — все это может перевесить стоимость хранения.
Да и любому, знакомому с самыми основами БД известно, что операция удаления записи — это пометка ее как удаленной. Очистка БД от удаленных записей — это совсем другая команда и, в случаи большого размера базы — очень затратная по процессорному времени.
Что такое — один CD содержащий всю-всю-всю информацию о студенте из статьи? Это примерно одна десятитысячная от объема современного винчестера — два-три русских рубля. Дешевле оставить их на харде, чем тратить время на удаление и дефрагментацию.
Да и любому, знакомому с самыми основами БД известно, что операция удаления записи — это пометка ее как удаленной. Очистка БД от удаленных записей — это совсем другая команда и, в случаи большого размера базы — очень затратная по процессорному времени.
Что такое — один CD содержащий всю-всю-всю информацию о студенте из статьи? Это примерно одна десятитысячная от объема современного винчестера — два-три русских рубля. Дешевле оставить их на харде, чем тратить время на удаление и дефрагментацию.
Ещё и ради дедупликации на серверах может хранится одна копия файла вечно. Для кого то этот файл удалён а кто то его только загрузил.
В случае соцсетей это действительно сложно. Хомячок загрузил фоточку, а её полайкали, написали комментарии, репостнули, отослали другу в приватных сообщениях и ещё 100500 действий. В итоге получается очень-очень сложный клубок зависимостей, где удалением и правда легко что-то поломать.
Но дропбокс — это просто хранилище и всё. Файлы просто лежат по папкам. Удалить их не составляет никакой принципиальной проблемы. Чисто технические нюансы — есть, но все они решаемы.
Но дропбокс — это просто хранилище и всё. Файлы просто лежат по папкам. Удалить их не составляет никакой принципиальной проблемы. Чисто технические нюансы — есть, но все они решаемы.
Видимо это тоже тот случай, когда дешевле было хранить, чем удалять. Ведь надо не просто удалить файл, надо делать это автоматически, гарантированно не прибив ничего лишнего, гарантированно дефрагментировать все хранилище. Программы мало написать, надо их всесторонне тестировать, выловить все баги и тд тп тд тп. Часто — дешевле и надежнее ничего не трогать.
Простите за интерес, у dropbox fat используется? Какие современные файловые системы надо дефрагментировать? Или у нас уже интернеты стали такими быстрыми, что жёсткие диски головки не успевают двигать? Что такого сложного в файлообменнике, что в файловых менеджерах эту задачу решают, в ftp серверах задачу решают, в файловых системах задачу решают, а в их продукте, который в этой части не сложнее файлового менеджера вдруг стало непосильной задачей.
Любые современные фс, в которых есть возможность удалять данные, подвержены фрагментации. Просто по определению и логике работы. Нужна вам при этом дефрагментация или плевать на снижение скорости от нее — это уже дело ваше. Они пытаются только чуть более оптимально файлы размещать, чтобы дичайшая фрагментация начиналась позже, а не прямо сразу.
Если не согласны — сразу пример: для простоты, диск на 1гб, забит файлами на 100% по 100 мб. Удалили 3 таких файла идущих на диске не подряд и записали один на 300 мб. Как это фс сможет сделать не фрагментировав его, по вашему?
Если не согласны — сразу пример: для простоты, диск на 1гб, забит файлами на 100% по 100 мб. Удалили 3 таких файла идущих на диске не подряд и записали один на 300 мб. Как это фс сможет сделать не фрагментировав его, по вашему?
Ну тогда и кнопка в интерфейсе должна быть не «удалить», а «удалить понарошку».
Мне кажется, тут вопрос и проблема не в том, что проще — удалять или хранить.
Тема в том, что сервис декларирует одно («файлы старше 60 дней удаляем, чесслово»), но фактически это оказывается не так.
И если им фат мешает или что-то еще, и это им известно, то неплохо было бы изменить обещание про 60 дней.
Тема в том, что сервис декларирует одно («файлы старше 60 дней удаляем, чесслово»), но фактически это оказывается не так.
И если им фат мешает или что-то еще, и это им известно, то неплохо было бы изменить обещание про 60 дней.
Именно. Мы тут недовольны пакетом Яровой, а там загруженные файлы не год, а вечность хранить собираются. К таким вещам надо относиться, как к брешам в безопасности, вроде утечки аккаунтов.
Файлы надо удалять. Процесс резервного копирования организовать так, чтобы удалённые файлы удалялись и из бекапов.
Файлы надо удалять. Процесс резервного копирования организовать так, чтобы удалённые файлы удалялись и из бекапов.
В общем случае из бакапов удалить файлы окажется сложнее чем организовать 'правильное' хранение. Тем более, бакапы могут быть вообще на readonly носителях, и стоимость удаления данных из них — это реорганизация, т.е. повторное копирование данных на новый носитель уже без удаленных, в общем дороговато.
Вот извините, это не проблема пользователей. Как если бы в парикмахерской вас побрили бы под ноль, сказав, что купили только машинки, потому что дешевле и проще. Пусть разрабатывают схемы под задачи, как бы.
Я то в принципе с вами согласен и не спорю.
Но бизнес есть бизнес.
В любом случае, я полагаю в реальности, файлы не удаляются совсем не по техническим причинам!
Но бизнес есть бизнес.
В любом случае, я полагаю в реальности, файлы не удаляются совсем не по техническим причинам!
Разрабатывают схемы под то, на что хватит денег и быстрее окупится.
Пользователей это как касается? Если бы честность была критерием успешности бизнеса, то живо бы средства нашлись. А пока пользователей держат за лохов, а те и рады. Даже сами отстаивают позицию сервиса.
Обычные пользователи держат в Дропбоксах фото своего кота и не хотят ради надежного удаления двукратного увеличения цены сервиса. Но у меня есть хорошая идея, как порадовать пользователей таких, как вы. В настройках пользователя поставить галочку «Я против имитации удаления моих файлов». При ее включении кнопка «Удалить файл» исчезает. Нет удаления — нет имитации.
Отличный комментарий, чего уж тут. Дескать, вы, параноики, не мешайте нам, нормальным людям, выкладывать всю свою подноготную всем кому попало.
Правда, моя паранойя подсказывает мне, что если бы dropbox вёл себя честно и без о всяких галочек писал бы на кнопке не «удалить», а «сделать вид, что удалил», любители котиков бы иначе бы относились к сервису.
Правда, моя паранойя подсказывает мне, что если бы dropbox вёл себя честно и без о всяких галочек писал бы на кнопке не «удалить», а «сделать вид, что удалил», любители котиков бы иначе бы относились к сервису.
Здравый смысл подсказывает, что если у вас паранойя, то вашим файлам вообще нечего делать ни на Dropbox, ни на Яндекс.Диске, ни на Google Drive. Вы говорите про публичные и в общем-то бесплатные файлохранилища, и удивляетесь, что они не слишком озабочены вашей приватностью. Ну да, не сильно. Эта штука предназначена для того, чтобы вы там могли что-то хранить для доступа с разных устройств, ну и имеет базовые функции безопасности, чтобы ей вообще был смысл пользоваться, только и всего.
Правильно подсказывает. Их там нет. :) Однако, кроме личной безопасности существует и коллективная. Если вокруг все болеют в опасности даже самый здоровый человек. Помню была новость, что один немецкий судья счёл подозрительным, что у подсудимых не было аккаунтов в соцсетях. Может и фейк, но настораживающий. А ну как завтра антисоциальными объявят тех, кто отказывается выкладывать всё, что у них есть в облако?
Да, это повод задуматься. Но с другой стороны, вдруг завтра будет облава на тех, кто ест мясо? А вы ещё не успели стать веганом? Или того хуже, гражданство будут давать только вейперам. А обычных курильщиков объявят вне закона. Что тогда делать, куда бежать?
От всех «а вдруг будет» вы не застрахуетесь. Поэтому маловероятные варианты лучше не рассматривать.
От всех «а вдруг будет» вы не застрахуетесь. Поэтому маловероятные варианты лучше не рассматривать.
Вы не в ту сторону путаете. Я не боюсь, что завтра человек без dropbox станет преступником. А недоволен именно последовательным навязыванием. Сначала нельзя удалить, потом нельзя не делиться, потом…
А вот ваши мотивы не понятны. Вы работаете на dropbox? Или вам как-то выгодно, что люди теряют контроль за личной информацией и жизнью? Или вам просто всё равно, но настолько что вы не ленитесь защищать здесь бизнес чужих для вас дядь? ;-)
А вот ваши мотивы не понятны. Вы работаете на dropbox? Или вам как-то выгодно, что люди теряют контроль за личной информацией и жизнью? Или вам просто всё равно, но настолько что вы не ленитесь защищать здесь бизнес чужих для вас дядь? ;-)
А недоволен именно последовательным навязыванием.
А где вы увидели «последовательное навязывание»? Есть какая-то контора, которая раздаёт свои услуги бесплатно, эта контора даже рекламку в ваш телевизор не показывала. Если вам нужна такая услуга, вы гуглите на эту тему, и сами к ней приходите, или к её конкурентам. Но вам, блин, не нравится, что она вам ещё и красную дорожку на ступеньки не постелила.
А вот ваши мотивы не понятны.
Мои мотивы такие же, как и у 99% участников всех дискуссий в Интернете. У меня свободное время, зашел на форум почитать, и вижу, что тут кто-то неправ. Я же не могу оставить это просто так.
Или вам как-то выгодно, что люди теряют контроль за личной информацией и жизнью?
Я в упор не понимаю, как можно назвать «потерей контроля за личной информацией» её добровольную передачу? Вы можете легко сохранить свою информацию у себя, просто не пользуясь этими (и другими такими же несекьюрными) онлайн-сервисами.
Но нет, лучше занять позицию толстой барышни — вроде и жирок уже свисает отовсюду, и делов-то всего-ничего, прекратить конхфетки по ночам жрать, и начать хотя бы час в день пешком ходить. Но и конфеты вкусные, и ходить лень. И остаётся только жаловаться, что всё плохо.
и вижу, что тут кто-то неправ
Не прав в том, что минимально заботится о своей безопасности? Ясно понятно. :)
Я в упор не понимаю, как можно назвать «потерей контроля за личной информацией» её добровольную передачу?
Потому что у них там есть договор присоединения, регламентирующий использование сервиса, в котором они объявляют условия работы. В частности, что информация остаётся принадлежащей её владельцу. А тут вдруг оказывается, что нет, владелец не может её удалить. Ну как вы сунули сумку в бесплатную камеру хранения в магазине, а там её тихо просканировали, потому что магазину интересно что ещё вы покупаете.
Вторжение в частную жизнь? Приличия? Законность? Не, не слышали. Каким лохам это нужно? Даёшь право сильного!
Не прав в том, что минимально заботится о своей безопасности?
Неправ в том, что возмущается по поводу действий тех, кто ему ничем не обязан.
Потому что у них там есть договор присоединения, регламентирующий использование сервиса, в котором они объявляют условия работы. В частности, что информация остаётся принадлежащей её владельцу. А тут вдруг оказывается, что нет, владелец не может её удалить.
Я ради интереса даже перечитал соглашение Дропбокса. Ещё они в том же соглашении пишут, что пользователь делегирует им право хранить и обрабатывать его информацию.
Вторжение в частную жизнь?
Не перегибайте. Ваша частная жизнь заканчивается за порогом вашего дома и за NAT'ом вашего домашнего роутера. Всё остальное — это общественная жизнь, которая идёт не по вашим правилам. Устраивают чужие правила, присоединяйтесь. Не устраивают, сидите дома. Не устраивают, но и дома сидеть не хочется, по этому поводу есть грубая поговорка про «съесть рыбку». Впрочем, ныть-то по поводу несовершенства общества тоже не запрещено. Но результата вам оно не принесёт. Тем более что даже магазин со своими бесплатными камерами хранения не несёт никакой ответственности за ваши сумки, а ваши покупки в магазине в любом случае попадут к маркетологам, которые потом под вас сформируют и расположение прилавков, и ассортимент, и музычку подберут — лишь бы вы побольше денег оставили в супермаркете.
кто ему ничем не обязан.
Смешно. Именно потому что они никому ничего не обязаны у них половина договора состоит из отказа от ответственности. :) Оферта это договор, законы никто не отменял. Надеюсь вы не являетесь владельцем какого-нибудь сервиса… :)
Я ради интереса даже перечитал соглашение Дропбокса.
Надо было читать полнее. :) "We need your permission to do things like hosting Your Stuff, backing it up and sharing it when you ask us to." А когда не ask и разрешение отозвано (ну, знаете, кнопка «delete»)…
Ваша частная жизнь заканчивается за порогом вашего дома и за NAT'ом вашего домашнего роутера.
Потрясающая наивность. К счастью, у меня нет желания заниматься вашим просвещением.
Тем более что даже магазин со своими бесплатными камерами хранения не несёт никакой ответственности за ваши сумки
И напоследок. Потому что больше я отвечать не буду. Будете заниматься бизнесом — консультируйтесь с юристами. С таким подходом вы даже в России рано или поздно сядете.
Смешно. Именно потому что они никому ничего не обязаны у них половина договора состоит из отказа от ответственности.
Именно потому, что половина договора состоит из отказа от ответственности, они никому ничем не обязаны. Как и Google. Как и разработчик вашей ОС, не суть важно, сообщество Linux или Apple, или Microsoft. И ни вас, ни кого-либо ещё из пользователей, никто не заставляет ни регистрироваться в ДропБоксе, ни принимать их соглашение. Пользователи сами, добровольно, идут на эти условия, потому что функции сервиса им нужнее, чем то непотребство, которое сервис может друг сделать с их дражайшими файлами.
Надо было читать полнее. :) «We need your permission to do things like hosting Your Stuff, backing it up and sharing it when you ask us to.»
А вам надо бы не только читать, но и головой думать. Этот самый permission — это и есть факт регистрации в Dropbox с установленной галочкой «Я согласен».
Потрясающая наивность. К счастью, у меня нет желания заниматься вашим просвещением.
Да, я тоже рад этому :) Как же вы с вашим «я требую приватности» вообще ухитряетесь выживать на этой планете?
И напоследок. Потому что больше я отвечать не буду. Будете заниматься бизнесом — консультируйтесь с юристами.
Спасибо. Не за совет (т.к. ваш последний ответ уже напоминает кидание какашками у школьника: «ваше образование», «консультируйтесь с юристами» и прочие штампы). А за то, что отвечать не будете. А то ей-богу, неприятно стало вас читать.
Честно говоря сомнительные объяснения (хоть и популярные). Вот прямо баз данных с auto vacuum нет на свете. И постоянный рост базы и поиск в ней это совершенно бесплатная операция, что ради неё проще забить на удаление мусора. И с дисками то же самое. Пишут там пишут всякие zfs, а потом приходят облачники и говорят, что им проще не удалять.
Файловая система вторична. Если на жестком диске удалили файл, на нем остается место, помеченное фс как пустое, в него будет записана часть другого файла, потому что файлы совершенно одинакового размера — встречаются не часто. И головка будет метаться по всем дорожкам — собирая файл в одно целое. Это потери во времени и большая вероятность ошибок, чем при последовательном чтении.
Дефрагментацию проводят тогда, когда затраты на хранение превышают затраты на дефрагментацию и цену вероятности потери данных.
Дефрагментацию проводят тогда, когда затраты на хранение превышают затраты на дефрагментацию и цену вероятности потери данных.
Я прекрасно знаю, как устроены файловые системы. Чего я не понимаю, так это того, понимаете ли вы в каком году живёте? Кончается второе десятилетие XXI века. Ну, знаете, гигабайты памяти, которые операционная система тратит под кэш, очереди ввода-вывода, в которых операционная система собирает запросы к накопителям и упорядочивает их. Те же очереди в контроллере, которые давно есть в каждом sata, не говоря уже про sas. И нам очень жаль бедную головку, для которой «метаться по всем дорожкам» в общем нормальное состояние. А если возникнет сбой, то будет произведено повторное чтение. А если диск откажет, то это штатная ситуация в файлохранилищах. Ведь там всё многократно продублировано рейдами и кластеризацией.
Но в сторону сопли. На хабре есть статья "Dropbox: взгляд изнутри". И там указана средняя скорость чтения с dropbox. И там намеряли среднюю скорость чтения с dropbox порядка 785 Mbps. Статье правда уже несколько лет, но это как раз неплохо. Потому что у меня в компьютере есть WD Green, купленный примерно в 2010. Я нещадно писал и стирал с него, иногда забивая полностью. Посмотрим же, как там себя файлы чувствуют. Я нашёл 5Gb файл, filefrag показал, что он состоит из 79 экстентов. А dd в /dev/null намерял скорость чтения 740MBps. Т.е. мои тормозные диски почти догнали dropbox. На фрагментированной ext4, пережившей туеву хучу обновлений Fedora.
Вас разводят выглядящей разумно сказочкой, которая на практике имела смысл для дискет. Для 20 мегабайтных жёстких дисков времён Windows 3.11. Но которая почти утратила смысл уже в концу 90-х и эре Windows 9x.
P.S. А zfs я привёл в пример сложной файловой системы, которая хранит много файлов, быстро отдаёт их и может удалять. И ничего, справились. Впрочем есть системы не хуже, особенно для системы вроде dropbox, где целостность и raid не задача файловой системы. Что же касается дефрагментации, — а нужна ли она ей?
Но в сторону сопли. На хабре есть статья "Dropbox: взгляд изнутри". И там указана средняя скорость чтения с dropbox. И там намеряли среднюю скорость чтения с dropbox порядка 785 Mbps. Статье правда уже несколько лет, но это как раз неплохо. Потому что у меня в компьютере есть WD Green, купленный примерно в 2010. Я нещадно писал и стирал с него, иногда забивая полностью. Посмотрим же, как там себя файлы чувствуют. Я нашёл 5Gb файл, filefrag показал, что он состоит из 79 экстентов. А dd в /dev/null намерял скорость чтения 740MBps. Т.е. мои тормозные диски почти догнали dropbox. На фрагментированной ext4, пережившей туеву хучу обновлений Fedora.
Вас разводят выглядящей разумно сказочкой, которая на практике имела смысл для дискет. Для 20 мегабайтных жёстких дисков времён Windows 3.11. Но которая почти утратила смысл уже в концу 90-х и эре Windows 9x.
P.S. А zfs я привёл в пример сложной файловой системы, которая хранит много файлов, быстро отдаёт их и может удалять. И ничего, справились. Впрочем есть системы не хуже, особенно для системы вроде dropbox, где целостность и raid не задача файловой системы. Что же касается дефрагментации, — а нужна ли она ей?
Попробуйте повторить тест увеличив число фрагментов до 79 тысяч.
Попробуйте сами что-нибудь замерить прежде чем пытаться задавить оппонента цифрами с потолка. Например, подсказали бы мне как разбить файл на 79 тысяч фрагментов, если при размере блока ext4 по умолчанию пятигигабайтный файл в принципе занимает лишь 2560 блоков на диске? Заодно попробуйте представить себе какой-нибудь не синтетический сценарий, при котором файлы оказались бы настолько фрагментированными. Потом вспомните, что в 2017 году продолжается переход на использование в датацентрах ssd, для которых все задержки окончательно становятся несоизмеримо меньше скорости передачи по сети. Ну и так далее.
В общем, давайте тестировать вместе. :)
В общем, давайте тестировать вместе. :)
Опять что за ерунду гонишь? 2560 блоков на 5 Гб максимум? По 2 Мб блок по умолчанию? Блок ext4 по умолчанию 4 кибибайта (а допустимый максимум обычно 64 КБ), так же как и в NTFS.
И на 5 Гб файл их приходится больше миллиона штук. Если как следует их перемешать, то этот миллион блоков без проблем может оказаться раскиданным на 79 тыс. отдельных кусков в разных местах диска. Это и есть сильная фрагментация. А 79 шт на 5 Гб — это можно считать отсутствие фрагментации, соответствующие утилиты покажут уровень фрагментации 0% если это типичный уровень для конкретного диска.
И на 5 Гб файл их приходится больше миллиона штук. Если как следует их перемешать, то этот миллион блоков без проблем может оказаться раскиданным на 79 тыс. отдельных кусков в разных местах диска. Это и есть сильная фрагментация. А 79 шт на 5 Гб — это можно считать отсутствие фрагментации, соответствующие утилиты покажут уровень фрагментации 0% если это типичный уровень для конкретного диска.
Главная ошибка в том, что сравнивается высоконагруженный сервис, превышающий масштабы вашего домашнего компа — на многие порядки.
А ваша главная ошибка в том, что вы предполагаете какую-то магию. Высокая нагрузка в dropbox приходится не на один несчастный жёсткий диск, а на весь датацентр, который вроде даже не один. Так что если вы не хотите сказать, что пользователи dropbox каждый день полностью перезаписывают его, то я не могу представить себе катастрофы фрагментации. Большая часть файлов как была загружена — так и лежит. А часто перезаписываемое вряд ли дробиться больше чем на несколько десятков фрагментов, что как было показано катастрофы не создаёт.
Какая еще магия? Вы пытаетесь экстраполировать свою домашнюю торрентокачалку на ЦОД и высоконагруженный сервис. Это как бомбила на шахе рассуждал бы о тонкостях логистики Ашана или с/х корпорации с позиции: «А что? Я же перевожу мешок картошки, значит надо всего-то миллион шестерок, дешево и удобно».
Но ЦОД это и есть «миллион шестерок». Там нет одного очень большого компьютера, нет одного очень емкого жёсткого диска.
Но вернёмся к теме лекции. Проблемы с фрагментацией файлов на диске касаются ЦОД в целом или это проблема отдельного накопителя, что с него данные медленнее считываются? Если нет, то что отличается? Если да, то давайте тестировать. У нас сейчас есть конкретный вопрос: На сколько фрагментированность файла влияет на скорость его чтения. Значит надо предположить условия, близкие к реальным и произвести замеры. Потому что сейчас ваши слова — «грех», аналогичный кнутовскому греху преждевременной оптимизации. Вы ещё не произвели ни одного замера производительности, но уже делаете выводы о скорости работы.
Но вернёмся к теме лекции. Проблемы с фрагментацией файлов на диске касаются ЦОД в целом или это проблема отдельного накопителя, что с него данные медленнее считываются? Если нет, то что отличается? Если да, то давайте тестировать. У нас сейчас есть конкретный вопрос: На сколько фрагментированность файла влияет на скорость его чтения. Значит надо предположить условия, близкие к реальным и произвести замеры. Потому что сейчас ваши слова — «грех», аналогичный кнутовскому греху преждевременной оптимизации. Вы ещё не произвели ни одного замера производительности, но уже делаете выводы о скорости работы.
Эксперимент не чистый. Во время эксперимента никто не дёргает ваш диск и эти 79 фрагментов дают лишь небольшую прибавку к времени чтения и не влияют на среднюю скорость.
А теперь отмасштабируйте эксперимент — одновременно с разных потоков обращайтесь к 2 таким файлам, 10, 1000 и т.д. ваша домашняя система заткнётся уже на первом десятке потоков сделав среднюю скорость по каждому потоку в 1Мб/с и меньше а дополнительные переключения между кусками файлов снизят производительность в геометрической прогрессии.
п.с. 79 тыс фрагментов возможны, если файл хранится в MFT но там немного другие алгоритмы и сходу сказать как это повлияет на производительность нельзя т.к. фрагменты будут скорей всего закешированы заранее.
Где-то уже было исследования гугла на эту тему, и о пользе нефрагментированных read-only ФС.
Суть одна — при малом количестве параллельных потоков разница незначительна, а при превышении какого-то порога средняя скорость чтения фрагментированных данных падает катастрофически вплоть до 10К/с даже на рейде из быстрых накопителей.
А теперь отмасштабируйте эксперимент — одновременно с разных потоков обращайтесь к 2 таким файлам, 10, 1000 и т.д. ваша домашняя система заткнётся уже на первом десятке потоков сделав среднюю скорость по каждому потоку в 1Мб/с и меньше а дополнительные переключения между кусками файлов снизят производительность в геометрической прогрессии.
п.с. 79 тыс фрагментов возможны, если файл хранится в MFT но там немного другие алгоритмы и сходу сказать как это повлияет на производительность нельзя т.к. фрагменты будут скорей всего закешированы заранее.
Где-то уже было исследования гугла на эту тему, и о пользе нефрагментированных read-only ФС.
Суть одна — при малом количестве параллельных потоков разница незначительна, а при превышении какого-то порога средняя скорость чтения фрагментированных данных падает катастрофически вплоть до 10К/с даже на рейде из быстрых накопителей.
Это что за бред тут прочитал? Там измеряли не скорость средняя скорость чтения с dropbox, а выборочный образец трафика на выборке создаваемой всего несколькими тысячами пользователей образца 2012 года. (за все время мониторинга больше месяца к сервису через отслеживаемые каналы хотя бы один раз подключилось всего 11 тыс. устройств, устройств у многих пользователей большее одного)
А пользователей у дропбокса сейчас несколько сотен миллионов. И это уже пользователи образца 2016 года с выросшими объемами файлов и активностью использования облачного хранения. И в результате суммарный трафик они создают минимум на 5 порядков (> 100 000 раз ) больше.
Диски же с тех пор не особо быстрее стали, ну раза в 1.5 только. На SSD облака никто и никогда не хранит — они для серверов и баз данных, а не для пользовательских файловых помоек. Они до сих пор еще много лет будут на магнитных дисках.
79 кусочков на 5 Гб файл это не о чем — практически нулевая фрагментация. По 64 Мб на 1 кусок — практически линейное чтение.
При серьезной фрагментации даже современные быстрые диски по скорости ниже 100 Mbps проседают относительно 1000-1500 Mbps линейных чтения/записи.
А пользователей у дропбокса сейчас несколько сотен миллионов. И это уже пользователи образца 2016 года с выросшими объемами файлов и активностью использования облачного хранения. И в результате суммарный трафик они создают минимум на 5 порядков (> 100 000 раз ) больше.
Диски же с тех пор не особо быстрее стали, ну раза в 1.5 только. На SSD облака никто и никогда не хранит — они для серверов и баз данных, а не для пользовательских файловых помоек. Они до сих пор еще много лет будут на магнитных дисках.
79 кусочков на 5 Гб файл это не о чем — практически нулевая фрагментация. По 64 Мб на 1 кусок — практически линейное чтение.
При серьезной фрагментации даже современные быстрые диски по скорости ниже 100 Mbps проседают относительно 1000-1500 Mbps линейных чтения/записи.
И потом. ZFS нельзя дефрагментировать, это ее недостаток, а не преимущество.
Я бы согласился, если бы у дропбокса был интенсивный уровень чтения/записи на гигабайт хранения, как, к примеру, у нетфликса. Но в реальности дропбокс — это файлопомойка и многие данные там просто лежат мертвым грузом. И какие бы дешевые диски не были, в случае файлопомоек ты быстро «вылетишь в трубу», если не будет управлять пространством.
Файлопомойка, но очень большая, гигантская. С огромным количеством пользователей.
Что до мертвого груза, это не про всех. Основная нагрузка на облако идет от тех, кто использует его для работы, покупает бизнес аккаунт и шарит множество файлов для совместной работы. Те, кто пользуют только бесплатный лимит — намного чаще изменяют свои файлы в облаке, потому что место заканчивается и надо его освобождать.
Что до мертвого груза, это не про всех. Основная нагрузка на облако идет от тех, кто использует его для работы, покупает бизнес аккаунт и шарит множество файлов для совместной работы. Те, кто пользуют только бесплатный лимит — намного чаще изменяют свои файлы в облаке, потому что место заканчивается и надо его освобождать.
У него довольно интересная идеология хранения — он вообще не хранит файлы, а чанки адресуемые по уникальным хэшм содержимого и базы данных в которых указано какой файл из каких чанков состоит.
Повторяющиеся чанки хранятся только один раз. За счет этого получается глобальная (между всеми пользователями) дедупликация данных. Если 1000 пользователей хранит один и тот же файл — реально он хранится только раз. Если пользователь хранит 100 версий какого-то файла, в котором что-то дописывается в конец или редактируется с заменой в реальности хранится только 100 последних кусочков + один основной набор исходной версии файла и т.д.
При запросе какого-то файла он на ходу «собирается» из нужных кусочков и отдается пользователю.
Не знаю сколько это позволяет выиграть на практике, но может оказаться что уровень чтения/записи на гигабайт хранения у него как раз весьма высокий.
Повторяющиеся чанки хранятся только один раз. За счет этого получается глобальная (между всеми пользователями) дедупликация данных. Если 1000 пользователей хранит один и тот же файл — реально он хранится только раз. Если пользователь хранит 100 версий какого-то файла, в котором что-то дописывается в конец или редактируется с заменой в реальности хранится только 100 последних кусочков + один основной набор исходной версии файла и т.д.
При запросе какого-то файла он на ходу «собирается» из нужных кусочков и отдается пользователю.
Не знаю сколько это позволяет выиграть на практике, но может оказаться что уровень чтения/записи на гигабайт хранения у него как раз весьма высокий.
«Иногда они возвращаются»
Ashley Madison также пытались отбрехаться, не вышло. Самое смешное, там полное удаление аккаунта стоило настоящих денег, а аккаунт оставался лишь помеченным на удаление… что и всплыло после грандиозной утечки.
В этом мире никому нельзя верить.
Как говорил он, даже у КГБ не было такого полного досье на граждан.
Ну правильно, люди сами не отправляли свои личные данные в КГБ.
Чаще всего пользователи и не знают о том, что на посещаемом им сейчас сайте может гнездиться целая стая «жучков» от разных известных брэндов, например, того же фэйсбука. В Лисе помогает заблокировать подлых насекомых :-) такое дополнение — https://addons.mozilla.org/ru/firefox/addon/ghostery/
Никто не смотрел на это под углом того, что все эти старые файлы все еще у них хранятся и вполне изучаются?
Никогда не храните файлы в Dropbox'е или в любом другом облаке, всегда предварительно их шифруйте сложным паролем. Заливайте только в виде образов TrueCrypt или в виде архивов WinRar/7zip. Никогда не доверяйте крупным корпорациям вашу личную информацию, она обязательно будет украдена и каким-либо образом использована без вашего ведома в их интересах ради прибыли.
Это про весь интернет можно так сказать.
Это можно сказать вообще о чём угодно в современном мире. От отслеживания посетителей в супермаркетах и торговых центрах до камер на дорогах и трекинга пассажиропотока в метро. Просто смиритесь, что чтобы вы ни делали или хранили об этом может узнать кто угодно при должном желании или по стечению обстоятельств, из-за ошибок систем и прочее. Sad but true.
UFO just landed and posted this here
Возник вопрос: почему, когда обновляют диски, файлы помеченные удаленными переносятся на новые?
И насколько сложно при переносе исключить такие файлы?
И насколько сложно при переносе исключить такие файлы?
Видимо копируют образом диск в диск, миграцией файловой системы или еще каким то способом, который не подразумевает пофайлового копирования
А разве обычно не рейд используют? Тогда меняют, видимо, так — вынимают один диск, ставят новый. Рейд восстанавливает состояние через некоторое время, информация не теряется.
Sign up to leave a comment.
В папки Dropbox стали возвращаться удалённые файлы. Баг исправлен