автоматический flush для для всех дисков

Кеды и так синкают все сами. Они не дадут размонтировать, пока процесс не завершен.

Можно порыться в настройках udisks, кеды через эту прослойку всё монтируют, у меня пример конфига лежит в /etc/udisks2/mount_options.conf.example, и заставить абсолютно всё внешнее монтироваться с sync. Винда именно так и монтирует ЕМНИП. Вот фрагмент например:

# This file contains custom mount options for udisks 2.x
# Typically placed at /etc/udisks2/mount_options.conf
# Refer to http://storaged.org/doc/udisks2-api/latest/mount_options.html
# 

### Simple global overrides
# [defaults]
# # common options, applied to any filesystem, always merged with specific filesystem type options
# defaults=ro
# allow=exec,noexec,nodev,nosuid,atime,noatime,nodiratime,ro,rw,sync,dirsync,noload

Но были жалобы на то что sync убивает некоторые карты памяти и флешки, кроме того в целом процесс происходит медленнее чем с кешами, даже с учётом времени их сброса для корректного отмонтирования.

В итоге оставили эту возможность на усмотрение юзера и как опцию индивидуальной настройки. Зато можно сразу выдёргивать как только «индикатор прогресса» пропадёт.

Короче можешь конфиг сотворить и принудительно всему втыкаемому sync включить, просто «по умолчанию», для всех, так не делается.

Ну и легендарный неуловимый и неустранимый баг когда всё фризилось и тормозило при копировании на флешку, я его номер забыл, от sync обострялся.

Короче то что ты хочешь делается так — в файл /etc/udisks2/mount_options.conf, или где он у тебя там, пишешь

[defaults]
defaults=sync

есть один вредный совет, можешь его попробовать, но я тебе его не рекомендую (потому что он уменьшает кэширование =вообще=, и у тебя просядеть производительной винчестера)

суть в том, чтобы значительно понизить vm.dirty*bytes
как вариант: понижаешь значения, копируешь на флешку, возвращаешь значения к прежнему виду

есть один вредный совет, можешь его попробовать, но я тебе его не рекомендую (потому что он уменьшает кэширование =вообще=, и у тебя просядеть производительной винчестера)

Это не влияет на производительность напрямую, а просто позволяет сгладить скачки нагрузки по записи на диск. Если выделить 2/4 мб под dirty_bytes/dirty_background_bytes, то может где-то какое-то влияние на типичном десктопе и можно будет замерить, сидя на каком-нибудь жестком диске вместо ссд. С 32/64 шансы уже стремятся к нулю даже в этом случае, при этом работа с флэшками станет гораздо комфортнее.

Кеды и так синкают все сами. Они не дадут размонтировать, пока процесс не завершен.

Угу. Хотя это выглядит странно и неудобно для пользователя. Закинув пару гигов на флэшку отмонтирование потом можно минут 15 ждать без всякой индикации прогресса.

А как это сделать? Можно пример что куда прописать. И это настраивается на всю систему или можно на съемные носители отдельно?

Система тормозит при копировании с nvme ssd на hdd (комментарий)

можно на съемные носители отдельно?

нет

Они не дадут размонтировать, пока процесс не завершен.

🤦

Причём тут кеды? Это ядро не даст ничего размонтировать пока не всё скинуто на носитель. И тут даже sync вводить не надо.

Так безопасно извлекать надо.

А как это сделать? Можно пример что куда прописать. И это настраивается на всю систему или можно на съемные носители отдельно?

/etc/sysctl.conf или /etc/sysctl.d/99-sysctl.conf, строчки (32 и 64 mb):

vm.dirty_background_bytes = 33554432
vm.dirty_bytes = 67108864

Затем sysctl --system должна применить настройки. После этого нужные значения будут в файлах:

cat /proc/sys/vm/dirty_bytes
cat /proc/sys/vm/dirty_background_bytes

Причём тут кеды? Это ядро не даст ничего размонтировать пока не всё скинуто на носитель. И тут даже sync вводить не надо.

При том, что у автора кубунта с кедами, и судя по вопросу слова «ядро» и прочие тонкости для него будут как минимум непонятны.

Собсно я ему написал как заставить кеды, и вообще любого использующего udisks чОрта лысого, монтировать абсолютно всё с sync «по умолчанию», раз уж ему руками каждому носителю включать sync лень. И получить то же самое поведение как и в Виндоус — индикатор прогресса до конца дополз и пропал — можно выдёргивать, даже отмонтировать, aka «безопасно извлекать», не обязательно (но желательно).

Но он я так понял другого хочет, он хочет чтобы индикатор прогресса пропадал когда кеш на диск сброшен. Но тут проблема в том что система не будет с этим торопиться, если её не пнуть через flush или umount... Так что он видимо желает чтобы после завершения копирования flush или umount вызывался автомагически и чтобы до окончания сброса кэша индикатор не пропадал. Как это реализовать у меня идей нет... «Нет асинхронного кэша — нет проблем» его не устраивает...

Всем спасибо, буду пробовать. Я так понимаю вариант с dirty_bytes, более щадящий для диска чем sync. Но с другой стороны 100 лет на Винде пользовался и не заморачивался об этом, все таки на USB Flash не так интенсивно что то пишется чтобы об этом париться. В общем попробую оба варианта.

Некоторые файловые системы (fat32, например) поддерживают опцию монтировниия flush — аналогично sync, но не настолько агрессивно.

Exfat тоже, да. Винда именно это и использует. Я все exfat флешки с flush монтирую. А сейчас посмотрел повнимательнее и увидел что я зря руками это включал, udisks по умолчанию vfat монтирует с flush.

Я все exfat флешки с flush монтирую.

А где это описано? В man mount exfat пока не добавили (хотя ядерный модуль уже некоторое время существует).

Наврал. flush поддерживает только vfat, и udisks по умолчанию с ним монтирует. А оба два exfat драйвера (fuse и ядерный) flush не умеют.

ок, тогда предложу хардкор
хотел предложить автору темы, но ему пока такое рановато, поэтому предложу тебе

у dd есть возможность копировать файл, минуя файловый кэш (опции direct и nocache). Может быть такой вариант хоть как-то улучшит ситуацию?
Взял отсюда, там же пример(ы) -> https://www.gnu.org/software/coreutils/manual/

В принципе, решение есть – autofsync

Когда починят «ускоренное» копирование файлов в Linux? (комментарий)

По крайне мере для mc и rsync работает.

После этого что то пошло не так. Копировал zip 5,6Гб, первые 25% прошли c нормальной скоростью, затем всё резко встало и индикатор дельфина начал показывать оставшееся время то 20 мин то 2 часа и т.д. Копирование продолжалось но очень медленно

После этого что то пошло не так. Копировал zip 5,6Гб, первые 25% прошли c нормальной скоростью, затем всё резко встало и индикатор дельфина начал показывать оставшееся время то 20 мин то 2 часа и т.д. Копирование продолжалось но очень медленно

Странно что копирование стало медленным только после 25%, должно было начать тормозить сразу. Значения точно применились?

Суть в том, что в начале копирования идет заполнение кэша dirty_bytes, т.е. первый кусок размером с этот кэш будет копироваться со скоростью чтения в оперативную память. Затем начнется уже реальная запись на флэшку, которая может быть дико медленной. Это уже зависит от флэшки и не зависит от размера кэша. Уменьшение размера кэша только приближает отображаемую скорость записи к реальной.

Я так понимаю вариант с dirty_bytes, более щадящий для диска чем sync.

Возможно в некоторых нетипичных случаях использования флэшки в качестве рабочего диска, на котором постоянно перезаписываются файлы или создаются временные.

Но изменить dirty_bytes проще, а буфер в 32/64 мб и так огромный. Значения по умолчанию в типичных дистрибутивах линукса «странные» для десктопа. Можно получить ситуацию, когда ты типа скопировал пару гигов на флэшку, а по факту запись еще даже не началась и потом она будет полчаса отмонтироваться.

Странно что копирование стало медленным только после 25%<

Параметры применялись, проверил как было написано cat… Сейчас повторно копирую, замедлилось сразу, временами вообще встает секунд на 20. После копирования sync отрабатывает сразу Да так раньше и было минут 15-20 ждал отмонтирования

Провел несколько экспериментов. Получил такие результаты: Копирования архива zip 5.6Гб на SanDisk Ultra USB3.0 32GB 32M/64M: Запись 16 минут. sync отработал мгновенно 64M/128M: Запись 8 минут. sync отработал за 18 секунд 128M/256M: Запись 5 минут. sync отработал за 15 секунд (почему то меньше чем при 64M/128M) 8Г/16Г: Запись 1 минута. sync отработал за 5 минут Оптимальным видится вариант 128M/256M т.к. и время работы sync не большое, и суммарное время получается даже меньше чем без ограничения (8Г/16Г) При 128M/256M ползунок прогресса движется равномерно без замедлений и резких продвижений. Но думаю для других USB Flash оптимальные параметры могут быть и другими.

ага, теперь дело за малым - попросить i-rinat обновить uthash.h (2.0.2 -> 2.3.0) и попробовать пересобрать либу

На другом ПК с Windows 10 записалось за 6,5 минут. Так что Linux при определенных настройках выигрывает процентов 30% времени

Так что Linux при определенных настройках выигрывает процентов 30% времени

Скорее всего просто случайный разброс для этой флэшки.

Вроде собирается и с uthash 2.3.0

i-rinat нужно ли что-то делать по этому поводу?

нужно ли что-то делать по этому поводу?

Не знаю. Зачем? Судя по ченжлогу uthash, там не было исправлений багов и не было изменения поведения функций. Добавили новые API, но если их не использовать, толку от этого ноль.