12048 2007-06-15 16:31:41 +0400 опция sync в ядрах 2.6.х 2008-07-03 10:20:30 +0400 1 1 3 Distributions ALT Linux Desktop bugs snapshot all Linux CLOSED WONTFIX P2 normal --- 1 matiskyn boyarsh vsu wrar qa-sisyphus oldest_to_newest 51449 0 matiskyn 2007-06-15 16:31:41 +0400 Опция 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 для простого пользователя 51464 1 wrar 2007-06-16 15:47:21 +0400 Почему снижает? 51504 2 rom_as 2007-06-17 19:00:27 +0400 Потому что нет нормальной, простой и надёжной политики/механизма доступа к сменным носителям, понятной простому пользователю. В настоящей ситуации со сменными носителями даже у меня (пользователь Linux с пятилетним стажем) возникают проблемы. Похожая бага: 11981 51506 3 wrar 2007-06-17 19:11:35 +0400 (In reply to comment #2) > Потому что нет нормальной, простой и надёжной политики/механизма доступа > к сменным носителям, понятной простому пользователю. Это общие слова. По сути баги можете что-то сказать? 51509 4 rom_as 2007-06-17 19:42:16 +0400 (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 51510 5 wrar 2007-06-17 19:56:27 +0400 > Обсуждение здесь: > http://lists.altlinux.ru/pipermail/community/2006-March/176532.html Увидел только ерунду про "давайте откатим не знаю что на неработавший никогда вариант". Просьба конструктивно описать, что же именно вы хотите изменить. 51511 6 rom_as 2007-06-17 20:43:42 +0400 Ладно. Начну с того, что опция "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 для простого пользователя". 51512 7 wrar 2007-06-17 20:58:05 +0400 (In reply to comment #6) > Ладно. > Начну с того, что опция "sync" до версии ядра 2.6.13 работала следующим > образом: > - запись на носитель смонтированный с этой опцией происходила > инкрементально и фактически минуя дисковые буфера и кеши; > - благодаря этому, физический процесс записи на носитель полностью > визуально контролировался, т.е. окончание визуального процесса записи > гарантировало окончание физической записи и пользователь мог смело > выдёргивать носитель (для флоппи это вообще единственно верное и > возможное решение). Ссылку, пожалуйста. > Вывод: Кеширование/буферирование дисковых операций записи мало того, что > бесполезная так ещё и вредная операция. И от неё важно избавится для > съёмных носителей. Ерунда. > Съёмный носитель - носитель который подключается временно и операции с > которым должны выполняться непосредственно Нет. > Лично я сейчас не вижу правильного решения этой проблеммы, в виду её > технической не решенности. Её только можно сгладить за счёт > опции "flush". Поэтому и говорится о "снижении ценности altlinux для > простого пользователя". s/altlinux/linux/ 51513 8 rom_as 2007-06-17 21:06:57 +0400 (In reply to comment #7) > (In reply to comment #6) > > Ладно. > > Начну с того, что опция "sync" до версии ядра 2.6.13 работала следующим > > образом: > > - запись на носитель смонтированный с этой опцией происходила > > инкрементально и фактически минуя дисковые буфера и кеши; > > - благодаря этому, физический процесс записи на носитель полностью > > визуально контролировался, т.е. окончание визуального процесса записи > > гарантировало окончание физической записи и пользователь мог смело > > выдёргивать носитель (для флоппи это вообще единственно верное и > > возможное решение). > Ссылку, пожалуйста. Ссылку на что? > > Вывод: Кеширование/буферирование дисковых операций записи мало того, что > > бесполезная так ещё и вредная операция. И от неё важно избавится для > > съёмных носителей. > Ерунда. Обоснуйте. 51515 9 wrar 2007-06-17 21:14:13 +0400 (In reply to comment #8) > > Ссылку, пожалуйста. > Ссылку на что? На описанное вами поведение параметра sync в ядрах младше .12. > > Ерунда. > Обоснуйте. Скорость записи и скорость умирания носителя. 51516 10 rom_as 2007-06-17 21:29:30 +0400 (In reply to comment #9) > (In reply to comment #8) > > > Ссылку, пожалуйста. > > Ссылку на что? > На описанное вами поведение параметра sync в ядрах младше .12. В той ссылке, которую я Вам не случайно дал, я такое поведение описывал. Если Вас не затруднит то Вы легко его там найдёте. Если Вам лень, я лично для Вас проведу эти опыты на своём сервере ещё раз. > > > Ерунда. > > Обоснуйте. > Скорость записи и скорость умирания носителя. Не вижу связи. У меня с "sync", когда он правильно работал никто не умер. Это сейчас, в так называемом "исправленном" состоянии, по каждой записи перезаписываются сектора с FAT, что и тормозит его на порядки. Ещё раз повторяю, до 2.6.13 "sync" работал так как я описывал не заёлозивая сектора с FAT! 51517 11 wrar 2007-06-17 21:44:10 +0400 (In reply to comment #10) > > На описанное вами поведение параметра sync в ядрах младше .12. > В той ссылке, которую я Вам не случайно дал, я такое поведение описывал. > Если Вас не затруднит то Вы легко его там найдёте. Если Вам лень, я > лично для Вас проведу эти опыты на своём сервере ещё раз. [...] > Это сейчас, в так называемом "исправленном" состоянии, по каждой записи > перезаписываются сектора с FAT, что и тормозит его на порядки. Ещё раз > повторяю, до 2.6.13 "sync" работал так как я описывал не заёлозивая > сектора с FAT! У вас каша в голове. 51518 12 rom_as 2007-06-17 21:45:49 +0400 Вот выдержка из указанного мною треда: > 2.4.26 fat > С sync: 41 сек, и прогресс показывается до конца записи; > Без sync: 39 сек, сразу сливается в буфер и копирует SubFs; > Кстате заценил только что проблему работы без sync: > - копирую файл размером в 1М и вспоминаю что не засёк время; > - перехожу на панель с флопиком и удаляю копируемый файл; > - процесс удаления зависает до момента завершения копирования SubFs. По мне так очень наглядный пример. :) 51519 13 rom_as 2007-06-17 21:48:29 +0400 (In reply to comment #11) > (In reply to comment #10) > > > На описанное вами поведение параметра sync в ядрах младше .12. > > В той ссылке, которую я Вам не случайно дал, я такое поведение описывал. > > Если Вас не затруднит то Вы легко его там найдёте. Если Вам лень, я > > лично для Вас проведу эти опыты на своём сервере ещё раз. > [...] > > Это сейчас, в так называемом "исправленном" состоянии, по каждой записи > > перезаписываются сектора с FAT, что и тормозит его на порядки. Ещё раз > > повторяю, до 2.6.13 "sync" работал так как я описывал не заёлозивая > > сектора с FAT! > > У вас каша в голове. Главное что-бы с маслом. :) А что, собственно, не так? 51520 14 wrar 2007-06-17 21:54:34 +0400 (In reply to comment #13) > А что, собственно, не так? То у вас "раньше sync работал, вот линка, где написано, что раньше он не работал", то "раньше sync не обновлял fat по каждому чиху". 51521 15 rom_as 2007-06-17 22:03:28 +0400 (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" пишет медленно, прямо на диск минуя буфер. Визуализация процесса записи соответствует физической записи на носитель. Так понятно? 51522 16 wrar 2007-06-17 22:08:46 +0400 (In reply to comment #15) > Так понятно? Предположим. Непонятно, в чём проблема. 51523 17 rom_as 2007-06-17 22:14:13 +0400 (In reply to comment #16) > (In reply to comment #15) > > Так понятно? > Предположим. > Непонятно, в чём проблема. Проблема в том, что уже в 2.6.12 и сейчас "sync" работает не так как в 2.4.26. А именно: медленно пишет, елозит сектора с FAT по каждой записи. В 2.4.26 работало так как нужно: пишет мимо буфера и прямо на диск, визуализация соответствует физическому процессу записи, не елозит сектора с FAT. 51524 18 wrar 2007-06-17 22:18:46 +0400 (In reply to comment #17) > В 2.4.26 работало так как нужно: пишет мимо буфера и прямо на диск, Вы уверены? Линку. 51525 19 rom_as 2007-06-17 22:29:15 +0400 (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. По мне так очень наглядный пример. :) С уважением Роман! //=============================================================== Остальное можно в архиве треда проследить. 51526 20 wrar 2007-06-17 22:34:32 +0400 (In reply to comment #19) > > > В 2.4.26 работало так как нужно: пишет мимо буфера и прямо на диск, > > Вы уверены? Линку. > Оказывается это моё письмо в архив не попало. Не канает. Натурные опыты - не доказательство. 51527 21 rom_as 2007-06-17 22:41:05 +0400 (In reply to comment #20) > (In reply to comment #19) > > > > В 2.4.26 работало так как нужно: пишет мимо буфера и прямо на диск, > > > Вы уверены? Линку. > > Оказывается это моё письмо в архив не попало. > Не канает. Натурные опыты - не доказательство. А что доказательство? 51528 22 wrar 2007-06-17 22:47:35 +0400 (In reply to comment #21) > А что доказательство? Код либо статьи о коде. 51592 23 mike 2007-06-19 00:33:22 +0400 2 wrar: проблема с юзабилити (в д.с. возможностью понять, оно там где-то сзади доморгало или нет) действительно обостряется без sync. 2 rom_as: утверждение про вредность кэширования при работе со сменными носителями действительно передуто. Бывают разные угловые ситуации, от "три раза переписанный один и тот же стометровый файл с правками" (не очень частая ситуация, но с sync это труба) до "выдернул флэшку и убёг, а там ничего не оказалось" (более частая, но отнюдь не полностью исключаемая sync). 51701 24 rom_as 2007-06-20 12:23:43 +0400 (In reply to comment #23) > 2 rom_as: утверждение про вредность кэширования при работе со сменными > носителями действительно передуто. Бывают разные угловые ситуации, от "три раза > переписанный один и тот же стометровый файл с правками" (не очень частая Лично я с таким ни разу не встречался, может по тому, что такого рода изменения делаю на стационарных носителях. Кроме того, за прозрачность и ясность механизма я такую цену готов заплатить. > ситуация, но с sync это труба) до "выдернул флэшку и убёг, а там ничего не > оказалось" (более частая, но отнюдь не полностью исключаемая sync). Выдёргивал сразу после визуального завершения процесса записи с "sync" и ни разу такого не получал. Как нибудь устрою стресс тест на ALT2.4 в этом направлении. :) 52297 25 boyarsh 2007-07-03 11:36:23 +0400 Разные люди предпочитают разное поведение сменных носителей 73540 26 dottedmag 2008-07-03 10:20:30 +0400