> Вот скомпилю я ведро, а чем мне разделы форматить?
Внезапно...
mkfs.btrfs dev

btrfs, btrfs... ext пора закапывать?

> Что мне пробовать, если все эти тулзы делают ровно одно и то же, за исключением специфичных usb-девайсов?

Ну шо, неужели тебя 280Kb так напрягут?

В оперативу, конечно. На диск это уже hibernate.

А мужики говорят, что s2d hibernate'ом называют вендузятники. Видать правы были мужики…

> Да у меня тоже встанет. У меня даже от тяжелого копирования (несколько сезонов сериала, например) ему слегка плохеет.

Стало быть тезис про говножелезо подтвердился. Или ты думаешь, что накупив самых дорогих писков и ссыпав это всё в корпус ты получишь офигеть какую конфетку?

Кто-нибудь знает, а reiser4 в ванильное ядро вообще когда-нибудь хоть попадёт? Что-то я уже устал ждать, а вручную собирать лениво.

> Стало быть тезис про говножелезо подтвердился. Или ты думаешь, что накупив самых дорогих писков и ссыпав это всё в корпус ты получишь офигеть какую конфетку?

Это ноут вообще-то :)
Но суть в другом - оно точно так же проявляется на 945пм (ноут), Ati X1150 SB450 (ноут), х58 (десктоп) и nForce 5x0 (десктопы, не один).
Железо разных поколений и разных производителей. И вдруг «ядро не виновато»? Не логично.

Жди, надейся и верь. Спрашивай в LKML.

>Реально наблюдаю такую картину: при копировании музыки(до ~80Мб) на плеер (2Гб) копируется секунд за пять, при копировании 1Гб до 10-15 мин.

Это не баг, это асинхронная передача данных, часть данных пишется в кеш, а при переполнении кэша или размонтировании кэш сбрасывается на сам накопитель. Это выключается (только зачем?): опция sync в fstab.

Кошмар.
cat /proc/cpuinfo
model name : Intel(R) Celeron(R) CPU E1400 @ 2.00GHz
cat /proc/meminfo
MemTotal: 2064996 kB
hdparm -i /dev/sda
Model=ST380815AS, FwRev=4.AAB, SerialNo=6RACSYRK
hdparm -i /dev/sdb
Model=ST31000528AS, FwRev=CC34, SerialNo=9VP0GA28
hdparm -i /dev/sdc
Model=WDC WD7500AADS-00M2B0, FwRev=01.00A01, SerialNo=WD-WCAV52133247

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

> Железо разных поколений и разных производителей.
И везде колом становится от dd на шифрованные носители?

Да заманали вы со своим dd. Уже разобрались выше, что дд не у всех этот баг воспроизводит.

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

Ядро виновато. И производители тоже.
Вторые из-за того что угрюмо молчат и ничего не рассказывают, а первые потому что не пинают первых.

*Вторых

>>Ну шо, неужели тебя 280Kb так напрягут?

Уже стояли, оказывается. Снес от греха подальше.

А мужики говорят, что s2d hibernate'ом называют вендузятники. Видать правы были мужики…

Ага, а то что термин hibernate используется как в ведре, так и твоем любимом pm-utils тебя не смущает?

Вроде в 2.6.36.

http://www.linux.org.ru/news/kernel/4222134

> Ага, а то что термин hibernate используется как в ведре, так и твоем любимом pm-utils тебя не смущает?
Меня — нет, а мужиков смущает.

Зачем она нужна, эта асинхронная передача, для флешек? Я хочу скинуть инфу и вытащить флешку. Другой механизм работы ЗАЧЕМ? и если в фстабе прописать, то оно будет только для одной флехи?

Эх, как нескоро… Ну что ж, как раз к тому времени KDE 4.5 появится и линукс станет совсем идеальным =)

>Зачем она нужна, эта асинхронная передача, для флешек? Я хочу скинуть инфу и вытащить флешку. Другой механизм работы ЗАЧЕМ? и если в фстабе прописать, то оно будет только для одной флехи?

А ты не думал, насколько быстрее ты убиваешь флешку, не используя кэш? И насколько оно медленнее выходит?

>>Меня — нет, а мужиков смущает.

Сынок, изучи список терминов, потом приходи в тред опять. Винда не имеет отношения к hibernate.

Можно вроде правило для HAL'а прописать, только вот HAL пора выкидывать. Может, это можно и через udev сделать.

> Сынок, изучи список терминов, потом приходи в тред опять
Это ты не мне, а тем мужикам. Мне пофигу, как называется то действие, которым я не пользуюсь.

>>Это ты не мне, а тем мужикам. Мне пофигу, как называется то действие, которым я не пользуюсь.

Скоро ты поймешь, что вокруг очень много идиотов.

pekmop1024

Я могу тебе дать 99% вероятности его воспроизведения простейшим способом на любом x86 железе.

Ну что же ты молчишь олень!??? (простите за выражение, не удержался) Напиши в Bugzilla"у потому что у бага №12309 Статус: RESOLVED INSUFFICIENT_DATA

Просвети насчёт износа. За скорость я писал, что 1 Гб будет копировать 10-15 минут, да еще и потом скидывать кеш.

> от тяжелых операций с диском, любых.
У меня дома шифрования нет, но я не вижу никаких колов от дисковых операций. Вижу снижение скорости записи пропорциональное, когда много потоков. Видимо я везунчик.

> За скорость я писал, что 1 Гб будет копировать 10-15 минут
Копируй два раза по 512. :D

>btrfs, btrfs... ext пора закапывать?

Оно им не конкурент, закапывать нужно ZFS

Ха-ха. Монтируй флешки вручную, а ещё лучше вообще не используй, все храни в голове.

И песни наcвистывай себе под нос. :D

Сижу на 2.6.30.10 BFS,BFQ.

У вас проблемы робяты?

> А 12309 там починили?

Так что, в толксы его? Или в hardware? У меня есть подозрение, что баг свзяан с libata

я сам сейчас на
0. Model=ST3160021A системный + Model=SAMSUNG SP0802N дополнительный
1. «старом» ide 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06),
2. без эмуляции (НЕ через libata),
3. драйвер вбит в ядро,
4. 250 hz таймер,
5. без preempt,
6. проблем с прерываниями (irq storm) нету,
7. процессор старый одноядерный K7 (нет изменения частоты),
8. памяти 768 Мб, но можно сделать сколько надо.

>у бага №12309 Статус: RESOLVED INSUFFICIENT_DATA

Эта пять! Складывается ощущение, что кернел-левелоперы такие себе олени, сидящие на топовом железе и потому не способные/не хотящие воспроизвести/исправить этот баг, т.к. возможно прийдётся выкинуть какой-то говнокод, пропихнутый их хозяевами (-корпорастами), а это не лояльно =)

>> ждем Linux 2.8

Дык оно ж певрого апреля вышло сего года,не?

Давай в hardware

>>Эта пять! Складывается ощущение, что кернел-левелоперы такие себе олени, сидящие на топовом железе и потому не способные/не хотящие воспроизвести/исправить этот баг, т.к. возможно прийдётся выкинуть какой-то говнокод, пропихнутый их хозяевами (-корпорастами), а это не лояльно =)

Ты только сейчас понял, что на десктоп им плевать и главное - серверные плюшки?

http://www.linux.org.ru/forum/linux-hardware/4893907

Я это понял ещё очень давно, читая kernelnewbies.org

100% воспроизводится

запускаем рторрент с хешированием фильмов по 2-8 Гб. Винт кстати WD, ноутбук.

Читай тред внимательно, хамло подзаборное

кстати, видимый ФГМ потихоньку начинает проявляеться и в lkml:
http://lkml.org/lkml/2010/4/1/128
http://lkml.org/lkml/2010/4/27/40
:-D

*проявляться

>Squashfs

Add support for lzma and lzo compression

Ну наконец-то, теперь не придётся патчить ваниль..

Ой.

Кто слона пропустил? Неужели.

12309 отлично воспроизводится на шифрованных дисках с LVM поверх.

Это ли не серверные плюшки?!

Забавно.

>>btrfs, btrfs... ext пора закапывать?

Оно им не конкурент, закапывать нужно ZFS

Оно им как раз конкурент в полный рост. Товарищу tytso придется задуматься, что же делать дальше. Как ты ZFS закапывать то собрался - ее ж в линаксе нету (для зануд - в том, который ядро)?

>>Это ли не серверные плюшки?!

Это особые плюшки - с маком.

> кстати, видимый ФГМ потихоньку начинает проявляеться и в lkml:

http://lkml.org/lkml/2010/4/1/128

ты на дату-то смотрел?