LINUX.ORG.RU

Ответ на: комментарий от anonymous

Но это не полное отключение кэширования, а просто уменьшение буфера до 2 метров, и не только для флэшки, а вообще.

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

Это суровый линукс, игрушки прибитые к полу и тд.

anonymous
()
Ответ на: комментарий от aureliano15

А почему убивает быстрее? Байтики ведь все равно запишутся, хоть через промежуточный буфер, хоть сразу...

Lavos ★★★★★
()
Ответ на: комментарий от Lavos

Потому что write amplification. Флэш физически пишется большими блоками, если сначала не накопить большой блок, а записывать отдельно сто раз по килобайту то запишутся сотни метров на самом деле, если нет аппаратного контроллера, который будет кэшировать сам уже после ОС.

anonymous
()
Ответ на: комментарий от anonymous

Из ответа для Lavos:

записывать отдельно сто раз по килобайту то запишутся сотни метров

Ну это, имхо, небольшое преувеличение, т. к. блоки записи  — 4 — 8 Кб:

When data is first written to an SSD, the cells all start in an erased state so data can be written directly using pages at a time (often 4–8 kilobytes (KB) in size).

( https://en.wikipedia.org/wiki/Write_amplification#Basic_SSD_operation )

Но по существу всё так.

aureliano15 ★★
()
Ответ на: комментарий от Lavos

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

Deleted
()
Ответ на: комментарий от aureliano15

А не знаешь как сделать чтобы любые диалоги копирования/удаления закрывались по реальному завершению операции например как «cp a b && sync»... Интересно как это скажется на производительности, а точнее на отзывчивости софта в целом?

LinuxDebian ★★★★
()

Тебе не понравится результат, на 3.0 скорость 250Кб из 5М.

mount -o sync /dev/sd?# /mnt

LinuxDebian ★★★★
()
Последнее исправление: LinuxDebian (всего исправлений: 1)
Ответ на: комментарий от LinuxDebian

как сделать чтобы любые диалоги копирования/удаления закрывались по реальному завершению операции

Не понял, о чём речь. У меня они и так закрываются по завершении. Или речь о том, чтоб закрывались только после физического сброса кэша на диск? Этого не знаю, но думаю, что никак, т. к. пользовательские программы дисковым кэшем не управляют, за исключением возможности принудительной синхронизации.

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

Именно после физического. Пользовательский софт юзает системные функци и я думаю может где-то можно выставить что-то вроде flush процесс записи в конце должен подвиснуть в ожидании записи буфера... Пробовал монтировать с ним но эффекта нет.

LinuxDebian ★★★★
()
Ответ на: комментарий от LinuxDebian

Это, я думаю, зависит от настроек той или иной программы. Но в рабочих окружениях KDE, Gnome и форках гнома можно настроить собственные контекстные меню с собственными командами, в т. ч. и со скриптами. Есть команды, позволяющие отображать графические диалоги и возвращать введённые данные скрипту, например

zenity --file-selection --directory
Используя их, можно настроить графическое окружение так, чтобы при нажатии правой кнопкой мыши по файлу или каталогу выскакивало пользовательское меню с пунктом, предлагающем копирование с синхронизацией, по нажатии на который предлагать ввести путь, куда надо скопировать выбранный элемент. Затем в фоновом режиме запустить
check_cp | zenity --progress &
а в командном режиме
cp -Rf выбранный_файл_или_каталог выбранная_зенитом_директория && sync
check_cp — это тоже пользовательский скрипт, из него проверять, висит ли ещё cp по его пиду, отображая прогресс по разнице размера (или суммы размеров) исходных и выходных файлов, а в случае нажатия на cancel прибивать cp и по желанию удалять недописанные файлы/каталоги на стороне приёмника. Потом анализировать код возврата cp и в случае чего выводить диагностическое сообщение. Думаю, как-то так.

aureliano15 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.