Bug 12048 - опция sync в ядрах 2.6.х
Summary: опция sync в ядрах 2.6.х
Status: CLOSED WONTFIX
Alias: None
Product: ALT Linux Desktop
Classification: Distributions
Component: bugs (show other bugs)
Version: snapshot
Hardware: all Linux
: P2 normal
Assignee: Anton V. Boyarshinov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-15 16:31 MSD by aleksey
Modified: 2008-07-03 10:20 MSD (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description aleksey 2007-06-15 16:31:41 MSD
Опция sync для fat по слухам "исправлена" начиная с 2.6.13
 в ядре 2.6.19 для fat появилась аналогичная sync опция flush
 У нас сейчас ядро 2.6.18 в котором опция   sync "исправлена", а опции flush
 нет.
 Последний факт проверен на kernel-image-std-smp-2.6.18-alt4 и
 mount-2.12r-alt5.
таким образом синхронная запись на съемный носитель практически невозможна(с 
установленной опцией sync запись идет очень медленно), это снижает ценность 
altlinux для простого пользователя
Comment 1 Andrey Rahmatullin 2007-06-16 15:47:21 MSD
Почему снижает?
Comment 2 Roman Savochenko 2007-06-17 19:00:27 MSD
Потому что нет нормальной, простой и надёжной политики/механизма доступа 
к сменным носителям, понятной простому пользователю. В настоящей 
ситуации со сменными носителями даже у меня (пользователь Linux с 
пятилетним стажем) возникают проблемы.

Похожая бага: 11981
Comment 3 Andrey Rahmatullin 2007-06-17 19:11:35 MSD
(In reply to comment #2)
> Потому что нет нормальной, простой и надёжной политики/механизма доступа 
> к сменным носителям, понятной простому пользователю.
Это общие слова. По сути баги можете что-то сказать?
Comment 4 Roman Savochenko 2007-06-17 19:42:16 MSD
(In reply to comment #3)
> (In reply to comment #2)
> > Потому что нет нормальной, простой и надёжной политики/механизма 
доступа 
> > к сменным носителям, понятной простому пользователю.
> Это общие слова. По сути баги можете что-то сказать?
Это как раз по сути. Если Вам нужны детали, то я могу их на страницу 
расписать, да и поднимался этот вопрос неоднократно, где я многократно 
отстаивал политику корректно работающей опции "sync"+автомонитровщик.
Под корректной я имею ввиду то как она работала до версии ядра 2.6.13, 
если опустить вопрос не полной актуализации FAT к содержимому.
Обсуждение здесь: 
http://lists.altlinux.ru/pipermail/community/2006-March/176532.html

Comment 5 Andrey Rahmatullin 2007-06-17 19:56:27 MSD
> Обсуждение здесь: 
> http://lists.altlinux.ru/pipermail/community/2006-March/176532.html
Увидел только ерунду про "давайте откатим не знаю что на неработавший никогда 
вариант".
Просьба конструктивно описать, что же именно вы хотите изменить.
Comment 6 Roman Savochenko 2007-06-17 20:43:42 MSD
Ладно.
Начну с того, что опция "sync" до версии ядра 2.6.13 работала следующим 
образом:
 - запись на носитель смонтированный с этой опцией происходила 
инкрементально и фактически минуя дисковые буфера и кеши;
 - благодаря этому, физический процесс записи на носитель полностью 
визуально контролировался, т.е. окончание визуального процесса записи 
гарантировало окончание физической записи и пользователь мог смело 
выдёргивать носитель (для флоппи это вообще единственно верное и 
возможное решение).

Вывод: Кеширование/буферирование дисковых операций записи мало того, что 
бесполезная так ещё и вредная операция. И от неё важно избавится для 
съёмных носителей.

Важно чётко различать понятие "съёмный" и "стационарный" носители.
Съёмный носитель - носитель который подключается временно и операции с 
которым должны выполняться непосредственно, минуя 
кеширование/буферирование (floppy, usb-disk, DVD+RW+прямая запись).
Стационарный носитель - носитель, возможно даже и съёмный, 
предназначенный для долговременной работы, обычно в течении рабочего 
дня (usb-disk). Здесь кеширование/буферирование нужно, но ввиду своей 
разовости операция перемонтирования здесь уместна.

Так вот, сейчас, механизма исключить работу с буфером/кешем для съёмных 
носителей нет и это печально. Опция "flush", о которой говорил Антон, 
проблему полносью не решает. Я её опробовал на Knoppix, где ядро 2.6.19. 
С этой опцией данные всёравно копируются в дисковый буфер/кеш, а значит 
визуальный процесс индицирует про мгновенную запись. Сама опция 
приводит к тому, что данные начинают сразу-же сбрасываться с буфера на 
носитель.

Из отрицательного опыта, который имел место недавно на ALT4.0, и который 
наглядно демонстрирует вред буферов для съёмных носителей:
 - ноутбук с USB-1.1 и памятью 256Мб;
 - подключил flash-disk объёмом 2Гб;
 - смонтировал и начал писать файл объёмом 700Мб;
 - в начале индикатор показал оптимистичную скорость под 3Мб/сек 
(копирование в буфер), а к концу скорость упала до 600Кб/сек.
 - по визуальному завершению процесса копирования я 
активировал "Безопасное извлечение диска", секунд через 30 система 
сообщила, что не может этого сделать, с выдачей диалога сообщения о 
возможных проблемах на двух языках (русском и англиском в перемешку);
 - в результате я 4 минуты пытался его отмонтировать, пока он не сбросил 
содержимое 128Мб кеша на флешку;

Вывод: если бы на моём месте был рядовой пользователь, не понимающий 
сути происходящего и верящий тому, что показывает визуализатор записи и 
системным сообщениям отмонтирования, то он наверное за эти 4 минуты 
разбил-бы ноут и с Linux не когда не связывался. :)

Лично я сейчас не вижу правильного решения этой проблеммы, в виду её 
технической не решенности. Её только можно сгладить за счёт 
опции "flush". Поэтому и говорится о "снижении ценности altlinux для 
простого пользователя".
Comment 7 Andrey Rahmatullin 2007-06-17 20:58:05 MSD
(In reply to comment #6)
> Ладно.
> Начну с того, что опция "sync" до версии ядра 2.6.13 работала следующим 
> образом:
>  - запись на носитель смонтированный с этой опцией происходила 
> инкрементально и фактически минуя дисковые буфера и кеши;
>  - благодаря этому, физический процесс записи на носитель полностью 
> визуально контролировался, т.е. окончание визуального процесса записи 
> гарантировало окончание физической записи и пользователь мог смело 
> выдёргивать носитель (для флоппи это вообще единственно верное и 
> возможное решение).
Ссылку, пожалуйста.

> Вывод: Кеширование/буферирование дисковых операций записи мало того, что 
> бесполезная так ещё и вредная операция. И от неё важно избавится для 
> съёмных носителей.
Ерунда.

> Съёмный носитель - носитель который подключается временно и операции с 
> которым должны выполняться непосредственно
Нет.

> Лично я сейчас не вижу правильного решения этой проблеммы, в виду её 
> технической не решенности. Её только можно сгладить за счёт 
> опции "flush". Поэтому и говорится о "снижении ценности altlinux для 
> простого пользователя".
s/altlinux/linux/
Comment 8 Roman Savochenko 2007-06-17 21:06:57 MSD
(In reply to comment #7)
> (In reply to comment #6)
> > Ладно.
> > Начну с того, что опция "sync" до версии ядра 2.6.13 работала 
следующим 
> > образом:
> >  - запись на носитель смонтированный с этой опцией происходила 
> > инкрементально и фактически минуя дисковые буфера и кеши;
> >  - благодаря этому, физический процесс записи на носитель полностью 
> > визуально контролировался, т.е. окончание визуального процесса 
записи 
> > гарантировало окончание физической записи и пользователь мог смело 
> > выдёргивать носитель (для флоппи это вообще единственно верное и 
> > возможное решение).
> Ссылку, пожалуйста.
Ссылку на что?

> > Вывод: Кеширование/буферирование дисковых операций записи мало того, 
что 
> > бесполезная так ещё и вредная операция. И от неё важно избавится для 
> > съёмных носителей.
> Ерунда.
Обоснуйте.
Comment 9 Andrey Rahmatullin 2007-06-17 21:14:13 MSD
(In reply to comment #8)
> > Ссылку, пожалуйста.
> Ссылку на что?
На описанное вами поведение параметра sync в ядрах младше .12.

> > Ерунда.
> Обоснуйте.
Скорость записи и скорость умирания носителя.
Comment 10 Roman Savochenko 2007-06-17 21:29:30 MSD
(In reply to comment #9)
> (In reply to comment #8)
> > > Ссылку, пожалуйста.
> > Ссылку на что?
> На описанное вами поведение параметра sync в ядрах младше .12.
В той ссылке, которую я Вам не случайно дал, я такое поведение описывал. 
Если Вас не затруднит то Вы легко его там найдёте. Если Вам лень, я 
лично для Вас проведу эти опыты на своём сервере ещё раз.

> > > Ерунда.
> > Обоснуйте.
> Скорость записи и скорость умирания носителя.
Не вижу связи. У меня с "sync", когда он правильно работал никто не умер. 
Это сейчас, в так называемом "исправленном" состоянии, по каждой записи 
перезаписываются сектора с FAT, что и тормозит его на порядки. Ещё раз 
повторяю, до 2.6.13 "sync" работал так как я описывал не заёлозивая 
сектора с FAT!
Comment 11 Andrey Rahmatullin 2007-06-17 21:44:10 MSD
(In reply to comment #10)
> > На описанное вами поведение параметра sync в ядрах младше .12.
> В той ссылке, которую я Вам не случайно дал, я такое поведение описывал. 
> Если Вас не затруднит то Вы легко его там найдёте. Если Вам лень, я 
> лично для Вас проведу эти опыты на своём сервере ещё раз.
[...]
> Это сейчас, в так называемом "исправленном" состоянии, по каждой записи 
> перезаписываются сектора с FAT, что и тормозит его на порядки. Ещё раз 
> повторяю, до 2.6.13 "sync" работал так как я описывал не заёлозивая 
> сектора с FAT!

У вас каша в голове.
Comment 12 Roman Savochenko 2007-06-17 21:45:49 MSD
Вот выдержка из указанного мною треда:
> 2.4.26 fat
> С sync: 41 сек, и прогресс показывается до конца записи;
> Без sync: 39 сек, сразу сливается в буфер и копирует SubFs;

> Кстате заценил только что проблему работы без sync:
>  - копирую файл размером в 1М и вспоминаю что не засёк время;
>  - перехожу на панель с флопиком и удаляю копируемый файл;
>  - процесс удаления зависает до момента завершения копирования SubFs.

По мне так очень наглядный пример. :) 
Comment 13 Roman Savochenko 2007-06-17 21:48:29 MSD
(In reply to comment #11)
> (In reply to comment #10)
> > > На описанное вами поведение параметра sync в ядрах младше .12.
> > В той ссылке, которую я Вам не случайно дал, я такое поведение 
описывал. 
> > Если Вас не затруднит то Вы легко его там найдёте. Если Вам лень, я 
> > лично для Вас проведу эти опыты на своём сервере ещё раз.
> [...]
> > Это сейчас, в так называемом "исправленном" состоянии, по каждой 
записи 
> > перезаписываются сектора с FAT, что и тормозит его на порядки. Ещё 
раз 
> > повторяю, до 2.6.13 "sync" работал так как я описывал не заёлозивая 
> > сектора с FAT!
> 
> У вас каша в голове.
Главное что-бы с маслом. :)
А что, собственно, не так?

Comment 14 Andrey Rahmatullin 2007-06-17 21:54:34 MSD
(In reply to comment #13)
> А что, собственно, не так?

То у вас "раньше sync работал, вот линка, где написано, что раньше он не 
работал", то "раньше sync не обновлял fat по каждому чиху".
Comment 15 Roman Savochenko 2007-06-17 22:03:28 MSD
(In reply to comment #14)
> (In reply to comment #13)
> > А что, собственно, не так?
> 
> То у вас "раньше sync работал, вот линка, где написано, что раньше он 
не 
> работал", то "раньше sync не обновлял fat по каждому чиху".
Тогда по порядку, как есть:
- ALT2.4 (2.4.26) - с "sync" пишет быстро, прямо на диск минуя буфер. 
Визуализация процесса записи соответствует физической записи на 
носитель.
- ALT3.0 (2.6.12) - c "sync" пишет медленно, прямо на диск минуя буфер. 
Визуализация процесса записи соответствует физической записи на 
носитель.

Так понятно?
Comment 16 Andrey Rahmatullin 2007-06-17 22:08:46 MSD
(In reply to comment #15)
> Так понятно?
Предположим.
Непонятно, в  чём проблема.
Comment 17 Roman Savochenko 2007-06-17 22:14:13 MSD
(In reply to comment #16)
> (In reply to comment #15)
> > Так понятно?
> Предположим.
> Непонятно, в чём проблема.
Проблема в том, что уже в 2.6.12 и сейчас "sync" работает не так как в 
2.4.26. А именно: медленно пишет, елозит сектора с FAT по каждой записи. 
В 2.4.26 работало так как нужно: пишет мимо буфера и прямо на диск, 
визуализация соответствует физическому процессу записи, не елозит 
сектора с FAT.

Comment 18 Andrey Rahmatullin 2007-06-17 22:18:46 MSD
(In reply to comment #17)
> В 2.4.26 работало так как нужно: пишет мимо буфера и прямо на диск, 
Вы уверены? Линку.
Comment 19 Roman Savochenko 2007-06-17 22:29:15 MSD
(In reply to comment #18)
> (In reply to comment #17)
> > В 2.4.26 работало так как нужно: пишет мимо буфера и прямо на диск, 
> Вы уверены? Линку.
Оказывается это моё письмо в архив не попало. Взял его у себя из 
исходящих и копирую его сюда полностью:
//===== Re: [Comm] USB-диск. безопасно извлечь (15.03.2006 19:29)======
Damir Shayhutdinov wrote:

>> Проверил.
>> ext2 пишеться всего в 2 раза медленее с sync чем без неё. При этом с 
sync процесс копирования отображается нормально, а без просто сливает в 
буфер, а далее заканчивает копировать SubFs. Т.е процесс копирования 
вообще до фанаря.
>> В то время как fat раз в 20 медленее!
>> Это на ядре 2.6.12. Вывод: Вся проблема в эфективности синхронизации 
которую в ядрах 2.6 поламали.
>
> Сравните скорость записи на 2.4.26 (или 2.6.8) с sync и без на fat.

2.4.26 fat
С sync: 41 сек, и прогрес показывается до конца записи;
Без sync: 39 сек, сразу сливается в буфер и копирует SubFs;

Кстате заценил только что проблему работы без sync:
 - копирую файл размером в 1М и вспоминаю что не засёк время;
 - перехожу на панель с флопиком и удаляю копируемый файл;
 - процесс удаления зависает до момента завершения копирования SubFs.

По мне так очень наглядный пример. :)

С уважением Роман! 
//===============================================================
Остальное можно в архиве треда проследить.
Comment 20 Andrey Rahmatullin 2007-06-17 22:34:32 MSD
(In reply to comment #19)
> > > В 2.4.26 работало так как нужно: пишет мимо буфера и прямо на диск, 
> > Вы уверены? Линку.
> Оказывается это моё письмо в архив не попало.
Не канает. Натурные опыты - не доказательство.
Comment 21 Roman Savochenko 2007-06-17 22:41:05 MSD
(In reply to comment #20)
> (In reply to comment #19)
> > > > В 2.4.26 работало так как нужно: пишет мимо буфера и прямо на 
диск, 
> > > Вы уверены? Линку.
> > Оказывается это моё письмо в архив не попало.
> Не канает. Натурные опыты - не доказательство.
А что доказательство?
Comment 22 Andrey Rahmatullin 2007-06-17 22:47:35 MSD
(In reply to comment #21)
> А что доказательство?
Код либо статьи о коде.
Comment 23 Michael Shigorin 2007-06-19 00:33:22 MSD
2 wrar: проблема с юзабилити (в д.с. возможностью понять, оно там где-то сзади
доморгало или нет) действительно обостряется без sync.

2 rom_as: утверждение про вредность кэширования при работе со сменными
носителями действительно передуто.  Бывают разные угловые ситуации, от "три раза
переписанный один и тот же стометровый файл с правками" (не очень частая
ситуация, но с sync это труба) до "выдернул флэшку и убёг, а там ничего не
оказалось" (более частая, но отнюдь не полностью исключаемая sync).
Comment 24 Roman Savochenko 2007-06-20 12:23:43 MSD
(In reply to comment #23)
> 2 rom_as: утверждение про вредность кэширования при работе со сменными
> носителями действительно передуто.  Бывают разные угловые ситуации, 
от "три раза
> переписанный один и тот же стометровый файл с правками" (не очень 
частая
Лично я с таким ни разу не встречался, может по тому, что такого рода 
изменения делаю на стационарных носителях. Кроме того, за прозрачность и 
ясность механизма я такую цену готов заплатить.

> ситуация, но с sync это труба) до "выдернул флэшку и убёг, а там ничего 
не
> оказалось" (более частая, но отнюдь не полностью исключаемая sync).
Выдёргивал сразу после визуального завершения процесса записи с "sync" и 
ни разу такого не получал. Как нибудь устрою стресс тест на ALT2.4 в этом 
направлении. :)
Comment 25 Anton V. Boyarshinov 2007-07-03 11:36:23 MSD
Разные люди предпочитают разное поведение сменных носителей
Comment 26 Mikhail Gusarov 2008-07-03 10:20:30 MSD