forum.opennet.ru - "Релиз Linux-ядра 2.6.34" (71)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Релиз Linux-ядра 2.6.34"

Форумы Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Релиз Linux-ядра 2.6.34"		+/–
Сообщение от opennews (??) on 17-Май-10, 12:35
Линус Торвальдс представил (http://lkml.org/lkml/2010/5/16/89) релиз Linux ядра 2.6.34 (http://www.kernel.org/), в которое принято 10167 исправлений от 1305 разработчиков, размер патча - 39 Мб (добавлено 621 тыс. строк кода, удалено - 290 тыс. строк). Около 42% всех представленных в 2.6.34 изменений связаны с драйверами устройств, примерно 27% изменений связаны с обновлением кода специфичного для аппаратных архитектур, 14% связано с сетевым стеком, 7% - файловыми системами и 6% c внутренними подсистемами ядра. Основные новшества (http://kernelnewbies.org/Linux_2_6_34): - Дисковая подсистема, ввод/вывод и файловые системы - Интегрирован (http://www.opennet.me/opennews/art.shtml?num=25879) код файловой системы Ceph (http://ceph.newdream.net/), способной поддерживать работу хранилища объемом в несколько петабайт (1 Пб = 1024 Тб), распределенного по тысячам машин. Встроенные в Ceph механизмы репликации данных (данные разбиваются на блоки и несколько раз дублируются на р... URL: http://lkml.org/lkml/2010/5/16/89 Новость: http://www.opennet.me/opennews/art.shtml?num=26609
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Релиз Linux-ядра 2.6.34, fresco, 12:35 , 17-Май-10, (1) +7

Релиз Linux-ядра 2.6.34, User294, 16:17 , 17-Май-10, (28)

Релиз Linux-ядра 2.6.34, pavlinux, 19:41 , 17-Май-10, (34) –1
Релиз Linux-ядра 2.6.34, Iv946n, 23:46 , 17-Май-10, (40) +1

Релиз Linux-ядра 2.6.34, User294, 22:42 , 18-Май-10, (60) +2
Релиз Linux-ядра 2.6.34, stranger, 11:49 , 20-Май-10, (80)

Релиз Linux-ядра 2.6.34, iZEN, 13:00 , 17-Май-10, (2) –2

какие мы любознательные, под корягой, Andrey Mitrofanov, 13:14 , 17-Май-10, (3) +2

какие мы любознательные, под корягой, iZEN, 14:09 , 17-Май-10, (11) –3

какие мы любознательные, под корягой, Andrey Mitrofanov, 14:13 , 17-Май-10, (12) +4
какие мы любознательные, под корягой, Аноним, 17:08 , 17-Май-10, (30) –1
какие мы любознательные, под корягой, User294, 23:11 , 18-Май-10, (65)

какие мы любознательные, под корягой, iZEN, 02:41 , 19-Май-10, (67)

какие мы любознательные, под корягой, guest, 18:08 , 20-Май-10, (82)

какие мы любознательные, под корягой, iZEN, 11:47 , 21-Май-10, (83)

какие мы любознательные, под корягой, guest, 12:11 , 21-Май-10, (84)

какие мы любознательные, под корягой, iZEN, 17:21 , 21-Май-10, (85)

какие мы любознательные, под корягой, guest, 18:44 , 21-Май-10, (86)

Релиз Linux-ядра 2.6.34, User294, 17:12 , 17-Май-10, (32)

Релиз Linux-ядра 2.6.34, Аноним, 06:06 , 18-Май-10, (44)

Релиз Linux-ядра 2.6.34, User294, 22:46 , 18-Май-10, (61) –1

Релиз Linux-ядра 2.6.34, mnu, 20:55 , 19-Май-10, (79)

Релиз Linux-ядра 2.6.34, User294, 16:55 , 20-Май-10, (81)

Релиз Linux-ядра 2.6.34, mnu, 16:25 , 18-Май-10, (52) +2

Релиз Linux-ядра 2.6.34, iZEN, 18:10 , 18-Май-10, (57)

Релиз Linux-ядра 2.6.34, Аноним, 13:42 , 19-Май-10, (73)

Релиз Linux-ядра 2.6.34, mnu, 14:17 , 19-Май-10, (74) +1

Релиз Linux-ядра 2.6.34, iZEN, 17:52 , 18-Май-10, (55) +1

Релиз Linux-ядра 2.6.34, User294, 22:36 , 18-Май-10, (59)

Релиз Linux-ядра 2.6.34, iZEN, 02:31 , 19-Май-10, (66) +1
Релиз Linux-ядра 2.6.34, mnu, 14:29 , 19-Май-10, (75) +1

Релиз Linux-ядра 2.6.34, mnu, 14:31 , 19-Май-10, (76)

Релиз Linux-ядра 2.6.34, anonymous, 13:16 , 17-Май-10, (4)

Релиз Linux-ядра 2.6.34, Lain_13, 13:36 , 17-Май-10, (5)

Релиз Linux-ядра 2.6.34, anonymous, 13:41 , 17-Май-10, (6) +2

Релиз Linux-ядра 2.6.34, Анонимус_б8, 14:57 , 17-Май-10, (16) +2

Релиз Linux-ядра 2.6.34, aurved, 20:25 , 17-Май-10, (36) –1

Релиз Linux-ядра 2.6.34, VoDA, 14:58 , 17-Май-10, (17) +3

Релиз Linux-ядра 2.6.34, Аноним, 15:02 , 17-Май-10, (18) +2

Релиз Linux-ядра 2.6.34, anonymous, 15:52 , 17-Май-10, (26)

Релиз Linux-ядра 2.6.34, VoDA, 16:17 , 17-Май-10, (29) +1

Релиз Linux-ядра 2.6.34, Карбофос, 17:09 , 17-Май-10, (31)
Релиз Linux-ядра 2.6.34, aurved, 20:31 , 17-Май-10, (37)

Релиз Linux-ядра 2.6.34, Sokol, 21:38 , 17-Май-10, (38)
Релиз Linux-ядра 2.6.34, Аноним, 22:31 , 17-Май-10, (39)

Релиз Linux-ядра 2.6.34, Zenithar, 04:41 , 18-Май-10, (41)

Релиз Linux-ядра 2.6.34, Карбофос, 09:16 , 18-Май-10, (45)

Релиз Linux-ядра 2.6.34, Zenithar, 10:00 , 18-Май-10, (46) –5

Релиз Linux-ядра 2.6.34, Wormik, 17:27 , 18-Май-10, (54)
Релиз Linux-ядра 2.6.34, User294, 22:56 , 18-Май-10, (63) +2

Релиз Linux-ядра 2.6.34, Zenithar, 10:01 , 18-Май-10, (47)

Релиз Linux-ядра 2.6.34, Карбофос, 12:00 , 18-Май-10, (50)

Релиз Linux-ядра 2.6.34, User294, 23:06 , 18-Май-10, (64) –1

Релиз Linux-ядра 2.6.34, Frank, 10:05 , 19-Май-10, (70)

Релиз Linux-ядра 2.6.34, Frank, 10:06 , 19-Май-10, (71)

Релиз Linux-ядра 2.6.34, ононим, 18:27 , 17-Май-10, (33)

Релиз Linux-ядра 2.6.34, Аноним, 16:09 , 17-Май-10, (27)

Релиз Linux-ядра 2.6.34, DeadMustdie, 19:56 , 17-Май-10, (35)
Релиз Linux-ядра 2.6.34, Zenithar, 04:57 , 18-Май-10, (42)

Релиз Linux-ядра 2.6.34, pavlinux, 17:56 , 18-Май-10, (56)

Релиз Linux-ядра 2.6.34, Frank, 10:11 , 19-Май-10, (72)

Релиз Linux-ядра 2.6.34, pavlinux, 14:36 , 19-Май-10, (77)
Релиз Linux-ядра 2.6.34, pavlinux, 16:06 , 19-Май-10, (78)

Релиз Linux-ядра 2.6.34, zomg, 12:12 , 18-Май-10, (51)

Релиз Linux-ядра 2.6.34, Аноним, 16:29 , 18-Май-10, (53) +1
Релиз Linux-ядра 2.6.34, Карбофос, 19:43 , 18-Май-10, (58)
Релиз Linux-ядра 2.6.34, Алексей, 08:17 , 19-Май-10, (68)

Релиз Linux-ядра 2.6.34, бедный буратино, 14:31 , 17-Май-10, (13) +2

Релиз Linux-ядра 2.6.34, Zenithar, 05:11 , 18-Май-10, (43) –1

Релиз Linux-ядра 2.6.34, User294, 22:49 , 18-Май-10, (62)

Релиз Linux-ядра 2.6.34, xiff, 11:51 , 26-Май-10, (87)

Сообщения по теме [Сортировка по времени | RSS]

1. "Релиз Linux-ядра 2.6.34" +7 +/–

Сообщение от fresco (??) on 17-Май-10, 12:35

по btrfs действительно много коммитов. хорошо!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

28. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от User294 (ok) on 17-Май-10, 16:17

И вообще ченжлог - доставляет.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

34. "Релиз Linux-ядра 2.6.34" –1 +/–

Сообщение от pavlinux (ok) on 17-Май-10, 19:41

> ченжлог - доставляет.
Скажите, а Анальгин куда применять?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

40. "Релиз Linux-ядра 2.6.34" +1 +/–

Сообщение от Iv946n on 17-Май-10, 23:46

Эх жаль в Ubuntu LTS и CentOS новые не попало...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

60. "Релиз Linux-ядра 2.6.34" +2 +/–

Сообщение от User294 (ok) on 18-Май-10, 22:42

>Эх жаль в Ubuntu LTS и CentOS новые не попало...
Кхм, загнать только что вышедшее ядро в LTS дистр было бы весьма неумным решением. Из-за отсутствия времени на тесты и новизны ядра наверняка нарисовалось бы много вкусных грабель :).И вообще в LTS и прочих долгоподдерживаемых наивно ожидать свежак, они не для этого по определению, а?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

80. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от stranger (??) on 20-Май-10, 11:49

>Эх жаль в Ubuntu LTS и CentOS новые не попало...
В CentOS оно все попадет после того, как RH все сбекпортит. Если уже не сделала этого...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Релиз Linux-ядра 2.6.34" –2 +/–

Сообщение от iZEN (ok) on 17-Май-10, 13:00

LogFS работает по принципу Soft Updates из UFS2?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "какие мы любознательные, под корягой" +2 +/–

Сообщение от Andrey Mitrofanov on 17-Май-10, 13:14

>LogFS работает по принципу Soft Updates из UFS2?
""If a file system discussion goes on long enough, someone will bring up soft updates eventually, usually in the form of, "Duhhh, why are you Linux people so stupid? Just use soft updates, like BSD!" Generally, there will be no direct reply to this comment and the conversation will flow silently around it, like a stream around an inky black boulder.
[...]
Overall, soft updates is a sophisticated, insightful, clever idea - and an evolutionary dead end. Journaling and copy-on-write systems are easier to implement, require less special-purpose code, and demand far less of the programmer writing to the interface.""

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "какие мы любознательные, под корягой" –3 +/–

Сообщение от iZEN (ok) on 17-Май-10, 14:09

>[оверквотинг удален]
>up soft updates eventually, usually in the form of, "Duhhh, why
>are you Linux people so stupid? Just use soft updates, like
>BSD!" Generally, there will be no direct reply to this comment
>and the conversation will flow silently around it, like a stream
>around an inky black boulder.
>[...]
>Overall, soft updates is a sophisticated, insightful, clever idea - and an
>evolutionary dead end. Journaling and copy-on-write systems are easier to implement,
>require less special-purpose code, and demand far less of the programmer
>writing to the interface.""
Вот так вот. Просто. Без обиняков. "S U — это эволюционный тупик из-за того, что код труднопонимаем. Журналируемые и CoW системы реализовать легче.". © Неосиляторы.
:D

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "какие мы любознательные, под корягой" +4 +/–

Сообщение от Andrey Mitrofanov on 17-Май-10, 14:13

>Journaling and copy-on-write systems are easier to implement,
>из-за того, что код труднопонимаем".
Ну, не осилил по-чучмекски, так не осилил---
>© Неосиляторы.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

30. "какие мы любознательные, под корягой" –1 +/–

Сообщение от Аноним (??) on 17-Май-10, 17:08

просто у спонсоров не нашлось лишних денег ) бюджет штука узкая :D

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

65. "какие мы любознательные, под корягой" +/–

Сообщение от User294 (ok) on 18-Май-10, 23:11

>Вот так вот. Просто. Без обиняков. "S U — это эволюционный тупик
>из-за того, что код труднопонимаем. Журналируемые и CoW системы реализовать легче.".
Да, iZEN, извини, но какойнить btrfs и выглядит стройнее чем упомянутое тобой решение и по большинству параметров и фич имхо зарулит с отрывом. Мне кажется что это неприятная для некоторых морально, но технически вполне честная классификация.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

67. "какие мы любознательные, под корягой" +/–

Сообщение от iZEN (ok) on 19-Май-10, 02:41

>>Вот так вот. Просто. Без обиняков. "S U — это эволюционный тупик
>>из-за того, что код труднопонимаем. Журналируемые и CoW системы реализовать легче.".
>
>Да, iZEN, извини, но какойнить btrfs и выглядит стройнее чем упомянутое тобой
>решение и по большинству параметров и фич имхо зарулит с отрывом.
Странно, что ты даже не предлагаешь сравнить файловые системы разных поколений, а уже окончательно уверился в том, что недоделанная Btrfs уже готова к продакшену и готова заменить не только всё ещё находящуюся в опытной эксплуатации у хомячков Ext4, но и промышленную UFS2.

>Мне кажется что это неприятная для некоторых морально, но технически вполне
>честная классификация.
Классификация "чего"? Несостоятельности и невозможности понять ортогональные вещи, которые уже с успехом совмещены в экспериментальной реализации "UFS2+SUJ"?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

82. "какие мы любознательные, под корягой" +/–

Сообщение от guest (??) on 20-Май-10, 18:08

>Классификация "чего"? Несостоятельности и невозможности понять ортогональные вещи, которые уже с успехом
>совмещены в экспериментальной реализации "UFS2+SUJ"?
помоему говорить о каком либо успехе SU (+J не трогаю) как-то странно. Технологии уже 10лет.
За эти 10лет МакКузик так и не осилил привернуть к soft updates ни вменяемую диагностику, ни рантайм статистику, ни нормальное включение/выключение, вообщем перечислять можно долго.
И как итог хорошая, в чемто красивая, и полезная технология убита примером кривоватой реализации.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

83. "какие мы любознательные, под корягой" +/–

Сообщение от iZEN (ok) on 21-Май-10, 11:47

>>Классификация "чего"? Несостоятельности и невозможности понять ортогональные вещи, которые уже с успехом
>>совмещены в экспериментальной реализации "UFS2+SUJ"?
>
>помоему говорить о каком либо успехе SU (+J не трогаю) как-то странно.
>Технологии уже 10лет.
>За эти 10лет МакКузик так и не осилил привернуть к soft updates
>ни вменяемую диагностику, ни рантайм статистику, ни нормальное включение/выключение, вообщем перечислять
>можно долго.
Изучите матчасть, прежде чем такое говорить. Включение/выключение SU нормально выполняется через tunefs(8). Рантайм статистика выводится gstat(8).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

84. "какие мы любознательные, под корягой" +/–

Сообщение от guest (??) on 21-Май-10, 12:11

>Изучите матчасть, прежде чем такое говорить. Включение/выключение SU нормально выполняется через tunefs(8).
Цитирую:
The tunefs utility cannot be run on an active file system.  To change an active file system, it must be downgraded to read-only or unmounted.
Если по вашему, это и есть нормальный и удобный механизм вкл/выкл, то наши мнения об удобстве кардинально не совпадают. Давайте таким же макаром файрвол сделаем - чтоб добавить/удалить правило надо будет передернуть интерфейс.
>Рантайм статистика выводится gstat(8).
Старый я наверное стал и слепой. Ткните меня носом пожалуйста где в выводе gstat список задержанных softupdates микроопераций с их таймаутами (про то что хотелось бы еще видеть и зависимости я молчу).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

85. "какие мы любознательные, под корягой" +/–

Сообщение от iZEN (ok) on 21-Май-10, 17:21

>>Изучите матчасть, прежде чем такое говорить. Включение/выключение SU нормально выполняется через tunefs(8).
>
>Цитирую:
>The tunefs utility cannot be run on an active file system.
>To change an active file system, it must be downgraded to
>read-only or unmounted.
>Если по вашему, это и есть нормальный и удобный механизм вкл/выкл, то
>наши мнения об удобстве кардинально не совпадают. Давайте таким же макаром
>файрвол сделаем - чтоб добавить/удалить правило надо будет передернуть интерфейс.
А в какой ещё ФС журналирование (к примеру) можно отключить на лету без отмонтирования? Я такой не знаю, а вы?
>>Рантайм статистика выводится gstat(8).
>
>Старый я наверное стал и слепой. Ткните меня носом пожалуйста где в
>выводе gstat список задержанных softupdates микроопераций с их таймаутами (про то
>что хотелось бы еще видеть и зависимости я молчу).
gstat — универсальный инструмент по сбору статистики с GEOM. На файловые системы ему (и пользователям), в общем-то, наплевать. Важна реакция на чтение/запись данных и счётчики производительности дисковой подсистемы (GEOM), а не то, как работает с данными ФС на своём уровне. Возможно, последнее интересно самим разработчикам, но у них для этого есть, я надеюсь, специальные отладочные инструменты.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

86. "какие мы любознательные, под корягой" +/–

Сообщение от guest (??) on 21-Май-10, 18:44

Уважаемый, ну какая связь между softupdates и geom???
Меня, несколько удивила ваша фраза несколькими постами выше:
> которые уже с успехом совмещены в экспериментальной реализации "UFS2+SUJ"?
Если о продакшен качестве ufs2 я с вами полностью согласен, то на счет softupdates нет.
>А в какой ещё ФС журналирование (к примеру) можно отключить на лету
>без отмонтирования? Я такой не знаю, а вы?
Нет, не знаю.
softupdates в отличии от журнала требует на диске ровно 1 бит.
>gstat — универсальный инструмент по сбору статистики с GEOM. На файловые системы
>ему (и пользователям), в общем-то, наплевать. Важна реакция на чтение/запись данных
Говорите за себя. Я вот например хотел бы знать, что после sync (на который кстати softupdates кладет болт) мои данные записаны на диск.
>и счётчики производительности дисковой подсистемы (GEOM), а не то, как работает
>с данными ФС на своём уровне. Возможно, последнее интересно самим разработчикам,
>но у них для этого есть, я надеюсь, специальные отладочные инструменты.
В том то и проблема, что не только пользователи но и разработчики были посланы аффтором этого чуда далеко и на долго, с воплями "я бог, там все работает, и никого править не пущу".
Ну и как результат, журналирование метаданных зарулило и softupdates уже вряди выйдет за пределы *BSD. мне жаль.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

32. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от User294 (ok) on 17-Май-10, 17:12

iZEN ты забыл сказать что весь твой UFS2 это - "как бы нам сделать из окаменевшего говна не совсем говно с минимальными изменениями кода поскольку большие делать все-равно некому". В итоге к ископаемому архаику прикрутили сомнительных костылей. Офигенная, блин, эволюция. ИМХО Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

44. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Аноним (??) on 18-Май-10, 06:06

Вы сейчас глубоко задели всех пользователей BSD систем, которые на "костыльных" UFS держат кучи нагруженных серверов по всему миру, несмотря на свою ущербность в Ваших глазах

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

61. "Релиз Linux-ядра 2.6.34" –1 +/–

Сообщение от User294 (ok) on 18-Май-10, 22:46

А чего такого оскорбительного в констатации фактов? Все познается в сравнении. И UFS всего лишь ископаемое. С весьма древней организацией и потому понятно какое по производительности. На лично мое имхо такие дизайны свое отжили, по большому счету. Вон в ext4 закопали останки чего-то похожего по смыслу, куда ему и дорога :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

79. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от mnu (??) on 19-Май-10, 20:55

>UFS всего лишь ископаемое. С весьма древней организацией и потому понятно какое по производительности.
а ты его тестил? :-) или так, чисто газифицируешь?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

81. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от User294 (ok) on 20-Май-10, 16:55

>а ты его тестил? :-)
Я не интересуюсь тестами ископаемых. Даже с костылями и подпорками. Это скучно и неперспективно.
>или так, чисто газифицируешь?
Так, чисто на архитектуру посмотрел слегка. Не понял нахрен оно вот такое. Вы поняли? Считаете это отличным инженерным решением? Юзайте наздоровье. А у меня ощущение вида "я его слепила из того что было".

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

52. "Релиз Linux-ядра 2.6.34" +2 +/–

Сообщение от mnu (??) on 18-Май-10, 16:25

> Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим.
Хм. Единственная production-ready (tm) FS на *BSD, построенная на технологии CoW - это ZFS, жрущая кучу RAM и дико тормозная при 95%+ занятости места на zpool'ах. Из не-production-ready есть HAMMER, по возможностям в некоторых местах превосходящий Btrfs, а в некоторых (сжатие, например) - всё ещё ей уступающий. Но HAMMER пока ещё не настолько стабилен, как UFS. Памяти жрёт меньше, чем ZFS, это да. Отжирает только в момент reblocking'а. Ни HAMMER, ни ZFS простыми не назовёшь. Не назовешь простой так же и XFS с reiserfs (которые в FreeBSD read-only).
При использовании UFS + SUJ при более чем приемлемом быстордействии Вы сохраните оперативную память. При использовании async UFS + geom_journal Вы жертвуете ~1Gb под журнал и имеете производительность, соизмеримую с любой развитой journalled FS (с теми же ограничениями). В обоих случаях Вы не рискуете целостностью Ваших данных, Вам практически наплевать на фрагментацию (в отличии от ZFS) и RAM'ы кушается не много.
А UFS2 нужен в основном для ОЧЕНЬ больших (>226Tb) FS да для всяких хитрых ACL... Ну, ускоряет немного благодаря delayed inode allocation, да, но ето не особо важно. Команда DragonFLyBSD вообще наплевала на UFS2, резонно решив, что лучше потратить время на стабилизацию HAMMER'а.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

57. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от iZEN (ok) on 18-Май-10, 18:10

>> Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим.
>
>Хм. Единственная production-ready (tm) FS на *BSD, построенная на технологии CoW -
>это ZFS, жрущая кучу RAM и дико тормозная при 95%+ занятости
>места на zpool'ах.
Про "кучу" RAM и тормоза при 95% занятости можно подробнее?
На днях копировал каталог с музыкой (~120ГБ) с ZFS (стационарный винчестер, SATA-2) на UFS2 (мобильный винчестер, SATA-2). После некоторого момента отожралось 100% RAM и графический пользовательский интерфейс перестал реагировать на кнопки мыши, тем не менее в фоне команда cp копировала файлы и таки закончила это дело. И, да, на ZFS включен prefetch — возможно это как-то повлияло на процесс копирования.
>А UFS2 нужен в основном для ОЧЕНЬ больших (>226Tb) FS да для всяких хитрых ACL...
Всегда считал, что предельный физический размер тома с UFS2 — 2ТБ вследствие ограничений разрядности некоторых value-типов в исходном коде FFS.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

73. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Аноним (??) on 19-Май-10, 13:42

mnu@RELENG_8_0:~> dd if=/dev/zero of=/tmp/gvirstor.dd bs=1m oseek=1999 count=1
1+0 records in
1+0 records out
1048576 bytes transferred in 0.003561 secs (294459461 bytes/sec)
mnu@RELENG_8_0:~> ll -sh /tmp/gvirstor.dd
1072 -rw-r--r--  1 mnu wheel   2,0G 19 тра 12:34 /tmp/gvirstor.dd
mnu@RELENG_8_0:~> s mdconfig -a -f !$ -u 12
s mdconfig -a -f /tmp/gvirstor.dd -u 12
mnu@RELENG_8_0:~> s gvirstor label -v -s 4Tb virtest /dev/md12
Total virtual chunks: 1048576 (4 MB each), 4194304 MB total virtual size.
Clearing metadata on /dev/md12.
Writing allocation table to /dev/md12... (8 MB, 2 chunks)
Storing metadata on /dev/md12 (500 chunks) (4 reserved) Done.
mnu@RELENG_8_0:~> diskinfo -v /dev/virstor/virtest
/dev/virstor/virtest
        512             # sectorsize
        4398046511104   # mediasize in bytes (4.0T)
        8589934592      # mediasize in sectors
mnu@RELENG_8_0:~> s newfs -O2 !$
s newfs -O2 /dev/virstor/virtest
/dev/virstor/virtest: 4194304.0MB (8589934592 sectors) block size 16384, fragment size 2048
        using 22825 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144,
6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424, 12419776,
.....
etc etc
As for ZFS slowdown, try to download some gigabytes of torrents in parallel to it, especially when zpool is nearly full.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

74. "Релиз Linux-ядра 2.6.34" +1 +/–

Сообщение от mnu (??) on 19-Май-10, 14:17

after adding some more 8Mb-chunked (yeah i should make chunks smaller, but who cares) MD's to geom_virstor (so newfs can proceed):
mnu@RELENG_8_0:~> s mount /dev/virstor/virtest /mnt/tmp
mnu@RELENG_8_0:~> df !$
df /mnt/tmp
Filesystem           1K-blocks  Used      Avail Capacity  Mounted on
/dev/virstor/virtest 4159842858    4 3827055426     0%    /mnt/tmp
mnu@RELENG_8_0:~> df -h /mnt/tmp
Filesystem              Size    Used   Avail Capacity  Mounted on
/dev/virstor/virtest    3.9T    4.0K    3.6T     0%    /mnt/tmp
mnu@RELENG_8_0:~> gvirstor status
           Name            Status  Components
virstor/virtest  6% physical free  md12
                                   md13
                                   md14
                                   md15
                                   md16
                                   md17
                                   md18
                                   md19
                                   md20
                                   md21
                                   md22
                                   md23
                                   md24
mnu@RELENG_8_0:~> ll -s /tmp/gvirstor.dd /mnt/big/gvirstor* | awksum # space really taken on disks by sparse MDs
1529120
mnu@RELENG_8_0:~> gvirstor list | grep Mediasize | awk '{s += $2} END {print s/1024}'
4395319296
mnu@RELENG_8_0:~> s umount /mnt/tmp
mnu@RELENG_8_0:~> s newfs -O1 /dev/virstor/virtest
/dev/virstor/virtest: 4194304.0MB (8589934592 sectors) block size 16384, fragment size 2048
        using 22834 cylinder groups of 183.69MB, 11756 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
32, 376224, 752416, 1128608, 1504800, 1880992, 2257184, 2633376, 3009568, 3385760,
...
etc etc (there is no delayed inode allocation in UFS1, therefore newfs works MUCH slower this time)
So 4Tb virtual storage is OK for UFS1 too.
p.s. ZFS is used w/o prefetch here, as i do not have 4Gb+ RAM, and benchmarks showed it is faster w/o prefetch.
p.p.s. Another ZFS slowdown (full-blown hard kernel hang for upto 10 sec) will be experienced by "zfs compression=on" users - kernel will hang while zlib compresses data, which is then sent to ZFS. Only then kernel will unhang and continue.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

55. "Релиз Linux-ядра 2.6.34" +1 +/–

Сообщение от iZEN (ok) on 18-Май-10, 17:52

>iZEN ты забыл сказать что весь твой UFS2 это - "как бы
>нам сделать из окаменевшего говна не совсем говно с минимальными изменениями
>кода поскольку большие делать все-равно некому". В итоге к ископаемому архаику
>прикрутили сомнительных костылей. Офигенная, блин, эволюция. ИМХО Copy-on-write зарулит нафиг все
>эти потуги. Хорошие вещи должны быть простыми и не костыльныим.
То же самое происходило: Ext2 > Ext3 > Ext4. Сюрприз? Вот только ни в одной из них поддержки онлайновых снапшотов нету и нельзя делать проверку структур (fsck) на смонтированной ФС...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

59. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от User294 (ok) on 18-Май-10, 22:36

> Вот только ни в одной из них поддержки онлайновых снапшотов нету
Что логично, т.к. LVM есть. Зачем городить повторный функционал в ФС? В случае CoW и подобных по смыслу ФС снапшоты имеют некий физический смысл, являясь по сути свойством-фичой дизайна ФС и там оно осмысленно. А в простой ФС во первых тупо делать то же что уже реализовано а во вторых - общая эффективность создания снапшотов в классической ФС - сами понимате какая. А никакая, блин.
> нельзя делать проверку структур (fsck) на смонтированной ФС...
...что для журналируемой ФС не слишком то актуально ;)
А вот на экстенты в UFS2 как я понимаю так и не перешли, да? А то разница между ext3 и 4 в ряде случаев просто вызывает отпад челюсти.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

66. "Релиз Linux-ядра 2.6.34" +1 +/–

Сообщение от iZEN (ok) on 19-Май-10, 02:31

>> Вот только ни в одной из них поддержки онлайновых снапшотов нету
>
>Что логично, т.к. LVM есть. Зачем городить повторный функционал в ФС? В
>случае CoW и подобных по смыслу ФС снапшоты имеют некий физический
>смысл, являясь по сути свойством-фичой дизайна ФС и там оно осмысленно.
>А в простой ФС во первых тупо делать то же что
>уже реализовано а во вторых - общая эффективность создания снапшотов в
>классической ФС - сами понимате какая. А никакая, блин.
Для UFS2 и ZFS время создания снапшотов — мгновенное. К тому же, LVM, в отличие от ZFS, не поддерживает инкрементные снимки и клоны.
>> нельзя делать проверку структур (fsck) на смонтированной ФС...
>
>...что для журналируемой ФС не слишком то актуально ;)
Ну, да. Лучше подождать минуту-другую, пока монтируемая ФС проверится, чем двадцать минут насиловать смонтированную рабочую ФС.
>А вот на экстенты в UFS2 как я понимаю так и не
>перешли, да? А то разница между ext3 и 4 в ряде
>случаев просто вызывает отпад челюсти.
Нет, экстенты в UFS2 ещё не реализовали, есть только необходимые структуры для этого. Зато в UFS2 идёт адресация на уровне фрагментов блоков (от 2 до 16 кбайт), чем экономится пространство под файлы и практически нету разбросанных по всему диску полупустых блоков с хвостами файлов, как в случае с Ext2/3. У Ext4 какой минимальный размер блока?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

75. "Релиз Linux-ядра 2.6.34" +1 +/–

Сообщение от mnu (??) on 19-Май-10, 14:29

>А вот на экстенты в UFS2 как я понимаю так и не перешли, да?
Вы понимаете не правильно.
http://www.freebsd.org/cgi/man.cgi?query=newfs&apropos=0
У UFS2 - переменный размер блока + частичная поддержка екстентов
(для хранения больших файлов + для атрибутов, AFAIK).
>[оверквотинг удален]
>     produce poor results.
>  -d max-extent-size
>     The file system may choose to store large files using extents.
>     This parameter specifies the largest extent size that may be
>     used.  It is presently limited to its default value which is 16
>     times the file system blocksize.
>  -f frag-size
>     The fragment size of the file system in bytes.  It must be a
>     power of two ranging in value between blocksize/8 and blocksize.
>     The default is 2048 bytes.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

76. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от mnu (??) on 19-Май-10, 14:31

гррр, съело цитату.
>  -b block-size
>         The block size of the file system, in bytes.  It must be a power
>         of 2.  The default size is 16384 bytes, and the smallest allow-
>         able size is 4096 bytes.  The optimal block:fragment ratio is
>         8:1.  Other ratios are possible, but are not recommended, and may
>         produce poor results.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от anonymous (??) on 17-Май-10, 13:16

Позорный баг с iowait так и не поправили? Все просираем десктопы?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Lain_13 on 17-Май-10, 13:36

На десктопах на него нарываются единицы. Я его, например, вообще в дикой природе не встречал ещё.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Релиз Linux-ядра 2.6.34" +2 +/–

Сообщение от anonymous (??) on 17-Май-10, 13:41

Щаз, единицы, километровые тикеты на kernel.org и launchpad говорят совершенно о другом.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "Релиз Linux-ядра 2.6.34" +2 +/–

Сообщение от Анонимус_б8 on 17-Май-10, 14:57

Нет никакого ядра (ц) НеО

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

36. "Релиз Linux-ядра 2.6.34" –1 +/–

Сообщение от aurved on 17-Май-10, 20:25

очень даже многие на него нарываются, вот в старых ядрах 2.6.18 (в RHEL например) этого не бывает, насколько я помню. И ведь так до сих пор эту хрень и не поправили. Хотя действительно об этом пишется очень много.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "Релиз Linux-ядра 2.6.34" +3 +/–

Сообщение от VoDA (ok) on 17-Май-10, 14:58

а как воспроизвести баг? или ссылка на тикет launchpad

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "Релиз Linux-ядра 2.6.34" +2 +/–

Сообщение от Аноним (??) on 17-Май-10, 15:02

+1. что за баг такой? :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

26. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от anonymous (??) on 17-Май-10, 15:52

Аналитики с ЛОРа подсказывают, что https://bugzilla.kernel.org/show_bug.cgi?id=12309 . Но я этот баг в первый раз в глаза вижу, такой нигде на моих системах не попадался.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

29. "Релиз Linux-ядра 2.6.34" +1 +/–

Сообщение от VoDA (ok) on 17-Май-10, 16:17

да, есть такая гнусная бага. это когда копируешь файлы с флехи на винт и мыша начинает дергаться. Я списывал на не-тот IO scheduler / типа на другом было бы получше, но тюнить влом - проще скопировать флеху, а затем посмотреть фильм.
Однозадачный linux получается ;)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

31. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Карбофос (ok) on 17-Май-10, 17:09

может мышь начинает дергаться от того, что винт уж больно шибко трещит? :)
такое пока не встречал, но полагаю, это специфично для каких-то конкретных чипсетов.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

37. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от aurved on 17-Май-10, 20:31

мышь конечно не приятно что дергается и отзывчивости нету, но вот когда при большой, лучше скажем так -- при приличной нагрузке на диск комп работает так, как будто ему лет так 10-12, а то 15, вот это напрягает. Причем ни в винде, ни во фрюхе такого не наблюдается при той же нагрузке. Первым это заметил чувак, какой-то известный в мире линукс, заметил он это именно на серверах (а не десктопах) из-за высокой загруженности системы при приличном дисковом IO. Причем раньше как от писал такого на этом же железе типа не было.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

38. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Sokol (??) on 17-Май-10, 21:38

Подтверждаю, сам нарывался на этот баг. Проявляется на некоторых чипсетах, скорее это даже зависит от контроллера ввода-вывода. Воспроизвести не сложно, запустить локальное копирование, сколь нибудь большого файла 3-4 Гб, а лучше нескольких. Тормоза будут не детские, причем они именно в виде freeze, у меня например на одном из сереров БД, тупо вставали все потоки чтения :(

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

39. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Аноним (??) on 17-Май-10, 22:31

Было на старом ПК с чипсетом VIA. Владелец удалил разделы с Linux очень быстро.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

41. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Zenithar on 18-Май-10, 04:41

У меня было год назад. Пробовал на компьютере мужа сестры Sabayon Linux 4. Муж Линукс не любит. Потом он заявил, что "А испробуем мы твой Линукс!", подключил PSP, и начал копировать на него большой файл. Несмотря на то, что определилось и подключилось, копировалось страшно медленно, а затем стало на 98-м проценте. А все потому, что я не оставлял систему однозадачной, как предлагается выше, а делал вещи, и делал много. Не знаю, какая там была файловая система, но файлик из виндовса удаляться не захотел (в винде при копироании сть компьютер зависает, или при доступе, с удалением потом проблемы). Я хоть и знал решение, но сделать не дали. Обвинили в том, что я принес домой глючный Линукс.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

45. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Карбофос (ok) on 18-Май-10, 09:16

в таком случае я выдаю оппоненту знамя в руки и вешаю барабан на шею. мой агрумент - линукс порой требует настройки, а уже настроенная система будет работать до отказа оборудования. да и безвирусный вариант системы гораздо спокойнее. :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

46. "Релиз Linux-ядра 2.6.34" –5 +/–

Сообщение от Zenithar on 18-Май-10, 10:00

Это не Линукс требует настройки, а Убунту требет нстройки. А вся настройка Линукса - это сменить воллпейпер, установить драйвер видеокарты, установить кодеки, и сменить кусор мыши

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

54. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Wormik (??) on 18-Май-10, 17:27

Это почему ещё? Да программок доставить надо и всё... Но намного больше, чем ты говоришь.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

63. "Релиз Linux-ядра 2.6.34" +2 +/–

Сообщение от User294 (ok) on 18-Май-10, 22:56

Чем убунта отличается от остальных линухов? А ничем, кроме того что ты ее не любишь. Может хватит уже столь тупо и толсто троллить то, Zenithar?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

47. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Zenithar on 18-Май-10, 10:01

Где ты был так долго? Возвращайся на сайт :-)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

50. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Карбофос (ok) on 18-Май-10, 12:00

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

64. "Релиз Linux-ядра 2.6.34" –1 +/–

Сообщение от User294 (ok) on 18-Май-10, 23:06

>А все потому, что я не оставлял систему однозадачной, как предлагается выше,
Ты опух, человек? Времена однозадачных систем были в эпоху MSDOS и безвозвратно закончились. А кто не отпустил ручник - тот пролетает. Исключение: если вы фирма Эппл и выпускаете ифон - то у вас есть шансы промыть мозг вашим хомячкам. В противном случае вас ждет эпик фэйл с таким подходом к делу. Что вы и получили. Кстати, заслуженно вполне. Баги мочить надо а не строить юзера что ты, дескать, должен как в досе, а потом еще и напильником, блаблабла.
>Обвинили в том, что я принес домой глючный Линукс.
Ну так ты именно это и сделал, баклан - если система обосралась при юзере, значит уж обосралась. Нормальным пользователям не впилось неделю с бубном прыгать. Им работать надо. Поэтому нормальный подход - передавить такие баги в системе, а не втирать ересь про однозадачные режимы. А так - обсираки бывают везде, но их процент у гентуобразных почему-то сильно выше чем у остальных. Всего лишь наблюдение...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

70. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Frank (??) on 19-Май-10, 10:05

> да, есть такая гнусная бага. это когда копируешь файлы с флехи на винт и мыша начинает дергаться.
Такая "бага" есть у меня на одной из двух десятков рабочих машинок, причём баг сей проявляется все зависимости от оси, и на богомерзкой винХР тоже. Это аппаратно-зависимый баг криворуких мамкостроителей.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

71. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Frank (??) on 19-Май-10, 10:06

s/все/вне/

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

33. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от ононим on 17-Май-10, 18:27

сам на себе такой баг испытывал, когда был nvidia чипсет nforce4 (со встроенной видео карточкой 6150). если копировать файлы более 4 гигов, то начинались просто жуткие тормоза как в винде обычно бывает. мышь дергается, окна сворачиваются, разворачиваются по 10 секунд и тд. когда же копирование заканчивалось, то тормоза прекращались.
потом перешел на amd/ati чипсеты и больше это проблема меня не мучала.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Аноним (??) on 17-Май-10, 16:09

> а как воспроизвести баг? или ссылка на тикет launchpad
Например, у меня при dd if=/dev/zero of=~/file bs=1000000 раз в несколько секунд всё подвисает на 1-2 сек.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

35. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от DeadMustdie (??) on 17-Май-10, 19:56

>Например, у меня при dd if=/dev/zero of=~/file bs=1000000 раз в несколько секунд
>всё подвисает на 1-2 сек.
Не наблюдаю.
# uname -a
Linux wookie 2.6.26-2-686 #1 SMP Tue Mar 9 17:35:51 UTC 2010 i686 GNU/Linux
# smartctl -a /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model:     WDC WD6400AAKS-22A7B2
Serial Number:    WD-WCASY4446571
Firmware Version: 01.03B01
User Capacity:    640 133 946 880 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Mon May 17 19:55:55 2010 MSD
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

42. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Zenithar on 18-Май-10, 04:57

>> а как воспроизвести баг? или ссылка на тикет launchpad
>
>Например, у меня при dd if=/dev/zero of=~/file bs=1000000 раз в несколько секунд
>всё подвисает на 1-2 сек.
Наблюдаю то эе самое с Интел. Я думал, так везде. Думал, процессор нули генериует в мегабайтных количестах с большим трудом. Попробовал сейчас с чипсетом AMD... Не тормозит! Я с ним вообще год, и в последние 2 месяца переезжаю на новых жесткий диск. Копирую и удаляю огромные объемы данных, и архивирую. Никаких тех самых тормзов, что я видел с Sabayon! Да и с Интелом спокойно прошло cp -ax 120-гигабайтного раздела, в системе с с ядром 2.6.28.10.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

56. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от pavlinux (ok) on 18-Май-10, 17:56

> Я с ним вообще год, и в последние 2 месяца переезжаю на новых жесткий диск.
> Копирую и удаляю огромные объемы данных, и архивирую.
А в процессе копирования полазай по инету, погляди Ютюбу, погяди mplayer,
ОпОфис, в Dia нарисуй план квартиры обычными прямоугольниками, закарась их,
Unigine Heaven погоняй, gtkperf на 1000 повторов.
Ну Што?! Ещё не тормозит? :)
> Да и с Интелом спокойно прошло cp -ax 120-гигабайтного раздела, в системе с с ядром 2.6.28.10.
mount -o remount,sync,atime,diratime,norelatime,barrier /
и
cp -ax ....


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

72. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Frank (??) on 19-Май-10, 10:11

>> Я с ним вообще год, и в последние 2 месяца переезжаю на новых жесткий диск.
>> Копирую и удаляю огромные объемы данных, и архивирую.
>
>А в процессе копирования полазай по инету, погляди Ютюбу, погяди mplayer,
>ОпОфис, в Dia нарисуй план квартиры обычными прямоугольниками, закарась их,
>Unigine Heaven погоняй, gtkperf на 1000 повторов.
>
>Ну Што?! Ещё не тормозит? :)
Нет, не тормозит! При этом ещё и BOINC крутится, одновременно две задачки щёлкая. Ах, да, ютуб не смотрю, ибо принципиально не имею дел с явой, моно и флешем.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

77. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от pavlinux (ok) on 19-Май-10, 14:36

>[оверквотинг удален]
>>
>>А в процессе копирования полазай по инету, погляди Ютюбу, погяди mplayer,
>>ОпОфис, в Dia нарисуй план квартиры обычными прямоугольниками, закарась их,
>>Unigine Heaven погоняй, gtkperf на 1000 повторов.
>>
>>Ну Што?! Ещё не тормозит? :)
>
>Нет, не тормозит! При этом ещё и BOINC крутится, одновременно две задачки
>щёлкая. Ах, да, ютуб не смотрю, ибо принципиально не имею дел
>с явой, моно и флешем.
Планировщик ввода/вывода надо нагружать, а не планировщик задач.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

78. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от pavlinux (ok) on 19-Май-10, 16:06

>[оверквотинг удален]
>>
>>А в процессе копирования полазай по инету, погляди Ютюбу, погяди mplayer,
>>ОпОфис, в Dia нарисуй план квартиры обычными прямоугольниками, закарась их,
>>Unigine Heaven погоняй, gtkperf на 1000 повторов.
>>
>>Ну Што?! Ещё не тормозит? :)
>
>Нет, не тормозит! При этом ещё и BOINC крутится, одновременно две задачки
>щёлкая. Ах, да, ютуб не смотрю, ибо принципиально не имею дел
>с явой, моно и флешем.
Запусти на одной консоли
# dd if=/dev/zero of=BIGFILE count=100000000 bs=1k
на другой
# sar -P ALL 1
И дай глянуть, измерения через минуту.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

51. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от zomg on 18-Май-10, 12:12

У меня на домашнем компе есть похожий баг, начался с ядра ~ 2.6.28. Когда копирую больше гига на флешку за раз, не важно одним файлом или многими, скорость копирования со временем падает до позорных ~ 100 КБ/с, и копирование продолжается вечность. Первые пару минут скорость держится на уровне нормальных 10 - 15 МБ/с. Перепробовал несколько флешек, три себя ведут именно так. Одна только флешка работает нормально -- это скоростная Corsair Voyager GT 8 GB. Пишет ~ 22 МБ/с стабильно. Система -- Intel Pentium 4.
Баг -- просто жесть. Меня бесит уже года полтора.
Неужели никто из разработчиков ядра никогда его не ловил?? X-|

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

53. "Релиз Linux-ядра 2.6.34" +1 +/–

Сообщение от Аноним (??) on 18-Май-10, 16:29

А зарепортить не пробовал? Хотя бы в багтрекер своего дистрибутива.. Чем ждать, что кто-то еще зарепортит и исправит проблему, возникающую у тебя o_O

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

58. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Карбофос (ok) on 18-Май-10, 19:43

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

68. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от Алексей (??) on 19-Май-10, 08:17

Вы описываете совершенно другой баг (в USB подсистеме). Причем этот баг вроде исправлен в 2.6.32 (или даже чуть ранее).
У меня тоже есть "скоростная" флешка Corsair Voyager GT 16 GB и при работе в Ubuntu 8.04 (ядро 2.6.24) наблюдаю аналогичные тормоза при записи на неё. Со скоростью чтения данных с флешки проблем нет. Пробовал тестировать с LiveCD под ядром 2.6.32 - проблема полностью решена, флешка показывает свою максимальную скорость записи.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Релиз Linux-ядра 2.6.34" +2 +/–

Сообщение от бедный буратино on 17-Май-10, 14:31

lzma в squashfs наконец-то!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

43. "Релиз Linux-ядра 2.6.34" –1 +/–

Сообщение от Zenithar on 18-Май-10, 05:11

>lzma в squashfs наконец-то!
Если что, то вседа можно было сделать самому. Просто когда squashfs вошла в ядро версии 2.6.28, она как раз вошла с о ограничениями: нет lzma. Тем не менее, многие дистрибутивы, включая Бубен и Sabayon, давно используют образы squashfs на своих LiveCD. Не удивлюсь, если сжатие в них - lzma

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

62. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от User294 (ok) on 18-Май-10, 22:49

>Если что, то вседа можно было сделать самому.
Бесспорно, можно все велосипеды переизобрести заново. Только неэффективно нифига.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

87. "Релиз Linux-ядра 2.6.34" +/–

Сообщение от xiff on 26-Май-10, 11:51

Рано обрадовались. Монтирование squashfs пожатых lzma из коробки пока не работает.
Интегрирована лишь часть патчей! Остальное, к сожалению, опять нужно патчить руками.
http://forum.kernelnewbies.org/read.php?4,1596

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Релиз Linux-ядра 2.6.34"		+7 +/–
Сообщение от fresco (??) on 17-Май-10, 12:35
по btrfs действительно много коммитов. хорошо!
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	28. "Релиз Linux-ядра 2.6.34"		+/–
	Сообщение от User294 (ok) on 17-Май-10, 16:17
	И вообще ченжлог - доставляет.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	34. "Релиз Linux-ядра 2.6.34"		–1 +/–
	Сообщение от pavlinux (ok) on 17-Май-10, 19:41
	> ченжлог - доставляет. Скажите, а Анальгин куда применять?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	40. "Релиз Linux-ядра 2.6.34"		+1 +/–
	Сообщение от Iv946n on 17-Май-10, 23:46
	Эх жаль в Ubuntu LTS и CentOS новые не попало...
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	60. "Релиз Linux-ядра 2.6.34"		+2 +/–
	Сообщение от User294 (ok) on 18-Май-10, 22:42
	>Эх жаль в Ubuntu LTS и CentOS новые не попало... Кхм, загнать только что вышедшее ядро в LTS дистр было бы весьма неумным решением. Из-за отсутствия времени на тесты и новизны ядра наверняка нарисовалось бы много вкусных грабель :).И вообще в LTS и прочих долгоподдерживаемых наивно ожидать свежак, они не для этого по определению, а?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	80. "Релиз Linux-ядра 2.6.34"		+/–
	Сообщение от stranger (??) on 20-Май-10, 11:49
	>Эх жаль в Ubuntu LTS и CentOS новые не попало... В CentOS оно все попадет после того, как RH все сбекпортит. Если уже не сделала этого...
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

2. "Релиз Linux-ядра 2.6.34"		–2 +/–
Сообщение от iZEN (ok) on 17-Май-10, 13:00
LogFS работает по принципу Soft Updates из UFS2?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	3. "какие мы любознательные, под корягой"		+2 +/–
	Сообщение от Andrey Mitrofanov on 17-Май-10, 13:14
	>LogFS работает по принципу Soft Updates из UFS2? ""If a file system discussion goes on long enough, someone will bring up soft updates eventually, usually in the form of, "Duhhh, why are you Linux people so stupid? Just use soft updates, like BSD!" Generally, there will be no direct reply to this comment and the conversation will flow silently around it, like a stream around an inky black boulder. [...] Overall, soft updates is a sophisticated, insightful, clever idea - and an evolutionary dead end. Journaling and copy-on-write systems are easier to implement, require less special-purpose code, and demand far less of the programmer writing to the interface.""
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	11. "какие мы любознательные, под корягой"		–3 +/–
	Сообщение от iZEN (ok) on 17-Май-10, 14:09
	>[оверквотинг удален] >up soft updates eventually, usually in the form of, "Duhhh, why >are you Linux people so stupid? Just use soft updates, like >BSD!" Generally, there will be no direct reply to this comment >and the conversation will flow silently around it, like a stream >around an inky black boulder. >[...] >Overall, soft updates is a sophisticated, insightful, clever idea - and an >evolutionary dead end. Journaling and copy-on-write systems are easier to implement, >require less special-purpose code, and demand far less of the programmer >writing to the interface."" Вот так вот. Просто. Без обиняков. "S U — это эволюционный тупик из-за того, что код труднопонимаем. Журналируемые и CoW системы реализовать легче.". © Неосиляторы. :D
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	12. "какие мы любознательные, под корягой"		+4 +/–
	Сообщение от Andrey Mitrofanov on 17-Май-10, 14:13
	>Journaling and copy-on-write systems are easier to implement, >из-за того, что код труднопонимаем". Ну, не осилил по-чучмекски, так не осилил--- >© Неосиляторы.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	30. "какие мы любознательные, под корягой"		–1 +/–
	Сообщение от Аноним (??) on 17-Май-10, 17:08
	просто у спонсоров не нашлось лишних денег ) бюджет штука узкая :D
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	65. "какие мы любознательные, под корягой"		+/–
	Сообщение от User294 (ok) on 18-Май-10, 23:11
	>Вот так вот. Просто. Без обиняков. "S U — это эволюционный тупик >из-за того, что код труднопонимаем. Журналируемые и CoW системы реализовать легче.". Да, iZEN, извини, но какойнить btrfs и выглядит стройнее чем упомянутое тобой решение и по большинству параметров и фич имхо зарулит с отрывом. Мне кажется что это неприятная для некоторых морально, но технически вполне честная классификация.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	67. "какие мы любознательные, под корягой"		+/–
	Сообщение от iZEN (ok) on 19-Май-10, 02:41
	>>Вот так вот. Просто. Без обиняков. "S U — это эволюционный тупик >>из-за того, что код труднопонимаем. Журналируемые и CoW системы реализовать легче.". > >Да, iZEN, извини, но какойнить btrfs и выглядит стройнее чем упомянутое тобой >решение и по большинству параметров и фич имхо зарулит с отрывом. Странно, что ты даже не предлагаешь сравнить файловые системы разных поколений, а уже окончательно уверился в том, что недоделанная Btrfs уже готова к продакшену и готова заменить не только всё ещё находящуюся в опытной эксплуатации у хомячков Ext4, но и промышленную UFS2. >Мне кажется что это неприятная для некоторых морально, но технически вполне >честная классификация. Классификация "чего"? Несостоятельности и невозможности понять ортогональные вещи, которые уже с успехом совмещены в экспериментальной реализации "UFS2+SUJ"?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	82. "какие мы любознательные, под корягой"		+/–
	Сообщение от guest (??) on 20-Май-10, 18:08
	>Классификация "чего"? Несостоятельности и невозможности понять ортогональные вещи, которые уже с успехом >совмещены в экспериментальной реализации "UFS2+SUJ"? помоему говорить о каком либо успехе SU (+J не трогаю) как-то странно. Технологии уже 10лет. За эти 10лет МакКузик так и не осилил привернуть к soft updates ни вменяемую диагностику, ни рантайм статистику, ни нормальное включение/выключение, вообщем перечислять можно долго. И как итог хорошая, в чемто красивая, и полезная технология убита примером кривоватой реализации.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	83. "какие мы любознательные, под корягой"		+/–
	Сообщение от iZEN (ok) on 21-Май-10, 11:47
	>>Классификация "чего"? Несостоятельности и невозможности понять ортогональные вещи, которые уже с успехом >>совмещены в экспериментальной реализации "UFS2+SUJ"? > >помоему говорить о каком либо успехе SU (+J не трогаю) как-то странно. >Технологии уже 10лет. >За эти 10лет МакКузик так и не осилил привернуть к soft updates >ни вменяемую диагностику, ни рантайм статистику, ни нормальное включение/выключение, вообщем перечислять >можно долго. Изучите матчасть, прежде чем такое говорить. Включение/выключение SU нормально выполняется через tunefs(8). Рантайм статистика выводится gstat(8).
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	84. "какие мы любознательные, под корягой"		+/–
	Сообщение от guest (??) on 21-Май-10, 12:11
	>Изучите матчасть, прежде чем такое говорить. Включение/выключение SU нормально выполняется через tunefs(8). Цитирую: The tunefs utility cannot be run on an active file system. To change an active file system, it must be downgraded to read-only or unmounted. Если по вашему, это и есть нормальный и удобный механизм вкл/выкл, то наши мнения об удобстве кардинально не совпадают. Давайте таким же макаром файрвол сделаем - чтоб добавить/удалить правило надо будет передернуть интерфейс. >Рантайм статистика выводится gstat(8). Старый я наверное стал и слепой. Ткните меня носом пожалуйста где в выводе gstat список задержанных softupdates микроопераций с их таймаутами (про то что хотелось бы еще видеть и зависимости я молчу).
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	85. "какие мы любознательные, под корягой"		+/–
	Сообщение от iZEN (ok) on 21-Май-10, 17:21
	>>Изучите матчасть, прежде чем такое говорить. Включение/выключение SU нормально выполняется через tunefs(8). > >Цитирую: >The tunefs utility cannot be run on an active file system. >To change an active file system, it must be downgraded to >read-only or unmounted. >Если по вашему, это и есть нормальный и удобный механизм вкл/выкл, то >наши мнения об удобстве кардинально не совпадают. Давайте таким же макаром >файрвол сделаем - чтоб добавить/удалить правило надо будет передернуть интерфейс. А в какой ещё ФС журналирование (к примеру) можно отключить на лету без отмонтирования? Я такой не знаю, а вы? >>Рантайм статистика выводится gstat(8). > >Старый я наверное стал и слепой. Ткните меня носом пожалуйста где в >выводе gstat список задержанных softupdates микроопераций с их таймаутами (про то >что хотелось бы еще видеть и зависимости я молчу). gstat — универсальный инструмент по сбору статистики с GEOM. На файловые системы ему (и пользователям), в общем-то, наплевать. Важна реакция на чтение/запись данных и счётчики производительности дисковой подсистемы (GEOM), а не то, как работает с данными ФС на своём уровне. Возможно, последнее интересно самим разработчикам, но у них для этого есть, я надеюсь, специальные отладочные инструменты.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	86. "какие мы любознательные, под корягой"		+/–
	Сообщение от guest (??) on 21-Май-10, 18:44
	Уважаемый, ну какая связь между softupdates и geom??? Меня, несколько удивила ваша фраза несколькими постами выше: > которые уже с успехом совмещены в экспериментальной реализации "UFS2+SUJ"? Если о продакшен качестве ufs2 я с вами полностью согласен, то на счет softupdates нет. >А в какой ещё ФС журналирование (к примеру) можно отключить на лету >без отмонтирования? Я такой не знаю, а вы? Нет, не знаю. softupdates в отличии от журнала требует на диске ровно 1 бит. >gstat — универсальный инструмент по сбору статистики с GEOM. На файловые системы >ему (и пользователям), в общем-то, наплевать. Важна реакция на чтение/запись данных Говорите за себя. Я вот например хотел бы знать, что после sync (на который кстати softupdates кладет болт) мои данные записаны на диск. >и счётчики производительности дисковой подсистемы (GEOM), а не то, как работает >с данными ФС на своём уровне. Возможно, последнее интересно самим разработчикам, >но у них для этого есть, я надеюсь, специальные отладочные инструменты. В том то и проблема, что не только пользователи но и разработчики были посланы аффтором этого чуда далеко и на долго, с воплями "я бог, там все работает, и никого править не пущу". Ну и как результат, журналирование метаданных зарулило и softupdates уже вряди выйдет за пределы *BSD. мне жаль.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	32. "Релиз Linux-ядра 2.6.34"		+/–
	Сообщение от User294 (ok) on 17-Май-10, 17:12
	iZEN ты забыл сказать что весь твой UFS2 это - "как бы нам сделать из окаменевшего говна не совсем говно с минимальными изменениями кода поскольку большие делать все-равно некому". В итоге к ископаемому архаику прикрутили сомнительных костылей. Офигенная, блин, эволюция. ИМХО Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	44. "Релиз Linux-ядра 2.6.34"		+/–
	Сообщение от Аноним (??) on 18-Май-10, 06:06
	Вы сейчас глубоко задели всех пользователей BSD систем, которые на "костыльных" UFS держат кучи нагруженных серверов по всему миру, несмотря на свою ущербность в Ваших глазах
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	61. "Релиз Linux-ядра 2.6.34"		–1 +/–
	Сообщение от User294 (ok) on 18-Май-10, 22:46
	А чего такого оскорбительного в констатации фактов? Все познается в сравнении. И UFS всего лишь ископаемое. С весьма древней организацией и потому понятно какое по производительности. На лично мое имхо такие дизайны свое отжили, по большому счету. Вон в ext4 закопали останки чего-то похожего по смыслу, куда ему и дорога :)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	79. "Релиз Linux-ядра 2.6.34"		+/–
	Сообщение от mnu (??) on 19-Май-10, 20:55
	>UFS всего лишь ископаемое. С весьма древней организацией и потому понятно какое по производительности. а ты его тестил? :-) или так, чисто газифицируешь?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	81. "Релиз Linux-ядра 2.6.34"		+/–
	Сообщение от User294 (ok) on 20-Май-10, 16:55
	>а ты его тестил? :-) Я не интересуюсь тестами ископаемых. Даже с костылями и подпорками. Это скучно и неперспективно. >или так, чисто газифицируешь? Так, чисто на архитектуру посмотрел слегка. Не понял нахрен оно вот такое. Вы поняли? Считаете это отличным инженерным решением? Юзайте наздоровье. А у меня ощущение вида "я его слепила из того что было".
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	52. "Релиз Linux-ядра 2.6.34"		+2 +/–
	Сообщение от mnu (??) on 18-Май-10, 16:25
	> Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим. Хм. Единственная production-ready (tm) FS на *BSD, построенная на технологии CoW - это ZFS, жрущая кучу RAM и дико тормозная при 95%+ занятости места на zpool'ах. Из не-production-ready есть HAMMER, по возможностям в некоторых местах превосходящий Btrfs, а в некоторых (сжатие, например) - всё ещё ей уступающий. Но HAMMER пока ещё не настолько стабилен, как UFS. Памяти жрёт меньше, чем ZFS, это да. Отжирает только в момент reblocking'а. Ни HAMMER, ни ZFS простыми не назовёшь. Не назовешь простой так же и XFS с reiserfs (которые в FreeBSD read-only). При использовании UFS + SUJ при более чем приемлемом быстордействии Вы сохраните оперативную память. При использовании async UFS + geom_journal Вы жертвуете ~1Gb под журнал и имеете производительность, соизмеримую с любой развитой journalled FS (с теми же ограничениями). В обоих случаях Вы не рискуете целостностью Ваших данных, Вам практически наплевать на фрагментацию (в отличии от ZFS) и RAM'ы кушается не много. А UFS2 нужен в основном для ОЧЕНЬ больших (>226Tb) FS да для всяких хитрых ACL... Ну, ускоряет немного благодаря delayed inode allocation, да, но ето не особо важно. Команда DragonFLyBSD вообще наплевала на UFS2, резонно решив, что лучше потратить время на стабилизацию HAMMER'а.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	57. "Релиз Linux-ядра 2.6.34"		+/–
	Сообщение от iZEN (ok) on 18-Май-10, 18:10
	>> Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим. > >Хм. Единственная production-ready (tm) FS на *BSD, построенная на технологии CoW - >это ZFS, жрущая кучу RAM и дико тормозная при 95%+ занятости >места на zpool'ах. Про "кучу" RAM и тормоза при 95% занятости можно подробнее? На днях копировал каталог с музыкой (~120ГБ) с ZFS (стационарный винчестер, SATA-2) на UFS2 (мобильный винчестер, SATA-2). После некоторого момента отожралось 100% RAM и графический пользовательский интерфейс перестал реагировать на кнопки мыши, тем не менее в фоне команда cp копировала файлы и таки закончила это дело. И, да, на ZFS включен prefetch — возможно это как-то повлияло на процесс копирования. >А UFS2 нужен в основном для ОЧЕНЬ больших (>226Tb) FS да для всяких хитрых ACL... Всегда считал, что предельный физический размер тома с UFS2 — 2ТБ вследствие ограничений разрядности некоторых value-типов в исходном коде FFS.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	73. "Релиз Linux-ядра 2.6.34"		+/–
	Сообщение от Аноним (??) on 19-Май-10, 13:42
	mnu@RELENG_8_0:~> dd if=/dev/zero of=/tmp/gvirstor.dd bs=1m oseek=1999 count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 0.003561 secs (294459461 bytes/sec) mnu@RELENG_8_0:~> ll -sh /tmp/gvirstor.dd 1072 -rw-r--r-- 1 mnu wheel 2,0G 19 тра 12:34 /tmp/gvirstor.dd mnu@RELENG_8_0:~> s mdconfig -a -f !$ -u 12 s mdconfig -a -f /tmp/gvirstor.dd -u 12 mnu@RELENG_8_0:~> s gvirstor label -v -s 4Tb virtest /dev/md12 Total virtual chunks: 1048576 (4 MB each), 4194304 MB total virtual size. Clearing metadata on /dev/md12. Writing allocation table to /dev/md12... (8 MB, 2 chunks) Storing metadata on /dev/md12 (500 chunks) (4 reserved) Done. mnu@RELENG_8_0:~> diskinfo -v /dev/virstor/virtest /dev/virstor/virtest 512 # sectorsize 4398046511104 # mediasize in bytes (4.0T) 8589934592 # mediasize in sectors mnu@RELENG_8_0:~> s newfs -O2 !$ s newfs -O2 /dev/virstor/virtest /dev/virstor/virtest: 4194304.0MB (8589934592 sectors) block size 16384, fragment size 2048 using 22825 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424, 12419776, ..... etc etc As for ZFS slowdown, try to download some gigabytes of torrents in parallel to it, especially when zpool is nearly full.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	74. "Релиз Linux-ядра 2.6.34"		+1 +/–
	Сообщение от mnu (??) on 19-Май-10, 14:17
	after adding some more 8Mb-chunked (yeah i should make chunks smaller, but who cares) MD's to geom_virstor (so newfs can proceed): mnu@RELENG_8_0:~> s mount /dev/virstor/virtest /mnt/tmp mnu@RELENG_8_0:~> df !$ df /mnt/tmp Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/virstor/virtest 4159842858 4 3827055426 0% /mnt/tmp mnu@RELENG_8_0:~> df -h /mnt/tmp Filesystem Size Used Avail Capacity Mounted on /dev/virstor/virtest 3.9T 4.0K 3.6T 0% /mnt/tmp mnu@RELENG_8_0:~> gvirstor status Name Status Components virstor/virtest 6% physical free md12 md13 md14 md15 md16 md17 md18 md19 md20 md21 md22 md23 md24 mnu@RELENG_8_0:~> ll -s /tmp/gvirstor.dd /mnt/big/gvirstor* \| awksum # space really taken on disks by sparse MDs 1529120 mnu@RELENG_8_0:~> gvirstor list \| grep Mediasize \| awk '{s += $2} END {print s/1024}' 4395319296 mnu@RELENG_8_0:~> s umount /mnt/tmp mnu@RELENG_8_0:~> s newfs -O1 /dev/virstor/virtest /dev/virstor/virtest: 4194304.0MB (8589934592 sectors) block size 16384, fragment size 2048 using 22834 cylinder groups of 183.69MB, 11756 blks, 23552 inodes. super-block backups (for fsck -b #) at: 32, 376224, 752416, 1128608, 1504800, 1880992, 2257184, 2633376, 3009568, 3385760, ... etc etc (there is no delayed inode allocation in UFS1, therefore newfs works MUCH slower this time) So 4Tb virtual storage is OK for UFS1 too. p.s. ZFS is used w/o prefetch here, as i do not have 4Gb+ RAM, and benchmarks showed it is faster w/o prefetch. p.p.s. Another ZFS slowdown (full-blown hard kernel hang for upto 10 sec) will be experienced by "zfs compression=on" users - kernel will hang while zlib compresses data, which is then sent to ZFS. Only then kernel will unhang and continue.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	55. "Релиз Linux-ядра 2.6.34"		+1 +/–
	Сообщение от iZEN (ok) on 18-Май-10, 17:52
	>iZEN ты забыл сказать что весь твой UFS2 это - "как бы >нам сделать из окаменевшего говна не совсем говно с минимальными изменениями >кода поскольку большие делать все-равно некому". В итоге к ископаемому архаику >прикрутили сомнительных костылей. Офигенная, блин, эволюция. ИМХО Copy-on-write зарулит нафиг все >эти потуги. Хорошие вещи должны быть простыми и не костыльныим. То же самое происходило: Ext2 > Ext3 > Ext4. Сюрприз? Вот только ни в одной из них поддержки онлайновых снапшотов нету и нельзя делать проверку структур (fsck) на смонтированной ФС...
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	59. "Релиз Linux-ядра 2.6.34"		+/–
	Сообщение от User294 (ok) on 18-Май-10, 22:36
	> Вот только ни в одной из них поддержки онлайновых снапшотов нету Что логично, т.к. LVM есть. Зачем городить повторный функционал в ФС? В случае CoW и подобных по смыслу ФС снапшоты имеют некий физический смысл, являясь по сути свойством-фичой дизайна ФС и там оно осмысленно. А в простой ФС во первых тупо делать то же что уже реализовано а во вторых - общая эффективность создания снапшотов в классической ФС - сами понимате какая. А никакая, блин. > нельзя делать проверку структур (fsck) на смонтированной ФС... ...что для журналируемой ФС не слишком то актуально ;) А вот на экстенты в UFS2 как я понимаю так и не перешли, да? А то разница между ext3 и 4 в ряде случаев просто вызывает отпад челюсти.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	66. "Релиз Linux-ядра 2.6.34"		+1 +/–
	Сообщение от iZEN (ok) on 19-Май-10, 02:31
	>> Вот только ни в одной из них поддержки онлайновых снапшотов нету > >Что логично, т.к. LVM есть. Зачем городить повторный функционал в ФС? В >случае CoW и подобных по смыслу ФС снапшоты имеют некий физический >смысл, являясь по сути свойством-фичой дизайна ФС и там оно осмысленно. >А в простой ФС во первых тупо делать то же что >уже реализовано а во вторых - общая эффективность создания снапшотов в >классической ФС - сами понимате какая. А никакая, блин. Для UFS2 и ZFS время создания снапшотов — мгновенное. К тому же, LVM, в отличие от ZFS, не поддерживает инкрементные снимки и клоны. >> нельзя делать проверку структур (fsck) на смонтированной ФС... > >...что для журналируемой ФС не слишком то актуально ;) Ну, да. Лучше подождать минуту-другую, пока монтируемая ФС проверится, чем двадцать минут насиловать смонтированную рабочую ФС. >А вот на экстенты в UFS2 как я понимаю так и не >перешли, да? А то разница между ext3 и 4 в ряде >случаев просто вызывает отпад челюсти. Нет, экстенты в UFS2 ещё не реализовали, есть только необходимые структуры для этого. Зато в UFS2 идёт адресация на уровне фрагментов блоков (от 2 до 16 кбайт), чем экономится пространство под файлы и практически нету разбросанных по всему диску полупустых блоков с хвостами файлов, как в случае с Ext2/3. У Ext4 какой минимальный размер блока?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору