LINUX.ORG.RU

The 2006 Linux File Systems: день второй и третий


0

0

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

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

День Второй: Идеи
-----------------
Второй день начался с поломки лампы проектора что было здорово для нас поскольку препятствовало использованию очень скушного slideware (прим перев - видимо имеется ввиду софт для презентаций). Мы приписали часть удивительной продуктивности конфы отсутствию проектора и факту, что большинство из нас не имели никакой сетевой связи из комнаты конференций, что заставило нас уделить внимание происходящему а не чтению почты.

Второй день был посвящён обсуждению интересных идей в архитектуре ФС. Нам повезло с присутствием экспертов в главных ФС (ext2/3, reiserfs, XFS, JFS) также как экспертов в других ФС (OCFS2, Lustre, ZFS) и конечно символический представитель подсистемы ввода-вывода (SCSI).

Для начала краткий обзор наших целей. Нам нужна ФС которая легко обнаруживает и исправляет дисковую порчу без перевода ФС в офф-лайн на часы или дни. Мы особенно не хотим терять целую ФС или её большие куски кода портится малая часть диска. Восстановление ФС должно занимать много меньше времени чем откат из бекапа; фактически мы должны проектировать размещение ФС с производительностью fsck в уме, а не просто производительностью ФС. Эти цели могут быть выражены как "repair-driven file system design" - проектирование нашей ФС для быстрого и лёгкого востановления с самого начала, а не допиливание впоследствии.

Мы также хотим избежать двойной записи, перевыделения блоков на каждую запись и слишком сложных реализаций, которые трудны для понимания и способствуют багам (прим перев - "keep it simple stupid" - одна из основополагающих идей UNIX является одним из главных условий создания новой ФС :) ). Мы хотим эффективно хранить маленькие файлы и с другой стороны желаем пожертвовать дисковым пространством в угоду надёжности. Мы можем воспользоваться кешируемыми дисковыми треками и сфокусироваться на уменьшении числа поисков вместо расположения данных точно последовательно.

★★
Ответ на: комментарий от filin

> ...Иноды в Директорных Входах

Я хочу выразить благодарность за перевод, и высказать пожелание. Как я понимаю, речь идёт о Directory Entries, мне было крайне трудно читать перевод этого устойчивого термина как "директорный вход". Здесь вместо "вход" гораздо больше подходит термин "запись". Да и само слово "директорная", это какой-то прямолинейный перевод, скорее подошло бы слово "каталожная". Получается "каталожная запись", что означает "запись в каталоге", что даже соответствует истине. Т.е. я не проф. переводчик, но чтение "директорных входов" мне постоянно приходилось транслировать мысленно, чтобы понять о чём речь. Про иноды ничего не скажу, для меня это устойчивая калька.

Casus ★★★★★
()
Ответ на: комментарий от Casus

> Как я понимаю, речь идёт о Directory Entries, мне было крайне трудно читать перевод этого устойчивого термина как "директорный вход". Здесь вместо "вход" гораздо больше подходит термин "запись". Да и само слово "директорная", это какой-то прямолинейный перевод, скорее подошло бы слово "каталожная". Получается "каталожная запись", что означает "запись в каталоге", что даже соответствует истине. Т.е. я не проф. переводчик, но чтение "директорных входов" мне постоянно приходилось транслировать мысленно, чтобы понять о чём речь.

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

filin ★★
() автор топика
Ответ на: комментарий от filin

обшибся немного, суперблоком принято называть маджик намбер плюс несколько других параметров, в ext2 (http://www.linux-tutorial.info/modules.php?name=Tutorial&pageid=274), битмапы инодов, блоков и таблица инодов идут сразу за ним, но не входят в суперблок, а каталог находится и вовсе в специальных directory files (http://www.linux-tutorial.info/modules.php?name=Tutorial&pageid=277). Это в s5fs битмапы были в суперблоке, а список инодов с названиями файлов находился сразу за суперблоком, именно это я и назвал неправильно суперблоком, впрочем в наследниках s5fs (как в ext2, например) каталог расположен всё равно не здесь, а в directory files, которые лучше назвать файлами каталога, что позволяет иметь неограниченное число файлов в разделе (что не позволяла s5fs).

filin ★★
() автор топика
Ответ на: комментарий от Casus

я бы оставил Directory Entries на английском ибо "каталожная запись" ничем не лучше "Директорных Входов"

cvv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.