https://slinkov.ru/openforum/vsluhforumID3/115032.html Обладатели десктоп-клиента для работы с облачным сервисом Dropbox получили (https://www.dropboxforum.com/t5/Syncing-and-uploads/Linux-Dropbox-client-warn-me-that-it-ll-stop-syncing-in-Nov-why/m-p/290058#M42250) увеломление о скором прекращении поддержки синхронизации данных с облаком в случае использования файловых систем, отличных от Ext4. Начиная с 7 ноября синхронизация содержимого каталогов с Dropbox<br>станет невозможной, например, при использовании многослойных или шифрованных разделов (в том числе eCryptfs поверх ext4) или файловых систем XFS, ZFS и Btrfs.<br><br><br>Причина такого решения остаётся до конца не ясной, в комментариях от представителей Dropbox упоминается лишь необходимость поддержки в <br>ФС расширенных атрибутов/Xattrs, но многие пользователи находят данный довод неубедительным, так как все основные Linux ФС поддерживают расширенные атрибуты и нет явных факторов, которые бы подталкивали к привязке к Ext4.<br><br><br>URL: https://linux.slashdot.org/story/18/08/10/2120248/dropbox-is-dropping-support-for-al https://slinkov.ru/openforum/vsluhforumID3/115032.html#198 Mon, 06 Jan 2020 17:26:28 GMT https://db.tt/Wy64J39eSD<br> https://slinkov.ru/openforum/vsluhforumID3/115032.html#195 Wed, 15 Aug 2018 16:10:49 GMT &gt; Настоящие конспирологи хранят свои секретные документы только в личной памяти.<br>&gt; Всё остальное - лишь повод для терморектального криптоанализа, в процессе которого испытуемый <br>&gt; внятно и безошибочно сдаёт все ключи шифрования.<br><br>Правильно, пароль надо на бумажке записывать. И хранить ее под клавиатурой. Если не под клавиатурой - это уже форменное свинство.<br><br> https://slinkov.ru/openforum/vsluhforumID3/115032.html#194 Wed, 15 Aug 2018 16:06:40 GMT &gt; Банально, все сводится к тому - как быстро сдохнет блок головок или двигатель винта.<br><br>Двигатель почти вечный, 10 лет круглосуточной работы - обычное дело. Если шпиндель клинит, данные вынуть совсем не получается - юзеры очень расстраиваются. Пришлось научиться делать нормально.<br> https://slinkov.ru/openforum/vsluhforumID3/115032.html#193 Wed, 15 Aug 2018 15:52:08 GMT &gt; есть исследования что вся скорость F2FS -- это лишь следствие агрессивного кэширования, <br>&gt; реализованного с *нарушением* ранее установленного *протокола* синхронизации.<br><br>Скорость F2FS - из-за локализации данных и поведения удобного крупноблочному флешу. Вот так просто и банально. Некоторые другие ФС тоже пытаются подыгрывать флешу в таком духе, группируя записи, но когда это сразу в основы структур заложено - работает лучше, ясен перец.<br> https://slinkov.ru/openforum/vsluhforumID3/115032.html#192 Wed, 15 Aug 2018 15:50:37 GMT &gt; вообще-то все верно. выравниванием износа и прочими фишками должен заниматься контроллер, <br>&gt; а не фс. иначе будет только во вред.<br><br>Фигли, поучите Самсунг на флеш-память правильно записывать. Без вас крупнейший производитель флеша конечно же не разберется что произвел.<br> https://slinkov.ru/openforum/vsluhforumID3/115032.html#191 Wed, 15 Aug 2018 15:41:13 GMT &gt; Это изначально отключено и непонятно для кого это нужно.<br><br>Для более обычных файлух и систем где штуки типа fallocate() не работают или работают плохо. Но реально протирать файло нулями на штуках типа Linux в основном лишь сильно грузит диск в начале закачки, мало чего давая с точки зрения фрагментации. Достаточно хинта преаллокации, btrfs его понимает не хуже остальных.<br> https://slinkov.ru/openforum/vsluhforumID3/115032.html#190 Wed, 15 Aug 2018 15:39:02 GMT &gt; фрагментация в мультизадачной системе ничему не вредит.<br><br>Кроме того что потом при просмотре мувика диск начнет зашиваться и мувик чего доброго лагать начнет. Можно конечно на SSD качать, только дороговато это как-то получается...<br> https://slinkov.ru/openforum/vsluhforumID3/115032.html#189 Wed, 15 Aug 2018 15:37:10 GMT &gt; авторы торрент-программ сначало создают файл, заполненный нулями, но не дырками (аллоцируют <br>&gt; всё пространство файла, недопуская дырки).<br><br>Чтобы рассуждать о предмете - надо в нем разбираться. У системы есть апи, позволяющее заказать непрерывный регион "мягко", без записи. У сколь-нибудь нормальных клиентов есть настройки - использовать это апи, вообще протереть все нулями, или вообще не рыпаться.<br><br>Кстати протирание 20-гигового торента нулями гарантирует длительный тупняки, так что оптимальность именно этого режима довольно спорная даже для обычных файлух. На самом деле хватит и "мягкой" преаллокации через апи, если диск не забит под завязку. А если забит - ничего не поможет, потому что непрерывного региона на 20 гигов там просто нет.<br><br>&gt; затем думают что покусочкам этот файл изменяют.<br><br>Они его и изменяют по кусочкам, по мере получения данных. А насколько это (не)оптимально будет для конкретной файловой системы... 20-гиговый преаллокнутый торент с XFSа удалялся 30 минут. Не любит XFS работу с метаданн https://slinkov.ru/openforum/vsluhforumID3/115032.html#188 Wed, 15 Aug 2018 15:25:01 GMT &gt; Что до локального шифрования... А зачем? <br><br>Ну вот смотри, если некто левый дорвется до твоих данных, что хорошего они тебе сделают? Наверное ничего. А что плохого? Придумывается много разных вариантов. Наверное затем.<br>