Почему с sync'ом низкая скорость записи?

Question

[syxoi]

ФС - xfs, заметил, что с опцией sync (она нужна мне, чтобы в раму ничего не кэшировалось, а сразу писалось на диск) запись на внешний хард через интерфейс USB 2.0 скорость записи аж ~2! мебибайта, а без нее - ~24 мебибайта. Собсно почему такая низкая скорость? И как с этим бороться?

Answer 1

[Алексей Черемисин]

Просто, если писать маленькими блоками с опцией sync, то получается много накладных расходов, которые в USB занимают 20-30%. Другими словами, на каждый блок данных система будет ждать подтверждения от устройства о записи.
Если это дело кешировать (что и делает кеш) и/или писать большими блоками, то и скорость вырастет.

Comments

[syxoi]

А как писать большими блоками? Без кэша? Возможно ли?

[Алексей Черемисин]

syxoi: а чам пишем? конечно возможно.

[Adamos]

Алексей Черемисин: не факт. Кроме файлов, пишется еще и немало мелкой служебной информации. С требованием сразу ее записывать диск будет постоянно прыгать от одной дорожки к другой. Даже если сами файлы вы будете писать большими блоками.

[syxoi]

Алексей Черемисин: всм чем? Ну через cp,как обычно)

[Алексей Черемисин]

Adamos: Ну, да, здесь вы правы!Причем если много мелких файлов, то будет еще хуже.

[Алексей Черемисин]

syxoi: Собственно, а зачем вам вообще тогда опция sync? можно же, после каждого копирования вызвать утилиту sync! и да, в cp буфер не устанавливается. отдельные файлы можно переписать и через dd.
Я, если честно, не особенно понимаю ваш паттерн использования, может чего и получше предложил бы.

[syxoi]

Алексей Черемисин: У меня домашний сервер на базе старого железа (4 пень и гиг рамы) сейчас юзаю btrfs, и как-то недавно переносил данные с одного харда надругой и при просмотре фильма у меня появились какие-то блики (ладно, сначала все свалил на возможные задержки, но нет, на этой позиции файл поврежден, а некотопые даже ее воспринимались плеером. Сделл рекавео чанков - не помогло. Но при этом в свопе откуда-то взялись 50 миб примерно. Я думаю, что из-за недостатка ОЗУ могло не хватит рамы т.к. файлы большие по размеру (10-20 гиб) и могли так потерятся.ещё используется люкс и на нем все это дело

[Алексей Черемисин]

syxoi: во первых, если есть ошибки в файловой системе, то в основном они из-за качества или изношенности носителя. Swap здесь совсем нипричем. Если не хватает свопа, то происходит ошибка копирования, а не порча файла. Память скорее всего у вас не сбоит, иначе бы ядро вылетало в core. А точно ли оригинальный видеофайл не имел такого дефекта? Я очень часто с таким сталкиваюсь, просто работаю в данной области с видео. Собственно, выводов у меня два: либо носитель фиговый и упоротый, но это быстро бы сказалось на ошибках копирования, либо файл сам по себе такой. Так что можно не насиловать себя и убрать sync, все равно он вами не по назначению используется.

[Алексей Черемисин]

syxoi: ну и дополнительно, если уж совсем не уверены, считайте md5sum от ваших файлов и копируйте их вместе с файлами.

[Алексей Черемисин]

https://ru.m.wikipedia.org/wiki/Md5sum

[syxoi]

Алексей Черемисин: с помощью find'a можно высчитать контрольную сумму. просто проц очень слабый и все это дело долго делается. а носитель качественный и исправен. исходные файлы были впорядке. я вот думаю, мб btrfs чет гонит, поэтому на xfs перешел.

[Алексей Черемисин]

syxoi: да, можно
find -type f -exec md5sum "{}" + > checklist.chk

[syxoi]

Алексей Черемисин: у меня бывало на ntfs что файлы повреждались. Это был последний этап перед переходом на линукс

[Алексей Черемисин]

syxoi: Что-то у вас не так! У меня, нигде просто так, без аппаратных проблем, файлы не повреждались, еще ни разу.

[syxoi]

Алексей Черемисин: у меня тоже аппаратных проблем нет, раньше просто ИБП не было, а машина то в деревне