LINUX.ORG.RU

Ext3, накладные расходы


0

1

Только только стал счастливым обладателем двух братьев-близнецов x 1Тб жёстких дисков. Конечно же чем дальше в лес - тем количество битов в байте всё меньшает, на наклейке гордо красуется надпись 1000Гб, а на деле размер - 931Гб (1 триллион байтов / 1Гб). Но не об этом сейчас речь.

Каждый жёсткий диск был разбит идентично: 1 примари раздел, на котором заколосилась ext3. Место для суперпользователя не отводилось. В результате разделы стали по 916.9Гб.

Отсюда вопрос: это нормально что на накладные расходы ушло 14Гб драгоценного пространства? Каким образом эту цифру можно уменьшить?

★★★★★

Re: Ext3, накладные расходы

По случаю отпуска у телепатов прилагается следующий текст:

# dumpe2fs -h /dev/sda1
dumpe2fs 1.40.2 (12-Jul-2007)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          1ccaae55-b410-4cd8-989c-0821c37043d4
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed directory hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122109952
Block count:              244190000
Reserved block count:     0
Free blocks:              240306875
Free inodes:              122109941
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      965
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Tue May 13 21:28:05 2008
Last mount time:          Tue May 13 21:37:55 2008
Last write time:          Tue May 13 21:56:11 2008
Mount count:              1
Maximum mount count:      500
Last checked:             Tue May 13 21:28:05 2008
Check interval:           5184000 (2 months)
Next check after:         Sat Jul 12 21:28:05 2008
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      7c9371fe-3c2f-4f25-9d6f-6ce194b8d468
Journal backup:           inode blocks
Journal size:             128M

Dendy ★★★★★ ()

Re: Ext3, накладные расходы

сходу не скажу. гугли на тему tune2fs и уменьшения количества суперблоков.

dmiceman ★★★★★ ()

Re: Ext3, накладные расходы

mkfs.xfs ибо ext3 сливает на таких дисках. А вобще man mkex2fs копай иноды

anonymous ()
Ответ на: Re: Ext3, накладные расходы от anonymous

Re: Ext3, накладные расходы

Что что, а суперблоки занимают копейки (-:

С помощью манов и вот этой замечательной книжки http://www.nongnu.org/ext2-doc/ext2.html установил следующее:

Место тратится на хранение inode'ов. Как видно из вышеозначеной таблицы, размер блока 4096 байт, по умолчанию на каждые 2 блока создался 1 inode (видно что блоков ровно в два раза больше чем inode'ов). Размер же inode равен 128 байт. Умножаем (122109952 * 128) и получаем наши чесноотожраные 14.665 Гб.

В свете того что хранилище организовывается под фильмотеку и на дисках будут файлы среднего размера 10 Гб становится резонным вопрос: зачем нам так много inode'ов? Поправьте если я неверно понял логический смысл inode:

Один inode - это хранилище информации ровно под один файл (или директорию) в файловой системе. Следовательно, уменьшив количество inode'ов я просто ограничу количество файлов в файловой системе. К примеру, 1000 inode'ов будет означать максимум 1000 файлов, так?

Dendy ★★★★★ ()
Ответ на: Re: Ext3, накладные расходы от Dendy

Re: Ext3, накладные расходы

Да, вот в xfs так и есть, для больших файлов, впрочем можно и екст3 отрихтовать под н файлов.

anonymous ()
Ответ на: Re: Ext3, накладные расходы от anonymous

Re: Ext3, накладные расходы

Уменьшил количество inode'ов в 4 раза - размер ФС увеличился на 9 Гб как и предполагалось.

Как полный профан в файловых системах полагаюсь на выбор разработчиков дистрибутива (-: Хочется родного, Линуксового. По правде у меня руки чешутся поставить ext4, чем наверно и займусь как только выйдет openSUSE 11. Уверен XFS, ZFS и иже с ними прекрастные файловые системы, но душа спокойна только тогда, когда данные варятся в родной, глобальной и надёжной, оттестированной тысячами пользователей ext*.

Dendy ★★★★★ ()

Re: Ext3, накладные расходы

для 1.1Тб диска xfs занимает 128Мб на inode table, a ext3 ~16Гб

Так что выводы делай сам :-)

sdio ★★★★★ ()

Re: Ext3, накладные расходы

А про рейсера все забыли?

michwill ★★★★★ ()
Ответ на: Re: Ext3, накладные расходы от michwill

Re: Ext3, накладные расходы

А зачем под фильмотеку делать рейзера? Там уместно будет уместно xfs заюзать. А на рейзер надо систему ставить. по крайней мере такие вещи как /var /usr /tmp от этого только выигрывают в скорости. По надежности - у меня все живет на рейзере кроме фильмотеки. Там как раз xfs заюзан.

А еще у меня живет маленький ребенок, который любит нажимать кнопки, до которых дотягивается в мое отсутствие, особенно ресет. Машина по многу раз за день на ходу ребутиться (ну лень мне башню разбирать, ресет отключать. Питание сразу подумал и даже не подключал, а теперь лезть не охота). Так с рейзера за год ни одного битика не потерялось. Зато прирост скорости весьма заметный после ext.

anonymous ()
Ответ на: Re: Ext3, накладные расходы от anonymous

Re: Ext3, накладные расходы

Всё таки я думаю остаться на ext, как на единственной ФС, на которую ориентируются разработчики. Единственное требование к фильмотеке - приемлимая скорость чтения и надёжность. А inode'ы можно и самому выставить сколько нужно (-:

Dendy ★★★★★ ()
Ответ на: Re: Ext3, накладные расходы от Dendy

Re: Ext3, накладные расходы

А вообще то заморачиваться на 1Tb диске из за 14Gb - это по моему слишком. Это всего лишь 1,4% от общего объема.

А если говорить о скорости - то смотря для чего. Если смотреть кино с диска - то тут можно вообще не заморачиваться. Все равно скорость потока НАМНОГО ниже чем скорость чтения. на самой корявой и медленной ФС все равно будет смотреться нормально.

Если конечно заниматься редактированием - то тут уже есть над чем подумать. Но тогда в руки тебе аппаратный рейд с процессором и буфером на батарейке. А разница в скорости по разным ФС без рейда все равно будет незначительной. Физику не обманешь - диск надо крутить, головку надо перемещать.

Надежность - тоже вещь относительная. Абсолютно надежных систем не бывает. И упираться это будет не в логику файловой системы, а в прямоту софта, который с ней работает и в железо. И файловой системой ты можешь подстраховать только первую составляющую. Но если это действительно хранилище и медиатека - то монтируй ro и проблем никаких. В общем то не сложно сделать скрипт который будет перемонтировать ФС, добавлять туда время от времени контент из указанного места и возвращать ro. А от железячных сбоев тебя спасет только рейд, причем не тупо-софтрейд на базе какого нибудь набортного Sil контроллера, а настоящий. Правильный. Но и за ним надо следить.

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

для удовлетворения паранойи можно еще вин завести под бекап по крону. Но это имхо тоже перебор. При современной доступности видео-аудио контента восстановить можно практически все.

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