Синхронная запись на съёмные носители

mount -o sync Но не советую.

Почему не советуешь?

Забыл написать, у меня KDE и прочий досктоп. Хочу чтобы это всё автомагически происходило. Ещё было бы круто, если бы это работало в том числе при прямой записи на девайс. Потому что dd образа на флешку выглядит примерно так: сначала весь образ закатывается за 3 секунды, а потом dd молча висит полчаса.

Можно глобально прописать низкий vm.dirty_bytes и vm.dirty_background_bytes, для отдельных устройств так по-моему и не сделали.

А может и сделали, потыкай /sys/class/bdi/*/strict_limit

Можно глобально прописать низкий vm.dirty_bytes и vm.dirty_background_bytes, для отдельных устройств так по-моему и не сделали.

Грусть-печаль :(

Системные диски я такому подвергать не хочу. Только съёмные.

лялекс пишет файлы как обычно в кэш

Известная полянка, наступал на эти грабли. Поначалу думаешь, что всё скопировал ось и вытаскивает флешку с понятным результатом. С точки зрения UX это дно.

К логопеду, быдло!

:)

Почему не советуешь?

Потому что твои съёмные носители износятся ощутимо быстрее.

Потому что твои съёмные носители износятся ощутимо быстрее.

С чего бы? Количество записанной информации одинаково что так что так.

например, чтобы можно было отменить копирование кучи файлов на середине.

А в чëм же тут преимущество? С кешированием для такой «отмены» вы просто удаляете всë это якобы скопированное ну и оно может и вовсе на флешку не пойдëт даже частично если кеш не начал сбрасываться.

А в чëм же тут преимущество?

В том, что я не получу битые файлы.

Так для этого просто правильно отмонтировать надо. А при чëм здесь отмена копирования?

А при чëм здесь отмена копирования?

1. Я копирую на диск 100500 файлов
2. В середине я понимаю, что мне надо срочно пойти посрать, обязательно взяв диск с собой
3. Я нажимаю «Отменить»
4. Мгновенно отмонтирую, потому что все скопированные файлы записались
5. Иду срать

Сценарий понятен? В текущей ситуации реальное копирование происходит в момент синка при отмонтировании и его никак нельзя прервать. И это проблема.

В подобной теме - автоматический flush для для всех дисков - ничего ценного не нашел? flush, например, в опциях (но это все равно чуть не то).

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

[defaults] defaults=sync

Вот это похоже на правду, спасибо за подсказку.

Потому что твои съёмные носители износятся ощутимо быстрее.

С чего бы? Количество записанной информации одинаково что так что так.

Количество информации — одинаково, а количество записей — нет.

Записывая чанками по 1M, они будут разбиваться контроллером по размеру блока. А когда у тебя отключены кэши, то может прилетать и по 1B, и этот каждый отдельный байт будет ПЕРЕзаписывать блок (который обычно 512B) целиком.

каждый отдельный байт будет ПЕРЕзаписывать блок (который обычно 512B) целиком

У NAND физические блоки обычно гораздо больше, 128 Кб и больше, например.

износятся ощутимо быстрее

С чего бы?

про sync на flash даже в мане написано

In the case of media with a limited number of write cycles (e.g. some flash drives), sync may cause life-cycle shortening.

Сри в кэш, ну.

у меня KDE и прочий досктоп. Хочу чтобы это всё автомагически происходило

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

Тем более.

In the case of media with a limited number of write cycles (e.g. some flash drives), sync may cause life-cycle shortening.

Ага, ичо?

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

Плюс, венда пишет на съёмные носители в синхронном режиме. Если бы венда гробила флешки, вой бы стоял на всю улицу уже давно.

про размер блока тут написали

нет, то что делает винда - это не синхронный режим

исходников винды я не видел, но выглядит как очень маленький кеш на запись и время для кеширования

Возможно, что и так, да. Но я очень сомневаюсь, что cp или аналоги из KDE будут писать файл по байтам. Почти наверняка там блочная запись.

cc mord0d

Но я очень сомневаюсь, что cp или аналоги из KDE будут писать файл по байтам. Почти наверняка там блочная запись.

Если ты отключишь кэширование, то писать будет ровно столько, сколько смогло за раз прочитать. И нассать чем ты там читаешь/пишешь, если I/O занимается ядро ОС.

Если ты отключишь кэширование, то писать будет ровно столько, сколько смогло за раз прочитать.

Ага, я в курсе. Но т.к. чтение при копировании тоже с блочного девайса идёт, то в итоге и норм должно быть.

То есть да, я согласен, что в идеале нужно уменьшить съёмным девайсам размер буфера до нескольких десятков мегабайт. Но лялекс не может :(

Можно принудительн после каждого файла делать sync. Придётся закостылить небольшой скриптец для копирования вместо обычного cp, но это решит озвученную проблему: каждый новый файл будет начинать копироваться только когда предыдущий полностью на флешке. Это более щадящий способ, чем сбрасывать прям всё-всё сразу.

(Завершение по ^C отлавливать с помощью trap между, и последний файл (который начал копироваться, но не синкнулся, очевидно) в таком случае удалять)

Но т.к. чтение при копировании тоже с блочного девайса идёт, то в итоге и норм должно быть.

Не должно. Кэши не регулируются per-device и отдельно на input И output, а значит если output свободен, то начнёт писать столько, сколько упало с input. Было бы слишком хорошо, если бы буфер чтения всегда был больше буфера записи.

Можно принудительн после каждого файла делать sync.

Да, это идея. Можно попробовать KDEшникам патч присунуть даже.

Можно попробовать KDEшникам патч присунуть даже.

Тогда лучше int fsync(int fd), чтобы лишнее синкать

а потом dd молча висит полчаса

status=progress