Новое подробное описание initramfs.

Переводить статьи - хорошая идея. ИМХО надо сначала перевести все интерфейсы программ на русский. Чем и занимаюсь в Launchpad. Одна проблема - я не вхожу в русскую команду переводчиков. Поэтому могу только предлагать варианты перевода. А сама команда вносит изменения с огромными тормозами. Из 16 переводчиков на мой мэйл откликаются в лучшем случае 3. (((

> технологии ядра Линукс 2.6 2.6? в 2.2 ЕМНИП уже было, может раньше.

Верно. Но проблема, как обычно несколько шире. В теме документирования объем работы очень большой. Основная проблема, что нет - единой концепции универсального документирования. По сути, с определенной точки зрения - любая статья направлена на устранение недостатков исходной документации. Получается, что статьи вред - так как увеличивают сущности. Человек вынужден копаться в разрозненной документации, тратить время на поиск, из-за недостатков родной документации.

Сейчас есть несколько недостаточно удобных систем документирования. Некоторые - следствия "досетевого состония". По идее желательна универсальная система, которая будет учитывать возможность удобного перевода и его представления, коллективной работы над документацией, единый формат.

Возможно, это должно быть нечто наподобие wiki, которая может генерировать хмl. Может быть есть нечто подобное. Есть еще идеи?

> технологии ядра Линукс 2.6 2.6? в 2.2 ЕМНИП уже было, может раньше.

Не знаю, старался переводить дословно. Можно уточнить, когда в ядро добавили initramfs.

Перевожу 3 абзац.

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

у меня вопрос есть. Я просто хотел перевести статьи IBM'овские и выложить их у себя на сайте, с указанием копирайтов и где искать оригинал, соответственно. Так вот хотелось бы узнать - необходимо спрашивать разрешение у автора статьи на перевод или нет? :)

Хм... с одной стороны согласен, с другой нет. Согласен с тем, что чем больше человек занимается ИТ, тем лучше он владеет языком. Несогласен - потому как иной раз приятней читать доку на родном языке, плюс ко всему есть начинающие люди, которым хотелось бы узнать больше, чем написано в книгах а-ля "Лялих для чайников" :), но нет языковых познаний.

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

Собственно, данная тема, на мой взгляд, интересна - часто это то тонкое место, как продолжается старт системы. Все помнят извечный вопрос про ошибку "Kernel panic - No init found" :) .

Полностью согласен, но эта статья - она не дает полного ответа на этот вопрос... :) Можно попробовать описать это более подробно.

сделал бы вику какую для этих целей чтоли...

>Полностью согласен, но эта статья - она не дает полного ответа на этот вопрос... :)

Мне попадались описания этого в сети, насколько помню.

Собственно, меня больше, как раз сейчас initramfs интересует.

> Переводить статьи - хорошая идея. ИМХО надо сначала перевести все интерфейсы программ на русский. Чем и занимаюсь в Launchpad. Одна проблема - я не вхожу в русскую команду переводчиков. Поэтому могу только предлагать варианты перевода. А сама команда вносит изменения с огромными тормозами. Из 16 переводчиков на мой мэйл откликаются в лучшем случае 3. (((

Пожалуйста свяжитесь со мной (https://launchpad.net/people/alexey-molchanov) и я включу вас в "Ubuntu Russian Translators" team. Странно, но никаких e-mail'ов я от вас вроде никогда не получал.

Забыл залогиниться, это был я. :)

>сделал бы вику какую для этих целей чтоли...

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

Самое смешное, что основная проблема в моем проекте, как было документирование - так и осталась...

Была бы документация в действительно нормальном виде - мне самому было бы гораздо проще.

Например - LFS - весь описан в XML - удобно. Я сделал уже давно шаблон XML - все работает - только материал добавляй. Описание ядра на русском пока сделал/взял(еще где-то - добавил) примерно на половину. Здесь вопрос - какой в этом смысл - когда правильнее если бы документация самого ядра подразумевала разные языки - так это было бы удобнее. Нет общей системы документирования.

Тут можно возразить - кто ядро собирает - ему перевод не нужен. Верно. Мне не особо нужен. Однако, когда описание всей системы - как ее собрать, сконфигурировать, как получить преимущества за счет всяких мелочей - на русском, что естественно - то как-то нездорово исключать описание, как лучше для конкретной системы конфигурировать ядро и почему. Оставлять на английском? Не выход. Да и нет нормального на английском. Лучшее общее - пожалуй то неполное, что с конфигуратором ядра.

Перевел я описание buildroot давно уже. Так оно просто в html - так в оригинале было, и то его они не сами в uClibc делали. Опять же это не совсем то. Далеко не то. И так далее...

Вот все из таких кусочков и состоит. Ну сделаем мы сейчас wiki... Будет у нас некая БД - с разрозненными разномастными описаниями частей. Как информацией даже из этой wiki пользоваться в системе, которая не подключена никуда еще... В каком-нибудь проекте типа KDE целая система выстроена документирования :) . А тут без плана пытаться сделать не понятно что...

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

Мне нужно примерно так - блок завершен - описание внесено в документацию родную для системы. Все. Такого пока не находится. Было бы - все бы было гораздо быстрее. Собственно, в этом основная сложность - красивую систему можно сделать - четко оправдав выбрасывание лишнего и "затяжку болтов" через описание - а если этого нет - везде разброд и шатание - отсутствие стандартов общих для всех - появление новых технологий - развитие и изменение непосредственно составляющих проектов... вобщем бессмысленное занятие - одному за этим угнаться.

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

Вобщем пока, если совсем грубо - или wiki или xml.

Ничего себе "подробная"! Статья куцая совершенно - ни малейшего намёка на то, как включать файлы в initramfs, ни про klibc - ни слова.

Вы уж фильтруйте анонсы

"в кэш памяти ядра" - русский моя родная языка?

"которая включает первоначальную корневую файловую систему и позволяет разместить инициализирующую программу в кэш памяти ядра"

Oй. Читал новости по диагонали и натолкнулся на "разместить инициализирующую программу в кэш памяти ядра". Первая ассоциация - найден способ расместить программу в кеш памяти ядра ПРОЦЕССОРА ;) Полез в исходник.

InMHO: поменяй на "разместить инициализирующую программу в кэш памяти ядра _Linux_". Ассоциации по умолчанию в русском и английском для некоторых терминов слегка различаются. В аглицком есть чёткая разница между терминами (kernel vs core) в русском нужен чёткий контекст к слову "ядро".

>Ничего себе "подробная"! Статья куцая совершенно - ни малейшего намёка на то, как включать файлы в initramfs, ни про klibc - ни слова.

Перевод заголовка там неправильный.

Правилное название - "Введение в initramfs ...." или "Знакомство(первое) с initramfs ...." на усмотрение главреда ;)

Угу :). Сию минуту поправим-с :).

>Первая ассоциация - найден способ расместить программу в кеш памяти ядра ПРОЦЕССОРА ;)

:) Вобще-то.. способ такой есть и найден довольно давно - но эт, конечно, из другой оперы :).

>"в кэш памяти ядра" - русский моя родная языка?

Хорошо, как лучше на Ваш взгляд?

>>"в кэш памяти ядра" - русский моя родная языка?

>Хорошо, как лучше на Ваш взгляд?

м.б. "кэш-памяти" ?

Я пока не понял, что там товарища вообще смутило.

Обычно такие слова пшутся через дефис, на сколько я знаю. Если на это обращать внимание :)

>м.б. "кэш-памяти" ?

Вот как раз и нет ;) Точнее кеш-память это из другой оперы. Там речь идёт о кеше который выделяется в памяти ядра.

>Обычно такие слова пшутся через дефис, на сколько я знаю. Если на это обращать внимание :)

1) кеш - это (алгоритмический) способ хранения данных и доступа к ним. http://en.wikipedia.org/wiki/Cache

2) кеш-память это аппаратная реализация п1. Например http://en.wikipedia.org/wiki/CPU_cache

В данном конкретном случае речь идёт о п1

Хм... :) я не против написать через дефис. Меня, прямо скажем, теперь заинтересовало правило, по которому такие слова надо писать через дефис.
Вообще, в оригинале так:

>This technical article introduces initramfs, a Linux 2.6 feature that enables an initial root filesystem and init program to reside in the kernel's memory cache,...

Кэш - и так память по определению, если не уточняется иное. В оригинале есть слово _память_ отдельно - _memory_. Ситуация осложняется тем, что кэш - слово заимствованное. Я бы тогда написал просто в кэш/е ядра :). Интересно само слово "кэш" уже внесено в русский язык и если да, то склоняется ли оно? :) Я бы не стал.

Вот более неудобный момент связан со словом _встроенный_. Ясно о чем речь. _Встроенный Линукс_, например, встречается часто - embedded. Но это же... :) или - для _встроенных/встраиваемых_ систем. Это что встраиваемый в нишу шкаф что ли :) ?

То же самое с Линукс/ом - это всего лишь ядро GNU (- ? :) ) систем, временно :) используемое сообществом свободных (! :) еще одна формулировка - от чего свободных? :) ) программистов. Так нет - у нас теперь все называется Линукс/ом... да и у них...

Про неоднозначность аббревиатуры GNU is Not Unix - вообще лучше не говорить... Много, много чего нехорошо даже в таких "мелочах"...

Однако, ядро Линукс на сколь-нибудь определенном временном отрезке долго не продержится, как и _встроенные системы_ :) - поэтому "голову можно не забивать" :) .

А, понял. Спасибо :)

>Я бы тогда написал просто в кэш/е ядра :).

В ядре несколько кешей. Нужно указывать в каком из ;)

Если следовать sS, то лучше написать "кэш в памяти".

>1) кеш - это (алгоритмический) способ хранения данных и доступа к ним. http://en.wikipedia.org/wiki/Cache
2) кеш-память это аппаратная реализация п1. Например http://en.wikipedia.org/wiki/CPU_cache
В данном конкретном случае речь идёт о п1

domenick> Кэш - и так память по определению, если не уточняется иное.

Хех. Оказывается не по определению :). Вобще как-то сразу стали терзать смутные сомнения на этот счет.

Вот пара ключевых абзацев для понимания технологии:

A few years ago, Linus Torvalds had a neat idea: what if Linux's cache could be mounted like a filesystem? Just keep the files in cache and never get rid of them until they're deleted or the system reboots? Linus wrote a tiny wrapper around the cache called "ramfs", and other kernel developers created an improved version called "tmpfs" (which can write the data to swap space, and limit the size of a given mount point so it fills up before consuming all available memory). Initramfs is an instance of tmpfs.

These ram based filesystems automatically grow or shrink to fit the size of the data they contain. Adding files to a ramfs (or extending existing files) automatically allocates more memory, and deleting or truncating files frees that memory. There's no duplication between block device and cache, because there's no block device. The copy in the cache is the only copy of the data. Best of all, this isn't new code but a new application for the existing Linux caching code, which means it adds almost no size, is very simple, and is based on extremely well tested infrastructure.

A system using initramfs as its root filesystem doesn't even need a single filesystem driver built into the kernel, because there are no block devices to interpret as filesystems. Just files living in memory.

Просто нужно для себя это перевести до конца и уже тогда будет понятно "кто на ком стоял" чтобы сделать адекватный перевод.

Вопрос стал выглядеть, как требующий отдельного прояснения и подробного разбирательства ;) .

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

Ясно. (Смотри выше :) ) . sS - предупреждать надо, что ты волшебник или мысли читаешь :) .

> 1) кеш - это (алгоритмический) способ хранения данных и доступа к ним.
> http://en.wikipedia.org/wiki/Cache
> 2) кеш-память это аппаратная реализация п1. Например
> http://en.wikipedia.org/wiki/CPU_cache

imho, если вы точно знаете о чем идет речь, то что вам мешает уточнить при помощи контекста, что вы имеете в виду?
например:
1. кэш память процессора;
2. кэш память ядра Linux.
легко различимы.

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

Дык до конца статью переведи. Всё на свои места сразу встанет. Там общие идеи раскрыты довольно подробно. Просто нужно в русском переводе более подробно раскрывать терминологию а не переводить дословно.

Конкретно про кеш еще одна выдержка из статьи:

"Linux copies data to and from the ramdisk into the "page cache" (for file data), and the "dentry cache" (for directory entries)"

По русски первый кеш это "кеш страниц память" а второй это "кеш элементов структуры файловой системы"(не знаю как это перевести менее громоздко ;))

>imho, если вы точно знаете о чем идет речь, то что вам мешает уточнить при >помощи контекста, что вы имеете в виду? >например: >1. кэш память процессора; >2. кэш память ядра Linux. >легко различимы.

Мне для этого пришлось залезть в оригинал ;)

В аннонсе по крайней мере нужно чётко указывать контексты. В статье их можно опускать по мере введения терминологии.

> То же самое с Линукс/ом - это всего лишь ядро GNU (- ? :) ) систем, > временно :) используемое сообществом свободных (! :) еще одна > формулировка - от чего свободных? :) ) программистов. Так нет - у нас > теперь все называется Линукс/ом... да и у них...

Linux - это ядро. А системы, построенные на его основе обычно называют GNU/Linux системами. Свободные - значит свободные для использования _любым_ желающим, в _любых_ целях. Но так же, свободные от имущественных прав авторов, кроме авторского права, на их интеллектуальную собственность - авторы при помощи copyleft передают свое ПО обществу, закрепляя за этими программами их дальнейшую свободу при помощи текстов лицензий copyleft (GNU GPL - copyleft). Это чтобы это ПО нельзя было в последствии отобрать (чтбы автор, или тот, кому он передаст/продаст авторские права, не смог отобрать уже выпущенное под copyleft ПО). Поскольку законодательные системы многих стран используют именно понятия интеллектуальной собственности и авторского права, сообществу GNU пришлось укладываться именно в эти законодательные рамки, чтобы предоставить ПО в свободное пользование и одновременно не дать закрыть уже открытые исходники или нажиться на них недобросовестным перепродавцам.

Хотя, вот тут http://action.nclug.ru/comment.php?comment.news.10 меня громко оспаривали... почитайте, там я приводил разные ссылки по теме.

> Про неоднозначность аббревиатуры GNU is Not Unix - вообще лучше не > говорить... Много, много чего нехорошо даже в таких "мелочах"...

А что в аббривеатуре GNU нехорошего?

// greyork

>Дык до конца статью переведи. Всё на свои места сразу встанет. Там общие идеи раскрыты довольно подробно. Просто нужно в русском переводе более подробно раскрывать терминологию а не переводить дословно.

Я стараюсь перевести, я очень стараюсь :). А некоторые, кто уже все перевел - так жадины и не прислали ничего (об этом собственно и было сообщение) :) .

>По русски первый кеш это "кеш страниц память" а второй это "кеш элементов структуры файловой системы"(не знаю как это перевести менее громоздко ;))

:) Здесь ясно.

Опять же гугль считает _кэш_ лучше писать, а не _кеш_... Я сейчас переосмыслил о чем вообще речь :) - sS чет ты как-то изначально все запутал. В сообщении явно речь о Линукс ядре идет и о кэш памяти этого ядра - я так сразу и написал - к чему мы и пришли снова :) , кэш память процессора там никоим образом не упоминается.


И вообще
>По русски первый кеш это "кеш страниц память"

Подозрительная формулировка :) .

из оригинала статьи так и не догнал: "...and the "/init" program from initramfs is run as a real init, with PID 1. (If initramfs's init needs to hand that special Process ID off to another program, it can use the exec() syscall just like everybody else.)..." получается что никаких заморочек с тем, чтоб перекинуть pid=1 на init c реально-монтируемой ФС не будет, так ли это?

кстати, возник еще такой вопрос, есть ли необходимость каким-либо образом выгружать initramfs, примерно так же как отмонтируется /initrd?

>И вообще >>По русски первый кеш это "кеш страниц память" >Подозрительная формулировка :) .

Это очепятка ;) s/ь/и/

Речь идёт о данных (содержании) файлов, а храняться эти данные именно в "кеше страниц памяти" или страничном кеше (page cache)

>Linux - это ядро.

Слава небесам, хоть с этим никто не спорит.

>А системы, построенные на его основе обычно называют GNU/Linux системами

В том то и дело, что не обычно. Обычно GNU куда-то теряют. Что серьезно принижает роль FSF. А должно было бы быть, как раз наоборот. gcc и несколько других не менее важных пакетов разрешают Линукс.

>Свободные - ...

:) Ну спасибо. Теперь буду знать.
А то я все как-то про свободу, да про свободу...

>А что в аббривеатуре GNU нехорошего?

Мне, например, не нравится :).

Вообще много нехорошего, вот сходу
здесь про акронимы http://ru.wikipedia.org/wiki/Акроним,
здесь про GNU http://ru.wikipedia.org/wiki/GNU,
1. Ты сможешь быстро и просто обычному человеку рассказать, как расшифровывается ГНУ и почему название такое?
2. В названии заключена иная аббревиатура - UNIX,
3. Рекурсивное название (в акрониме используется буква собственного названия) - неоправдано сложно,
4. Название построено как отрицание,
5. Отрицание определенной конкретной системы,
6. В реальности не является четким акронимом - могло бы быть GINU,
7. Не содержит объяснения или ключевой идеи...

И так далее... еще можно довольно много указать, если покопаться. Естественно, что людям удобнее говорить Линукс. Понятно почему, да?
Вот поэтому GNU и неудобное.

>Это очепятка ;) s/ь/и/

Это ясно, что очепятка была... :) Я вообще про "кэш страниц памяти".

Вот это осталось перевести - есть желающие на части :) ?

ramdisk vs ramfs

A ramdisk (like initrd) is a ram based block device, which means it's a fixed size chunk of memory that can be formatted and mounted like a disk. This means the contents of the ramdisk have to be formatted and prepared with special tools (such as mke2fs and losetup), and like all block devices it requires a filesystem driver to interpret the data at runtime. This also imposes an artificial size limit that either wastes space (if the ramdisk isn't full, the extra memory it takes up still can't be used for anything else) or limits capacity (if the ramdisk fills up but other memory is still free, you can't expand it without reformatting it).

But ramdisks actually waste even more memory due to caching. Linux is designed to cache all files and directory entries read from or written to block devices, so Linux copies data to and from the ramdisk into the "page cache" (for file data), and the "dentry cache" (for directory entries). The downside of the ramdisk pretending to be a block device is it gets treated like a block device.

A few years ago, Linus Torvalds had a neat idea: what if Linux's cache could be mounted like a filesystem? Just keep the files in cache and never get rid of them until they're deleted or the system reboots? Linus wrote a tiny wrapper around the cache called "ramfs", and other kernel developers created an improved version called "tmpfs" (which can write the data to swap space, and limit the size of a given mount point so it fills up before consuming all available memory). Initramfs is an instance of tmpfs.

These ram based filesystems automatically grow or shrink to fit the size of the data they contain. Adding files to a ramfs (or extending existing files) automatically allocates more memory, and deleting or truncating files frees that memory. There's no duplication between block device and cache, because there's no block device. The copy in the cache is the only copy of the data. Best of all, this isn't new code but a new application for the existing Linux caching code, which means it adds almost no size, is very simple, and is based on extremely well tested infrastructure.

A system using initramfs as its root filesystem doesn't even need a single filesystem driver built into the kernel, because there are no block devices to interpret as filesystems. Just files living in memory.

Initrd vs initramfs

The change in underlying infrastructure was a reason for the kernel developers to create a new implementation, but while they were at it they cleaned up a lot of bad behavior and assumptions.

Initrd was designed as front-end to the old "root=" root device detection code, not a replacement for it. It ran a program called "/linuxrc" which was intended to perform setup functions (like logging on to the network, determining which of several devices contained the root partition, or associating a loopback device with a file), tell the kernel which block device contained the real root device (by writing the de_t number to /proc/sys/kernel/real-root-dev), and then return to the kernel so the kernel could mount the real root device and execute the real init program.

This assumed that the "real root device" was a block device rather than a network share, and also assumed that initrd wasn't itself going to be the real root filesystem. The kernel didn't even execute "/linuxrc" as the special process ID 1, because that process ID (and its special properties like being the only process that can not be killed with "kill -9") was reserved for init, which the kernel was waiting to run after it mounted the real root filesystem.

With initramfs, the kernel developers removed all these assumptions. Once the kernel launches "/init" out of initramfs, the kernel is done making decisions and can go back to following orders. With initramfs, the kernel doesn't care where the real root filesystem is (it's initramfs until further notice), and the "/init" program from initramfs is run as a real init, with PID 1. (If initramfs's init needs to hand that special Process ID off to another program, it can use the exec() syscall just like everybody else.)

>> Linux - это ядро.
> Слава небесам, хоть с этим никто не спорит.
...
>> Свободные - ...
> :) Ну спасибо. Теперь буду знать.
> А то я все как-то про свободу, да про свободу... 

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

А про "GNU - GNU is Not UNIX"... "GNU - это не коммерческий UNIX" вполне 
себе звучит :) Просто раньше под UNIX'ами понимали только коммерческие 
системы и даже в наше время нельзя назвать ни одной свободной UNIX-like 
системы, кроме Solaris, имеющей право называться UNIX. Ибо по прежнему 
copyright...

//greyork

>> А что в аббривеатуре GNU нехорошего?

> Мне, например, не нравится :)

Объясняю. Аббревиатура GNU - это юмор такой, юмор. :) Придумана РМСом нарочно, в пику разным корпоративным биомеханоидам без ч/ю.

И судя по вашей бурной реакции, задумка таки удалась. ;)

>Ну, извините - я думал вы вопрос задавали, когда писали (цитирую вас):
Вопрос я, да... :), задавал. В контексте ответа Вы на вопрос, конечно, достаточно верно ответили. Однако, так как я "не первый год в спорте" для меня этот вопрос - риторический.

>Объясняю. Аббревиатура GNU - это юмор такой, юмор. :)

А что делать людям без чувства юмора - типа меня...

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

Угу. Я думаю более умно не переводить а написать свой комментарий и указать неочевидные места и уточнения.