Линус Торвальдс анонсировал (https://lkml.org/lkml/2012/12/21/430) первый кандидат в релизы ядра Linux 3.8 (rc1), который ознаменовал закрытие окна по приёму новшеств (merge window) в ветку 3.8. Линус отметил, что по числу принятых изменений это было одно из самых больших окон приема новшеств, рекордное для ветки 3.х. По соотношению изменений не отмечается ничего необычного: 63% всех патчей касаются драйверов устройств (staging, networking, scsi, gpu, sound, drbd и т.д.), 18% относятся к поддержке архитектур (основная масса изменений касается платформ на основе ARM), а остальные изменения размазаны по различны подсистемам, таким как сетевая подсистема, файловые системы, include-файлам и т.п.
Среди принятых (http://lwn.net/Articles/528893/) новшеств (http://www.phoronix.com/scan.php?page=news_item&px=MTI1MzQ):- Прекращена (http://www.opennet.me/opennews/art.shtml?num=35582) поддержка процессоров 386-DX/SX. Целью подобного шага является желание упростить поддержку некоторых структур ядра, изменение которых затрудняет наличие дополнительного кода, необходимого для поддержки процессоров 386-DX/SX. Например, для работы на системах i386 в функции sync_core(), используемой для организация синхронизации в режиме SMP, необходимо обеспечить поддержку процессоров без CPUID (http://ru.wikipedia.org/wiki/CPUID);
- В состав ядра принята (http://www.opennet.me/opennews/art.shtml?num=35667) разработанная компанией Samsung файловая система F2FS (Flash-Friendly File System), ориентированная для использования на Flash-памяти;
- Добавлена (http://www.opennet.me/opennews/art.shtml?num=35636) большая порция улучшений и исправлений для файловой системы Btrfs;- В файловой системе XFS появился новый механизм верификации для выявления повреждённых данных при сбоях чтения с носителя;
- В файловой системе Ext4 добавлена поддержка inline-хранения данных, что позволяет значительно увеличить эффективность хранения очень мелких файлов за счёт размещения данных прямо внутри inode, что значительно сэкономит дисковое пространство;
- Проведена работа (http://www.opennet.me/opennews/art.shtml?num=35614) по ускорению криптографических операций (например, ускорены шифры camellia,cast5, serpent, twofish, cast6) с использованием набора команд AVX на новых процессорах Intel. Оптимизирована реализация crc32c;
- Приняты (http://www.opennet.me/opennews/art.shtml?num=35610) патчи с реализацией поддержки механизма "huge zero_page (http://lwn.net/Articles/517465/)", который в некоторых ситуациях позволит существенно (до 2.5 раз) сократить потребление физической памяти при включении в ядре поддержки Transparent Huge-Pages (THP). Huge zero_page расширяет возможности THP в направлении экономии пустых страниц памяти, для которых не выделяются реальные области физической памяти;- Поддержка (http://www.opennet.me/opennews/art.shtml?num=35605) DMA-BUF для V4L2, что позволит организовать совместное использование буферов между V4L2-драйверами и иными драйверами. Например, графический драйвер сможет забирать данные из буфера V4L2 напрямую, не совершая операций копирования;
- Реализация (http://www.opennet.me/opennews/art.shtml?num=35604) технологии A-Sync DMA Engines для драйвера Radeon, что
даст возможность GPU копировать или перемещать данные даже когда шейдерная часть занята рендерингом сцен;
- Добавление (http://www.opennet.me/opennews/art.shtml?num=35434) нового 2D-драйвера для платформ Tegra 2 и Tegra 3, созданного при поддержке компании NVIDIA;- В подсистему контроля простоя CPU (cpuidle (http://lwn.net/Articles/384146/)) добавлена возможность привязки к каждому из процессоров разных драйверов для управления параметрами CPU в зависимости от загруженности процессора. Подобное необходимо для обеспечения поддержки асимметричных архитектур, таких как big.LITTLE;
- Для гостевых систем под управлением Microsoft Hyper-V добавлен balloon-драйвер, позволяющий исключить дублирование идентичных областей памяти в разных виртуальных окружениях;
- При выполнение mmap() или через SYSV IPC приложение может самостоятельно определить необходимый размер страниц памяти (Huge-Pages);
- Для архитектуры x86 добавлена (http://lkml.indiana.edu/hypermail/linux/kernel/1212.1/01135.... поддержка горячего подключения/отключения базового CPU ("CPU0"), используемого при загрузке (ранее используемый для загрузки процессор не мог был в последующем отключен);
- Поддержка SoC Broadcom BCM281XX, Allwinner A1X, Samsung EXYNOS5440, а также плат USI Topkick, ZyXEL NSA-310 и MPL CEC4.- Поддержка контроллеров карт памяти Wondermedia SD/MMC и Realtek PCI-E SD/MMC;
- Поддержка (http://lkml.indiana.edu/hypermail/linux/kernel/1212.1/03373.... процессоров POWER8 с улучшенной поддержкой многопоточности (SMT, Simultaneous Multi-Threading), выпуск которых должен начаться в 2013 году;
- Поддержка (http://lkml.indiana.edu/hypermail/linux/kernel/1212.1/02293.... звуковых устройств: кодека VIA HD, устройств FastTrack C400 USB, PSC724 Ultiimate Edge, Stanton SCS.1d/1m FireWire, Freescale/iVeia P1022 и Maxim MAX98090;
- В драйвер hid-multitouch добавлена (http://lkml.indiana.edu/hypermail/linux/kernel/1212.1/02063.... поддержка мультитач протокола, используемого в Windows 8.
URL: https://lkml.org/lkml/2012/12/21/430
Новость: http://www.opennet.me/opennews/art.shtml?num=35682
> В файловой системе Ext4 добавлена поддержка inline-хранения данных, что позволяет значительно увеличить эффективность хранения очень мелких файлов за счёт размещения данных прямо внутри inode, что значительно сэкономит дисковое пространство;А я всегда считал, что основное отличие ext23 от ext4 именно в этом, и поэтому на ext4 меньше места на одном и том же занимается. Разве это не так?
Ты с экстентами попутал, которые для больших файлов полезны (тех что больше ~нескольких блоков на которые можно было сослатся прямо из иноды).
Нет друг, какраз наоборот, в ext2 это уже давно было а в ext4 только ввели
у ext2 оверхед больше. Если создать раздел на 1 гб и установить туда debian, то в случае с ext4 можно больше данных сверху записать.
> у ext2 оверхед больше. Если создать раздел на 1 гб и установить
> туда debian, то в случае с ext4 можно больше данных сверху
> записать.При ^has_journal
> у ext2 оверхед больше.В общем случае экстенты более эффективны. Хотя в клинических случаях возможна и обратная ситуация, но когда систему юзают а не пытаются завалить как мамонта - экстенты все-таки в среднем по больнице эффективнее. Плюс в ext4 иноды несколько грамотнее выделяются.
> и поэтому на ext4 меньше места на одном и том же занимаетсяТебя глючило. Основным отличием от ext3 у ext4 являются экстенты. Они позволяют компактно и быстро адресовывать большие регионы в файлах характерной структурой - собственно, экстентом. В ext4 такой регион может быть до 128Мб на одну запись. Это в общем случае работает намного быстрее чем ранее использовавшиеся методы, особенно на больших файлах. Файловая система может одним махом указать что большой кусок принадлежит конкретному файлу. Откуда наступает приличный профит при работе с большими файлами на больших томах vs более классические дизайны.
мои личные наблюдения по поводу ext2,3,4: http://www.opennet.me/openforum/vsluhforumID1/94103.html
> мои личные наблюдения по поводу ext2,3,4: http://www.opennet.me/openforum/vsluhforumID1/94103.htmlСкажите, а ваша фамилия случайно не Шишкин? Посмотрите на мир вокруг. Сколько объем типового винча? Ну или даже SSD? И что общее это имеет с диском в файле на 1Гб? Ясен фиг, в 2012 году мало кто оптимизирует поведение ФС под диск в 1 Гб. А то что до...ться можно даже до дверного косяка - никто и не сомневался.
Кстати, а что, использовать квоты - слишком просто и неспортивно? Порнуха с дирами в файле на гиг - чем-то лучше? Ну да, врядли кто-то оптимизировал ext4 под настолько ушибленные сценарии.
ну вот extfs и доэволюцинировала медленно до уровня reiser3.
в рейзере есть другая фича, это упаковка нескольких тейлов от разных файлов один кластер. И её обычно отключали, ибо слишком тормозило.
в ней еще баги неоднократно находили
> в ней еще баги неоднократно находилиА также в утилитах типа fsck, которые могут просто раздестроить том вместо починки. К счастью, до такой "фичи" ext4 недоэволюционировал :)
>> в ней еще баги неоднократно находили
> А также в утилитах типа fsck, которые могут просто раздестроить том вместо
> починки. К счастью, до такой "фичи" ext4 недоэволюционировал :)Да ладно, совсем недавно же было.
ага, только этот баг повторить ни кто не мог, так он проявлялся только при специфичных опциях монтирования и то не всегда
> ага, только этот баг повторить ни кто не мог, так он проявлялся
> только при специфичных опциях монтирования и то не всегдаУ меня тоже не получалось разрушить reiserfs при проверке. Хотя старался, даже питание вырубал.
> У меня тоже не получалось разрушить reiserfs при проверке.Зато например у авторов aMule успешно получилось. А если гуглануть - то окажется что при весьма скромном проценте внедрения reiserfs, воплей относительно успешного выигрыша в русскую рулетку оказыватеся довольно много.
Чтой-то у меня не нагугливается ничего.
> Чтой-то у меня не нагугливается ничего.Вас забанили в гугле? Оригинально! Ну вот например даже википедики так сходу знают: http://en.wikipedia.org/wiki/ReiserFS#fsck что намекает что по этим граблям кто-то уже попрыгал.
> Вас забанили в гугле?Нет, просто гугл не в курсе ваших веселых историй.
> Ну вот например даже википедики так сходу знают
Из авторитетных источников там только ссылка на Тео Цо. А слушать Тео по поводу рейзера - это все равно слушать Поттера про sysvinit и syslog.
> Нет, просто гугл не в курсе ваших веселых историй.Наверное и правда забанили. Ибо даже сами авторы reiser-а называли ситуации когда fsck может облажаться. Да-да, они в курсе. Например если на томе лежит образ иного диска в формате рейзера, его дерево с удовольствием будет заюзано. И том будет окончательно "починен". Ну а поскольку это было не его дерево - ну вы поняли. Никакой защиты от этого нет, авторы рекомендовали просто не класть образа дисков в рейзере на рейзер (на заметку гражданину с 1-гиговыми дирами в файлах-дисках). Нормальный такой подход, угу. "В некоторой ситуации у вас за спиной могут оказаться кирпичи вместо парашюта".
Вот только мне мои данные нужны пока еще. А fsck у рейзера как был не фонтан так никто его допиливать и не собирается. В отличие от многих других ФС.
> "В некоторой ситуации у вас за спиной могут оказаться кирпичи вместо парашюта"."Если вы сами их туда положили"
> "Если вы сами их туда положили"Не, в данном случае производитель парашюта это сделал. Так и написал - в некоторых ранцах иногда по ошибке лежат кирпичи. Мы в курсе, но ничего сделать не можем. Проверяйте содержимое до вылета.
>> в ней еще баги неоднократно находили
> А также в утилитах типа fsck, которые могут просто раздестроить том вместо
> починки. К счастью, до такой "фичи" ext4 недоэволюционировал :)Спорный вопрос. Вообще, интересно - если положить ext4 в виде файла на ext4, и потом запустить fsck, не повторится ли фейл рейзерфс?
fsck не интересуется содержимым файлов.
> fsck не интересуется содержимым файлов.А не кисло бы ему интересоваться. Хотя бы на уровне magic-label.
> Хотя бы на уровне magic-label.Внезапно, не у любого файла есть какой-либо magic number для понимания его типа.
это слишком костыльно и криво для стандартной тулзы восстановления, которая должна анализировать ошибки только с точки зрения формальной структуры фс.для эвристического восстановления существуют специальные тулзы (например, testdisk и ко), которые явно предупреждают о методах своей работы и, тем самым, не вводят в заблужедние пользователя.
> fsck не интересуется содержимым файлов.Что не мешает по ошибке перепутать метаданные фс внутри файла с метаданными основной фс.
By default, reiserfs stores small files and `file tails' directly into its tree. This confuses some utilities such as LILO(8). This option is used to disable packing of files into the tree.
Не вижу чтобы от разных файлов. Откуда инфа?
> Не вижу чтобы от разных файлов
>> упаковка нескольких тейлов от разных файловЧитать умеем? Ясно же человек написал про хвосты.
Ага. Только в мне ничего нет про хвосты от _разных_ файлов в _одном_ кластере.
в одном блоке может быть множество leaf-узлов с хвостами - никаких ограничений тут нет
> в одном блоке может быть множество leaf-узлов с хвостами - никаких ограничений
> тут нетГде такое написано и как это включить?
Написано тут http://filesystems.nm.ru/my/reiserfs_layout.pdf
Включить нужно лишь tail-packing
404
Скопировать вручную текст ссылки в браузер и перейти - не судьба? Ох, сколько глупых вопросов я предчувствую...
> а остальные изменения размазаны по различны подсистемамна столько качетвенные изменения, что прям "размазаны"? :)
>> а остальные изменения размазаны по различны подсистемам
> на столько качетвенные изменения, что прям "размазаны"? :)С другой стороны, то что они размазаны, вовсе не говорит о том, что они некачественные.
> С другой стороны, то что они размазаны, вовсе не говорит о том,
> что они некачественные.В конце концов, изменения - это не яйца и не помидоры.
Радеон 6850 на этом ядре показывает 20 кадров в unigine heaven и 310 кадров в Lightsmark 2008 в FullHD. Прирост в 4 и 1.7 раза соответственно.
Обгоняет проприетарный драйвер?
Не обгоняет пока. Проприентарный первый тест ЕМНИП 35 кадров, второй - 550.
> Радеон 6850 на этом ядре показывает 20 кадров в unigine heaven и
> 310 кадров в Lightsmark 2008 в FullHD. Прирост в 4 и 1.7 раза соответственно.Самое интересное пока вроде еще не сделали (асинхронные операции через DMA-кольца). Ну то-есть база для них готова но там еще юзермод надо менять, чтобы он мог этими ништяками пользоваться, как я понимаю. А вот это AFAIK еще не сделано.
стандартные вопросы: какие новые возможности, появившиеся в этой ветки ядра можно будет интегрировать и в другие ветки ядра (и как это будет зависеть от того, какая это ветка? (и это будет как, в очередных патчах к ним, или это каждый под себя должен будет делать сам?))
Если про BTRFS написано, что для нее не просто улучшения, а "большая порция улучшений и исправлений", то может ли быть тогда смысл все инсталляции делать уже на ней, а не например на EXT4? (или не все, а только какие-то определенные?)
Возможно ли сейчас заранее что-либо знать о том, в состав каких дистрибутивов "3.8" войдет? (и на каких уже установленных дистрибутивах будет смысл поменять ядро? (либо, если с чем на этот счет не возможно определиться сейчас, то тогда когда и при каких обстоятельствах по этому вопросу уже можно будет сориентироваться и определиться?))
Если в "3.8" все будет удачно, то сможет ли ее существование сократить сроки поддержки других веток ядра? (сколько стоит его написать и поддерживать?)
> Если про BTRFS написано, что для нее не просто улучшения, а "большая порция улучшений и исправлений", то может ли быть тогда смысл все инсталляции делать уже на ней, а не например на EXT4? (или не все, а только какие-то определенные?)Общие слова не могут быть критерием для принятия решения. Только конкретика. Там, кстати, линк был на конкретику.
Как я понял, в btrfs есть следующие не исправленные на данный момент недостатки:
- Переизбыток мета-данных: создаете нулевые файлы и у вас на ФС кончается место хотя кроме метаданных на томе вообще ничего нет
- Баг с колизиями
- Для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4И еще непонятно что там с fsck; некоторые говорят что он не нужен, но, ИМХО, это как-то странно.
C Brtfs все ясно, что не готова она, и пару версия ядра лучше еще подождать, а вот что там с F2FS? На нее можно систему установить? Как у неё со скоростью? По описанию-то славная вещь, чтобы SSD служил верой и правдой многие годы )
Похоже, еще доделывают - fsck.f2fs пока не готов.
> Похоже, еще доделывают - fsck.f2fs пока не готов.fsck.zfs тоже не готов, что не мешает энтузиастам использовать эту фс.
Эдак btrfs может вообще остаться не у дел. С одной стороны, есть простые и проверенные ext*, с другой - прогресс, неизбежные SSD и f2fs.
> Эдак btrfs может вообще остаться не у дел. С одной стороны, есть
> простые и проверенные ext*, с другой - прогресс, неизбежные SSD и
> f2fs.btrfs by design неплохо работает с SSD. Специфика cow + некоторые оптимизации. Конечно, не F2FS, но получше "проверенных" ext.
>получше "проверенных" ext.Вера, она такая. Морщины пользователя btrfs еще не научилась разглаживать? Файловая система, которая много лет "скоро будет совсем хорошей, через 2 версии ядра".
>>получше "проверенных" ext.
> Вера, она такая. Морщины пользователя btrfs еще не научилась разглаживать? Файловая система,
> которая много лет "скоро будет совсем хорошей, через 2 версии ядра".У айтишников вообще есть такое свойство - считать зрелой систему, которая сгнила, разложилась и высохла до выбеленных костей лет этак 10 назад. Когда она винтажем станет.
> Вера, она такая.А Клава - так и вообще!
> Морщины пользователя btrfs еще не научилась разглаживать?
Нет. У пользователей btrfs не появляется морщин: там где юзеры обычных ФС люто батхертят "ох я дебил, убил результат работы за день!", строя жуткие гримасы от которых появляются морщины, юзеры btrfs просто юзают ближайший подходящий снапшот и достают оттуда убитое. Поэтому разглаживать морщины им не требуется.
> Нет. У пользователей btrfs не появляется морщин: там где юзеры обычных ФС
> люто батхертят "ох я дебил, убил результат работы за день!", строя
> жуткие гримасы от которых появляются морщины, юзеры btrfs просто юзают ближайший
> подходящий снапшот и достают оттуда убитое. Поэтому разглаживать морщины им не
> требуется.Пользователи nilfs пользуются этой возможностью уже давно.
> Пользователи nilfs пользуются этой возможностью уже давно.Пусть пользуются. Кто-то против?
> - Переизбыток мета-данных: создаете нулевые файлы и у вас на ФС кончается место хотя кроме метаданных на томе вообще ничего нетЭто работает на _любой_ файловой системе, включая ext* И XFS.
> - Баг с колизиями
Баг с коЛизиями уже давно исправили.
> - Для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4
А по некоторым нагрузкам - есть отставание XFS от ext4.
А по некоторым другим - отставание ext4 от XFS.
Мораль - ext4 и XFS не готовы для продакшена.> И еще непонятно что там с fsck; некоторые говорят что он не нужен, но, ИМХО, это как-то странно.
ZFS уже много лет живет без fsck.
> ZFS уже много лет живет без fsck.Да, и периодически высплывают перлы типа того что на лисяре было, когда мужик чинил завалившуюся ФС хексэдитором. Просто парням из сана было главное впарить. А теперь писать утилиты для монстрилы такого уровня тупо некому, даже если бы и захотели.
> мужик чинил завалившуюся ФС хексэдитором.Заметим, это не мешает ей быть готовой для продакшена.
> Заметим, это не мешает ей быть готовой для продакшена....с точки зрения ушлых маркетологов из сана :)
>> Заметим, это не мешает ей быть готовой для продакшена.
> ...с точки зрения ушлых маркетологов из сана :)И сотен счастливых администраторов FreeBSD.
>И сотен счастливых администраторов FreeBSD.Сотен миллиардов счастливых администраторов FreeBSD, я настаиваю!
> И сотен счастливых администраторов FreeBSD....которым приходится выбирать из двух кактусов. Один побольше, второй поменьше. Оба колючие до безобразия.
>> Заметим, это не мешает ей быть готовой для продакшена.
> ...с точки зрения ушлых маркетологов из сана :)Вылазь из криокамеры. Она не только готова для продакшена, а уже лет 6 как вовсю там используется. Причем не в формате "экстракт из пересказа пересказов от BSD", а вполне себе от первоисточника.
> Вылазь из криокамеры. Она не только готова для продакшена, а уже лет 6 как вовсю там используется.Как же они без fsck, бедные?
> Как же они без fsck, бедные?Ну вот так. Когда надо на btrfs наехать - припоминают про fsck. Когда про ZFS - молчат в тряпочку. А когда не повезло - сношаются как на лисяре или просто пересоздают нафиг многодисковый пул с раскатыванием бэкапа, что доставляет много радости.
> Ну вот так. Когда надо на btrfs наехать - припоминают про fsck.
> Когда про ZFS - молчат в тряпочку. А когда не повезло
> - сношаются как на лисяре или просто пересоздают нафиг многодисковый пул
> с раскатыванием бэкапа, что доставляет много радости.Далеко не все так сношаются.
Адепты ZFS делятся на два вида:1. Рассказывают об опыте внедрения на промышленных системах из миллионов хостов под астрономическими нагрузками. (На самом деле, их опыт юзания фс ограничивается NTFS и FAT32 на локалхосте под уютной хрюшей/семеркой) Никогда не страдают от сбоев ZFS.
2. Молодые наивные юноши, допущенные к рутовой консоли серваков мелких фирм, и наслушавшиеся историй успеха от первых. Страдают от сбоев ZFS, но мужественно молчат, боясь показаться криворукими и посрамить честь родной фри.
> Как же они без fsck, бедные?У ZFS есть три инструмента:
* zpool import -F
* zpool scrub
* zdbzfs fsck, если таковой будет создан (по образу классических), останется тестирующей целостность ФС утилитой, интересной разработчикам, — не более. Видеть тонны собранного ей хлама с незначащими именами в каталогах /.lost+found каждой из ФС в пуле (а число ФС может быть несколько десятков) обычным пользователям неинтересно, так как scrub выдаёт более информативную информацию с точностью до имени проё-ого файла и полного пути к нему, что сокращает время восстановления хранилища в разы.
> У ZFS есть три инструмента:...среди которых ни одного аналога fsck. И почему-то наезжающие на btrfs упорно игнорируют что там похожий инструментарий есть. Даже утилитка для недеструктивного вытаскивания файлов.
> среди которых ни одного аналога fsck.Безусловно. scrub — это не аналог убогого fsck, а его прямая замена. Ибо пользователям важно знать, какие конкретно файлы нужно быстро восстановить из бэкапа по списку, любезно предоставленном scrub'ом, а не рыться и вынюхивать с помощью hex-редактора в "завалах" /.lost+found/ в поисках "осколков счастья", оставшихся от их повреждённых файлов.
> Безусловно. scrub — это не аналог убогого fsck, а его прямая замена.Ты уж определись: или уж fsck убогий и не нyжен, или уж нужен. А то у тебя правда варьируется в зависимости от того о какой ФС спич. Не комильфо, знаешь ли, когда мировоззрение индивида крутится как флюгер на ветру.
> Ибо пользователям важно знать, какие конкретно файлы нужно быстро восстановить из
> бэкапа по списку, любезно предоставленном scrub'ом, а не рыться и вынюхивать
> с помощью hex-редактора в "завалах" /.lost+found/ в поисках "осколков счастья", оставшихся
> от их повреждённых файлов.Ты только забыл что в btrfs тоже уже есть различных утилит восстановления. Вплоть до недеструктивной, вытаскивающей с сильно побитой ФС на другой носитель. Но это не мешает тебе истошно орать что в btrfs нету fsck когда речь о нем. Вот я и дивлюсь на такие двойные стандарты.
>> Безусловно. scrub — это не аналог убогого fsck, а его прямая замена.
> Ты уж определись: или уж fsck убогий и не нyжен, или уж нужен.А ты читай внимательнее, что я пишу. Или ещё не научился понимать из связных слов предложения?
> А то у тебя правда варьируется в зависимости от того
> о какой ФС спич. Не комильфо, знаешь ли, когда мировоззрение индивида
> крутится как флюгер на ветру.Не неси чушь.
>> Ибо пользователям важно знать, какие конкретно файлы нужно быстро восстановить из
>> бэкапа по списку, любезно предоставленном scrub'ом, а не рыться и вынюхивать
>> с помощью hex-редактора в "завалах" /.lost+found/ в поисках "осколков счастья", оставшихся
>> от их повреждённых файлов.
> Ты только забыл что в btrfs тоже уже есть различных утилит восстановления.
> Вплоть до недеструктивной, вытаскивающей с сильно побитой ФС на другой носитель.
> Но это не мешает тебе истошно орать что в btrfs нету fsck когда речь о нем. Вот я и дивлюсь на такие двойные стандарты.Никогда не орал, что "Btrfs нету fsck". Ты тщательнее следи за своими претензиями, особенно в тех случаях, к кому их предъявляешь. Иначе выйдет недоразумение и окажешься глупцом в собственных глазах.
> А ты читай внимательнее, что я пишу. Или ещё не научился понимать из связных слов предложения?Ты слишком хорошего мнения о той бредятине котрую ты обычно выдаешь.
> Не неси чушь.
Действительно, это твоя прерогатива.
> Никогда не орал, что "Btrfs нету fsck". Ты тщательнее следи за своими претензиями,
Я слежу. Вот например, http://www.opennet.me/openforum/vsluhforumID3/85076.html#79 - орал вполне себе в сторону btrfs - "Когда там появится fsck? Или не нужен? :))"
> особенно в тех случаях, к кому их предъявляешь. Иначе выйдет
> недоразумение и окажешься глупцом в собственных глазах.Ну, ты этого хотел - скушай. Я вон пруфлинк привел.
>> Никогда не орал, что "Btrfs нету fsck". Ты тщательнее следи за своими претензиями,
> Я слежу. Вот например, http://www.opennet.me/openforum/vsluhforumID3/85076.html#79
> - орал вполне себе в сторону btrfs - "Когда там появится
> fsck? Или не нужен? :))"Так я не перестаю спрашивать: "Когда там появится fsck? Или не нужен?"
Заметь: я не отвергаю и не принимаю fsck в Btrfs. Если разработчики озаботились его нужностью — пожалуйста. Я не против. Ведь это им решать, нужна ли эта утилита или не нужна. Я лишь спрашивал на тот момент: "Когда она будет в Btrfs?" Если будет (уже есть), то насколько ей можно доверять данные, не ломает ли она чего-нибудь по ходу? Не ломает — прекрасно, ломает — нафик она такая нужна?Касательно всяких тестирующих и ремонтирующих утилит ФС у меня есть мнение, что они должны писаться вместе с кодом ФС параллельно. Только так можно обеспечить синхронность действий и желаемых эффектов от их совместного применения. Если тестирующие и ремонтирующие утилиты откладываются "на потом", то с создаваемой ФС явно что-то не так. Ну, может и взлетит, но удастся ли ей нормально сесть в нештатном режиме?
>> особенно в тех случаях, к кому их предъявляешь. Иначе выйдет
>> недоразумение и окажешься глупцом в собственных глазах.
> Ну, ты этого хотел - скушай. Я вон пруфлинк привел.Ты опять не сумел понять то, что я написал.
> - Переизбыток мета-данных: создаете нулевые файлы и у вас на ФС кончается
> место хотя кроме метаданных на томе вообще ничего нетЭто не исправят никогда, поскольку природу не обманешь. Так будет происходить на вообще любой файловой системе. Хранение имени файла и прочих сведений ВНЕЗАПНО тоже требует некоего места. Просто потому что имена файлов и прочие сведения тоже должны где-то храниться и это занимает некое место.
Если вы создаете миллионы файлов, тогда миллионы имен файлов, их размеров, дат создания и прочая - внушительные горы метаданных. Они на любой ФС неизбежно или займут все место или упрутся в какие-то технические лимиты ФС на число файлов/директорий на томе. Для пользователя результат
Если вы не поняли, в эту игру выиграть нельзя. Совсем. Это был скаркастический пример того что претензии не совсем обоснованы.
> - Баг с колизиями
Починен. По крайней мере совсем обламываться теперь не будет. Тормозить при злонамеренном создании файлов вредителем - будет, конечно, но злонамеренными действиями тормознуть можно в общем то любую ФС.
> - Для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4
Не отнять. Но пилят хорошо.
> И еще непонятно что там с fsck; некоторые говорят что он не нужен,
Не знаю кто там говорит, но большинство линуксоидов гордые и не собираются пользоваться ФС без такового. По поводу чего авторам btrfs его пришлось сделать. Он пока еще сырой, но в отличие от некоторых других, он по крайней мере есть.
> он по крайней мере есть.Хороший эвфемизм для выражения "глючное гoвно", надо запомнить.
> "глючное гoвно"Шо ж ты так самокритично о себе?
> Хороший эвфемизм для выражения "глючное гoвно", надо запомнить.Даже "глючное гoвно" - лучше чем совсем никакого + маркетинговый буллшит в качестве компенсации.
> совсем никакого + маркетинговый буллшит в качестве компенсации.Тонкий намек на ZFS?
> Тонкий намек на ZFS?Вообще, он достаточно толстый. Но имеющий право на жизнь, имхо. Ибо все познается в сравнении.
>Не отнять. Но пилят хорошоСколько лет его уже пилят, c момента эпохального первого победного бенчмарка на Форониксе (летом 2010 кажись), где она порвала все файловые системы с десятикратным отрывом? тупо игнорируя fsync, ессно...
http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_...Линк кстати. Хоть и не уверен что именно тот обзор, но этот тоже хорош.
> http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_...
> Линк кстати. Хоть и не уверен что именно тот обзор, но этот тоже хорош."Published on July 27, 2010" хорош для чего, собственно? Любители протухших консервов такие любители...
> Любители протухших консервов такие любители...Это ты про BSD'шников?
> Это ты про BSD'шников?Действительно, у них там технологии консервируются в могильнике - сами они ничего вообще в ZFS кажется не улучшили. Только у остальных копипастят.
3.8 пока не появится ни в одном промышленном (коммерческом) дистрибутиве, что само по себе отвечает на все ваши вопросы. А со всеми остальными ветками и дистрибутивами вы можете упражняться как хотите. дело чисто ваше.
> 3.8 пока не появится ни в одном промышленном (коммерческом) дистрибутиве, что само
> по себе отвечает на все ваши вопросы. А со всеми остальными
> ветками и дистрибутивами вы можете упражняться как хотите. дело чисто ваше.Вообще-то, в промышленных дистрах есть традиция бэкпортировать наиболее востребованные изменения. Думаю, патчсет btrfs не избежит этой судьбы. Особенно в оракловском фирменном ведре.
> 3.8 пока не появится ни в одном промышленном (коммерческом) дистрибутивеНе совсем понятно с чего ради промышленный и коммерческий - синонимы. Есть дофига крупных инсталляций вполне промышленного масштаба которые никому ничего за это не платили.
>> 3.8 пока не появится ни в одном промышленном (коммерческом) дистрибутиве
> Не совсем понятно с чего ради промышленный и коммерческий - синонимы. Есть
> дофига крупных инсталляций вполне промышленного масштаба которые никому ничего за это
> не платили.Чтобы промышленной системе жить без внешней поддержки - необходимо иметь собственную, внутреннюю поддержку.
Ну или выгодно договориться "мы вам пиар, вы нам поддержку".
> Чтобы промышленной системе жить без внешней поддержки - необходимо иметь собственную,
> внутреннюю поддержку.И что? Довольно многие справляются своими силами. Что впрочем не мешает редхату процветать за счет продаж поддержки. Однако если посмотреть на рыночную долю - у редхата она невелика. Просто они окучивают наиболее жирные ынтырпрайзы.
> И что? Довольно многие справляются своими силами. Что впрочем не мешает редхату
> процветать за счет продаж поддержки. Однако если посмотреть на рыночную долю
> - у редхата она невелика. Просто они окучивают наиболее жирные ынтырпрайзы.Ну дык те, которые без поддержки (не только редхатовской, но также новеловской и оракловской, или собственной) - те, собсно, не ынтырпрайзы, а так, мелкие лавочки, которые никому ничего не гарантируют.
> мелкие лавочки, которые никому ничего не гарантируют.Получается что гугл, фэйсбук или википедия - мелкие лавочки, которые никому ничего не гарантируют. Правда если они гавкнутся - попаболи у юзерья будет больше чем по поводу отвала какого-нибудь банка.
Добавление нового 2D-драйвера для платформ Tegra 2 и Tegra 3, созданного при поддержке компании NVIDIA;Этож ванильное ядро, зачем это.
> Этож ванильное ядро, зачем это.Затем что работать должно сразу. А не после прыжков с бубном. И даже нвидия кажется стала это понемногу понимать, а хотя-бы и после гостеприимного жеста от мистера Торвальдса.
вот что чле^Wпалец животворящий делает!
>> Этож ванильное ядро, зачем это.
> Затем что работать должно сразу. А не после прыжков с бубном. И
> даже нвидия кажется стала это понемногу понимать, а хотя-бы и после
> гостеприимного жеста от мистера Торвальдса.Тегра - это как бы не видяха. Не совсем видяха, если быть точной.
А с видяхами там по-прежнему все печально.
> Тегра - это как бы не видяха. Не совсем видяха, если быть точной.Тегра - это как бы SoC, в котором встроена в том числе и видяха. Хоть и немного другая. Но Торвальдс высказался про "компанию нвидия вообще", если что.
> А с видяхами там по-прежнему все печально.
Ну да, потому что нвидия поняла все как-то по своему. Ну в общем еще пару факов от Торвальдса - и может допрет :)
Так кто теперь няшнее, XFS или ext4?
> Так кто теперь няшнее, XFS или ext4?Забенчите под вашими нагрузками да посмотрите.
>> Так кто теперь няшнее, XFS или ext4?
> Забенчите под вашими нагрузками да посмотрите.Какие нагрузки на фс могут быть на локалхосте?
>>> Так кто теперь няшнее, XFS или ext4?
>> Забенчите под вашими нагрузками да посмотрите.
> Какие нагрузки на фс могут быть на локалхосте?Антивирус Касперского, это же очевидно.
>>>> Так кто теперь няшнее, XFS или ext4?
>>> Забенчите под вашими нагрузками да посмотрите.
>> Какие нагрузки на фс могут быть на локалхосте?
> Антивирус Касперского, это же очевидно.Надо форониксу подкинуть идею. Если он, конечно, осилит установить касперыча на убунту.
> Надо форониксу подкинуть идею. Если он, конечно, осилит установить касперыча на убунту.Пусть ClamAV ставят. А что, вполне себе бенч.
> Пусть ClamAV ставят. А что, вполне себе бенч.Ага, поставил один такой спец себе clamav. В результате появился принципиально новый "антивирус попова".
Вот еще "антивируса фороникса" нам не хватало.
> Какие нагрузки на фс могут быть на локалхосте?Да любые. Хоть видеомонтаж или файлопомойка на всю окрестную локалку.
> Так кто теперь няшнее, XFS или ext4?Кто сильнее - слон или кит?
муравей
> муравейБактерии. Трупы слона, кита и муравья будут ими зохаваны совершенно одинаково. В перспективе - наноботы. То же самое, но более адресно и осмысленно и не обязательно трупы.
> Так кто теперь няшнее, XFS или ext4?btrfs, конечно же.
Кто-нибудь знает, будут там программы для проверки F2FS на ошибки и их исправление?
> Кто-нибудь знает, будут там программы для проверки F2FS на ошибки и их
> исправление?В ядре? Нет, не будут.