Линус Торвальдс представил (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):
- Дисковая подсистема, ввод/вывод и файловые системы- Интегрирован (https://www.opennet.ru/opennews/art.shtml?num=25879) код файловой системы Ceph (http://ceph.newdream.net/), способной поддерживать работу хранилища объемом в несколько петабайт (1 Пб = 1024 Тб), распределенного по тысячам машин. Встроенные в Ceph механизмы репликации данных (данные разбиваются на блоки и несколько раз дублируются на р...
URL: http://lkml.org/lkml/2010/5/16/89
Новость: https://www.opennet.ru/opennews/art.shtml?num=26609
по btrfs действительно много коммитов. хорошо!
И вообще ченжлог - доставляет.
> ченжлог - доставляет.Скажите, а Анальгин куда применять?
Эх жаль в Ubuntu LTS и CentOS новые не попало...
>Эх жаль в Ubuntu LTS и CentOS новые не попало...Кхм, загнать только что вышедшее ядро в LTS дистр было бы весьма неумным решением. Из-за отсутствия времени на тесты и новизны ядра наверняка нарисовалось бы много вкусных грабель :).И вообще в LTS и прочих долгоподдерживаемых наивно ожидать свежак, они не для этого по определению, а?
>Эх жаль в Ubuntu LTS и CentOS новые не попало...В CentOS оно все попадет после того, как RH все сбекпортит. Если уже не сделала этого...
LogFS работает по принципу Soft Updates из UFS2?
>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.""
>[оверквотинг удален]
>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
>Journaling and copy-on-write systems are easier to implement,
>из-за того, что код труднопонимаем".Ну, не осилил по-чучмекски, так не осилил---
>© Неосиляторы.
просто у спонсоров не нашлось лишних денег ) бюджет штука узкая :D
>Вот так вот. Просто. Без обиняков. "S U — это эволюционный тупик
>из-за того, что код труднопонимаем. Журналируемые и CoW системы реализовать легче.".Да, iZEN, извини, но какойнить btrfs и выглядит стройнее чем упомянутое тобой решение и по большинству параметров и фич имхо зарулит с отрывом. Мне кажется что это неприятная для некоторых морально, но технически вполне честная классификация.
>>Вот так вот. Просто. Без обиняков. "S U — это эволюционный тупик
>>из-за того, что код труднопонимаем. Журналируемые и CoW системы реализовать легче.".
>
>Да, iZEN, извини, но какойнить btrfs и выглядит стройнее чем упомянутое тобой
>решение и по большинству параметров и фич имхо зарулит с отрывом.Странно, что ты даже не предлагаешь сравнить файловые системы разных поколений, а уже окончательно уверился в том, что недоделанная Btrfs уже готова к продакшену и готова заменить не только всё ещё находящуюся в опытной эксплуатации у хомячков Ext4, но и промышленную UFS2.
>Мне кажется что это неприятная для некоторых морально, но технически вполне
>честная классификация.Классификация "чего"? Несостоятельности и невозможности понять ортогональные вещи, которые уже с успехом совмещены в экспериментальной реализации "UFS2+SUJ"?
>Классификация "чего"? Несостоятельности и невозможности понять ортогональные вещи, которые уже с успехом
>совмещены в экспериментальной реализации "UFS2+SUJ"?помоему говорить о каком либо успехе SU (+J не трогаю) как-то странно. Технологии уже 10лет.
За эти 10лет МакКузик так и не осилил привернуть к soft updates ни вменяемую диагностику, ни рантайм статистику, ни нормальное включение/выключение, вообщем перечислять можно долго.
И как итог хорошая, в чемто красивая, и полезная технология убита примером кривоватой реализации.
>>Классификация "чего"? Несостоятельности и невозможности понять ортогональные вещи, которые уже с успехом
>>совмещены в экспериментальной реализации "UFS2+SUJ"?
>
>помоему говорить о каком либо успехе SU (+J не трогаю) как-то странно.
>Технологии уже 10лет.
>За эти 10лет МакКузик так и не осилил привернуть к soft updates
>ни вменяемую диагностику, ни рантайм статистику, ни нормальное включение/выключение, вообщем перечислять
>можно долго.Изучите матчасть, прежде чем такое говорить. Включение/выключение SU нормально выполняется через tunefs(8). Рантайм статистика выводится gstat(8).
>Изучите матчасть, прежде чем такое говорить. Включение/выключение 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 микроопераций с их таймаутами (про то что хотелось бы еще видеть и зависимости я молчу).
>>Изучите матчасть, прежде чем такое говорить. Включение/выключение 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), а не то, как работает с данными ФС на своём уровне. Возможно, последнее интересно самим разработчикам, но у них для этого есть, я надеюсь, специальные отладочные инструменты.
Уважаемый, ну какая связь между softupdates и geom???
Меня, несколько удивила ваша фраза несколькими постами выше:
> которые уже с успехом совмещены в экспериментальной реализации "UFS2+SUJ"?Если о продакшен качестве ufs2 я с вами полностью согласен, то на счет softupdates нет.
>А в какой ещё ФС журналирование (к примеру) можно отключить на лету
>без отмонтирования? Я такой не знаю, а вы?Нет, не знаю.
softupdates в отличии от журнала требует на диске ровно 1 бит.>gstat — универсальный инструмент по сбору статистики с GEOM. На файловые системы
>ему (и пользователям), в общем-то, наплевать. Важна реакция на чтение/запись данныхГоворите за себя. Я вот например хотел бы знать, что после sync (на который кстати softupdates кладет болт) мои данные записаны на диск.
>и счётчики производительности дисковой подсистемы (GEOM), а не то, как работает
>с данными ФС на своём уровне. Возможно, последнее интересно самим разработчикам,
>но у них для этого есть, я надеюсь, специальные отладочные инструменты.В том то и проблема, что не только пользователи но и разработчики были посланы аффтором этого чуда далеко и на долго, с воплями "я бог, там все работает, и никого править не пущу".
Ну и как результат, журналирование метаданных зарулило и softupdates уже вряди выйдет за пределы *BSD. мне жаль.
iZEN ты забыл сказать что весь твой UFS2 это - "как бы нам сделать из окаменевшего говна не совсем говно с минимальными изменениями кода поскольку большие делать все-равно некому". В итоге к ископаемому архаику прикрутили сомнительных костылей. Офигенная, блин, эволюция. ИМХО Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим.
Вы сейчас глубоко задели всех пользователей BSD систем, которые на "костыльных" UFS держат кучи нагруженных серверов по всему миру, несмотря на свою ущербность в Ваших глазах
А чего такого оскорбительного в констатации фактов? Все познается в сравнении. И UFS всего лишь ископаемое. С весьма древней организацией и потому понятно какое по производительности. На лично мое имхо такие дизайны свое отжили, по большому счету. Вон в ext4 закопали останки чего-то похожего по смыслу, куда ему и дорога :)
>UFS всего лишь ископаемое. С весьма древней организацией и потому понятно какое по производительности.а ты его тестил? :-) или так, чисто газифицируешь?
>а ты его тестил? :-)Я не интересуюсь тестами ископаемых. Даже с костылями и подпорками. Это скучно и неперспективно.
>или так, чисто газифицируешь?
Так, чисто на архитектуру посмотрел слегка. Не понял нахрен оно вот такое. Вы поняли? Считаете это отличным инженерным решением? Юзайте наздоровье. А у меня ощущение вида "я его слепила из того что было".
> 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'а.
>> 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.
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 sectorsmnu@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 etcAs for ZFS slowdown, try to download some gigabytes of torrents in parallel to it, especially when zpool is nearly full.
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.
>iZEN ты забыл сказать что весь твой UFS2 это - "как бы
>нам сделать из окаменевшего говна не совсем говно с минимальными изменениями
>кода поскольку большие делать все-равно некому". В итоге к ископаемому архаику
>прикрутили сомнительных костылей. Офигенная, блин, эволюция. ИМХО Copy-on-write зарулит нафиг все
>эти потуги. Хорошие вещи должны быть простыми и не костыльныим.То же самое происходило: Ext2 > Ext3 > Ext4. Сюрприз? Вот только ни в одной из них поддержки онлайновых снапшотов нету и нельзя делать проверку структур (fsck) на смонтированной ФС...
> Вот только ни в одной из них поддержки онлайновых снапшотов нетуЧто логично, т.к. LVM есть. Зачем городить повторный функционал в ФС? В случае CoW и подобных по смыслу ФС снапшоты имеют некий физический смысл, являясь по сути свойством-фичой дизайна ФС и там оно осмысленно. А в простой ФС во первых тупо делать то же что уже реализовано а во вторых - общая эффективность создания снапшотов в классической ФС - сами понимате какая. А никакая, блин.
> нельзя делать проверку структур (fsck) на смонтированной ФС...
...что для журналируемой ФС не слишком то актуально ;)
А вот на экстенты в UFS2 как я понимаю так и не перешли, да? А то разница между ext3 и 4 в ряде случаев просто вызывает отпад челюсти.
>> Вот только ни в одной из них поддержки онлайновых снапшотов нету
>
>Что логично, т.к. LVM есть. Зачем городить повторный функционал в ФС? В
>случае CoW и подобных по смыслу ФС снапшоты имеют некий физический
>смысл, являясь по сути свойством-фичой дизайна ФС и там оно осмысленно.
>А в простой ФС во первых тупо делать то же что
>уже реализовано а во вторых - общая эффективность создания снапшотов в
>классической ФС - сами понимате какая. А никакая, блин.Для UFS2 и ZFS время создания снапшотов — мгновенное. К тому же, LVM, в отличие от ZFS, не поддерживает инкрементные снимки и клоны.
>> нельзя делать проверку структур (fsck) на смонтированной ФС...
>
>...что для журналируемой ФС не слишком то актуально ;)Ну, да. Лучше подождать минуту-другую, пока монтируемая ФС проверится, чем двадцать минут насиловать смонтированную рабочую ФС.
>А вот на экстенты в UFS2 как я понимаю так и не
>перешли, да? А то разница между ext3 и 4 в ряде
>случаев просто вызывает отпад челюсти.Нет, экстенты в UFS2 ещё не реализовали, есть только необходимые структуры для этого. Зато в UFS2 идёт адресация на уровне фрагментов блоков (от 2 до 16 кбайт), чем экономится пространство под файлы и практически нету разбросанных по всему диску полупустых блоков с хвостами файлов, как в случае с Ext2/3. У Ext4 какой минимальный размер блока?
>А вот на экстенты в 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.
гррр, съело цитату.> -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.
Позорный баг с iowait так и не поправили? Все просираем десктопы?
На десктопах на него нарываются единицы. Я его, например, вообще в дикой природе не встречал ещё.
Щаз, единицы, километровые тикеты на kernel.org и launchpad говорят совершенно о другом.
Нет никакого ядра (ц) НеО
очень даже многие на него нарываются, вот в старых ядрах 2.6.18 (в RHEL например) этого не бывает, насколько я помню. И ведь так до сих пор эту хрень и не поправили. Хотя действительно об этом пишется очень много.
а как воспроизвести баг? или ссылка на тикет launchpad
+1. что за баг такой? :)
Аналитики с ЛОРа подсказывают, что https://bugzilla.kernel.org/show_bug.cgi?id=12309 . Но я этот баг в первый раз в глаза вижу, такой нигде на моих системах не попадался.
да, есть такая гнусная бага. это когда копируешь файлы с флехи на винт и мыша начинает дергаться. Я списывал на не-тот IO scheduler / типа на другом было бы получше, но тюнить влом - проще скопировать флеху, а затем посмотреть фильм.Однозадачный linux получается ;)
может мышь начинает дергаться от того, что винт уж больно шибко трещит? :)
такое пока не встречал, но полагаю, это специфично для каких-то конкретных чипсетов.
мышь конечно не приятно что дергается и отзывчивости нету, но вот когда при большой, лучше скажем так -- при приличной нагрузке на диск комп работает так, как будто ему лет так 10-12, а то 15, вот это напрягает. Причем ни в винде, ни во фрюхе такого не наблюдается при той же нагрузке. Первым это заметил чувак, какой-то известный в мире линукс, заметил он это именно на серверах (а не десктопах) из-за высокой загруженности системы при приличном дисковом IO. Причем раньше как от писал такого на этом же железе типа не было.
Подтверждаю, сам нарывался на этот баг. Проявляется на некоторых чипсетах, скорее это даже зависит от контроллера ввода-вывода. Воспроизвести не сложно, запустить локальное копирование, сколь нибудь большого файла 3-4 Гб, а лучше нескольких. Тормоза будут не детские, причем они именно в виде freeze, у меня например на одном из сереров БД, тупо вставали все потоки чтения :(
Было на старом ПК с чипсетом VIA. Владелец удалил разделы с Linux очень быстро.
У меня было год назад. Пробовал на компьютере мужа сестры Sabayon Linux 4. Муж Линукс не любит. Потом он заявил, что "А испробуем мы твой Линукс!", подключил PSP, и начал копировать на него большой файл. Несмотря на то, что определилось и подключилось, копировалось страшно медленно, а затем стало на 98-м проценте. А все потому, что я не оставлял систему однозадачной, как предлагается выше, а делал вещи, и делал много. Не знаю, какая там была файловая система, но файлик из виндовса удаляться не захотел (в винде при копироании сть компьютер зависает, или при доступе, с удалением потом проблемы). Я хоть и знал решение, но сделать не дали. Обвинили в том, что я принес домой глючный Линукс.
в таком случае я выдаю оппоненту знамя в руки и вешаю барабан на шею. мой агрумент - линукс порой требует настройки, а уже настроенная система будет работать до отказа оборудования. да и безвирусный вариант системы гораздо спокойнее. :)
Это не Линукс требует настройки, а Убунту требет нстройки. А вся настройка Линукса - это сменить воллпейпер, установить драйвер видеокарты, установить кодеки, и сменить кусор мыши
Это почему ещё? Да программок доставить надо и всё... Но намного больше, чем ты говоришь.
Чем убунта отличается от остальных линухов? А ничем, кроме того что ты ее не любишь. Может хватит уже столь тупо и толсто троллить то, Zenithar?
Где ты был так долго? Возвращайся на сайт :-)
да на работе сейчас софт тестируем для эмуляции оборудования, вот и времени особо нет. с нуля писали, автоконфигурация и прочее. тестирование на нагрузку до предела io и прочие увлекательные занятия...
>А все потому, что я не оставлял систему однозадачной, как предлагается выше,Ты опух, человек? Времена однозадачных систем были в эпоху MSDOS и безвозвратно закончились. А кто не отпустил ручник - тот пролетает. Исключение: если вы фирма Эппл и выпускаете ифон - то у вас есть шансы промыть мозг вашим хомячкам. В противном случае вас ждет эпик фэйл с таким подходом к делу. Что вы и получили. Кстати, заслуженно вполне. Баги мочить надо а не строить юзера что ты, дескать, должен как в досе, а потом еще и напильником, блаблабла.
>Обвинили в том, что я принес домой глючный Линукс.
Ну так ты именно это и сделал, баклан - если система обосралась при юзере, значит уж обосралась. Нормальным пользователям не впилось неделю с бубном прыгать. Им работать надо. Поэтому нормальный подход - передавить такие баги в системе, а не втирать ересь про однозадачные режимы. А так - обсираки бывают везде, но их процент у гентуобразных почему-то сильно выше чем у остальных. Всего лишь наблюдение...
> да, есть такая гнусная бага. это когда копируешь файлы с флехи на винт и мыша начинает дергаться.Такая "бага" есть у меня на одной из двух десятков рабочих машинок, причём баг сей проявляется все зависимости от оси, и на богомерзкой винХР тоже. Это аппаратно-зависимый баг криворуких мамкостроителей.
s/все/вне/
сам на себе такой баг испытывал, когда был nvidia чипсет nforce4 (со встроенной видео карточкой 6150). если копировать файлы более 4 гигов, то начинались просто жуткие тормоза как в винде обычно бывает. мышь дергается, окна сворачиваются, разворачиваются по 10 секунд и тд. когда же копирование заканчивалось, то тормоза прекращались.потом перешел на amd/ati чипсеты и больше это проблема меня не мучала.
> а как воспроизвести баг? или ссылка на тикет launchpadНапример, у меня при dd if=/dev/zero of=~/file bs=1000000 раз в несколько секунд всё подвисает на 1-2 сек.
>Например, у меня при 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
>> а как воспроизвести баг? или ссылка на тикет launchpad
>
>Например, у меня при dd if=/dev/zero of=~/file bs=1000000 раз в несколько секунд
>всё подвисает на 1-2 сек.Наблюдаю то эе самое с Интел. Я думал, так везде. Думал, процессор нули генериует в мегабайтных количестах с большим трудом. Попробовал сейчас с чипсетом AMD... Не тормозит! Я с ним вообще год, и в последние 2 месяца переезжаю на новых жесткий диск. Копирую и удаляю огромные объемы данных, и архивирую. Никаких тех самых тормзов, что я видел с Sabayon! Да и с Интелом спокойно прошло cp -ax 120-гигабайтного раздела, в системе с с ядром 2.6.28.10.
> Я с ним вообще год, и в последние 2 месяца переезжаю на новых жесткий диск.
> Копирую и удаляю огромные объемы данных, и архивирую.А в процессе копирования полазай по инету, погляди Ютюбу, погяди mplayer,
ОпОфис, в Dia нарисуй план квартиры обычными прямоугольниками, закарась их,
Unigine Heaven погоняй, gtkperf на 1000 повторов.Ну Што?! Ещё не тормозит? :)
> Да и с Интелом спокойно прошло cp -ax 120-гигабайтного раздела, в системе с с ядром 2.6.28.10.
mount -o remount,sync,atime,diratime,norelatime,barrier /
и
cp -ax ....
>> Я с ним вообще год, и в последние 2 месяца переезжаю на новых жесткий диск.
>> Копирую и удаляю огромные объемы данных, и архивирую.
>
>А в процессе копирования полазай по инету, погляди Ютюбу, погяди mplayer,
>ОпОфис, в Dia нарисуй план квартиры обычными прямоугольниками, закарась их,
>Unigine Heaven погоняй, gtkperf на 1000 повторов.
>
>Ну Што?! Ещё не тормозит? :)Нет, не тормозит! При этом ещё и BOINC крутится, одновременно две задачки щёлкая. Ах, да, ютуб не смотрю, ибо принципиально не имею дел с явой, моно и флешем.
>[оверквотинг удален]
>>
>>А в процессе копирования полазай по инету, погляди Ютюбу, погяди mplayer,
>>ОпОфис, в Dia нарисуй план квартиры обычными прямоугольниками, закарась их,
>>Unigine Heaven погоняй, gtkperf на 1000 повторов.
>>
>>Ну Што?! Ещё не тормозит? :)
>
>Нет, не тормозит! При этом ещё и BOINC крутится, одновременно две задачки
>щёлкая. Ах, да, ютуб не смотрю, ибо принципиально не имею дел
>с явой, моно и флешем.Планировщик ввода/вывода надо нагружать, а не планировщик задач.
>[оверквотинг удален]
>>
>>А в процессе копирования полазай по инету, погляди Ютюбу, погяди mplayer,
>>ОпОфис, в Dia нарисуй план квартиры обычными прямоугольниками, закарась их,
>>Unigine Heaven погоняй, gtkperf на 1000 повторов.
>>
>>Ну Што?! Ещё не тормозит? :)
>
>Нет, не тормозит! При этом ещё и BOINC крутится, одновременно две задачки
>щёлкая. Ах, да, ютуб не смотрю, ибо принципиально не имею дел
>с явой, моно и флешем.Запусти на одной консоли
# dd if=/dev/zero of=BIGFILE count=100000000 bs=1k
на другой# sar -P ALL 1
И дай глянуть, измерения через минуту.
У меня на домашнем компе есть похожий баг, начался с ядра ~ 2.6.28. Когда копирую больше гига на флешку за раз, не важно одним файлом или многими, скорость копирования со временем падает до позорных ~ 100 КБ/с, и копирование продолжается вечность. Первые пару минут скорость держится на уровне нормальных 10 - 15 МБ/с. Перепробовал несколько флешек, три себя ведут именно так. Одна только флешка работает нормально -- это скоростная Corsair Voyager GT 8 GB. Пишет ~ 22 МБ/с стабильно. Система -- Intel Pentium 4.
Баг -- просто жесть. Меня бесит уже года полтора.
Неужели никто из разработчиков ядра никогда его не ловил?? X-|
А зарепортить не пробовал? Хотя бы в багтрекер своего дистрибутива.. Чем ждать, что кто-то еще зарепортит и исправит проблему, возникающую у тебя o_O
это просто может быть элементарный баг самого чипсета, к которому нужно будет строить нехилый костыль. как примерно год назад были проблемы с сетевыми картами, выяснилось - баг в прошивке.
Вы описываете совершенно другой баг (в USB подсистеме). Причем этот баг вроде исправлен в 2.6.32 (или даже чуть ранее).У меня тоже есть "скоростная" флешка Corsair Voyager GT 16 GB и при работе в Ubuntu 8.04 (ядро 2.6.24) наблюдаю аналогичные тормоза при записи на неё. Со скоростью чтения данных с флешки проблем нет. Пробовал тестировать с LiveCD под ядром 2.6.32 - проблема полностью решена, флешка показывает свою максимальную скорость записи.
lzma в squashfs наконец-то!
>lzma в squashfs наконец-то!Если что, то вседа можно было сделать самому. Просто когда squashfs вошла в ядро версии 2.6.28, она как раз вошла с о ограничениями: нет lzma. Тем не менее, многие дистрибутивы, включая Бубен и Sabayon, давно используют образы squashfs на своих LiveCD. Не удивлюсь, если сжатие в них - lzma
>Если что, то вседа можно было сделать самому.Бесспорно, можно все велосипеды переизобрести заново. Только неэффективно нифига.
Рано обрадовались. Монтирование squashfs пожатых lzma из коробки пока не работает.
Интегрирована лишь часть патчей! Остальное, к сожалению, опять нужно патчить руками.
http://forum.kernelnewbies.org/read.php?4,1596