Размер журнала в ext4

[Nebulosa]

Так всё-таки, почему ReiserFS - труп?..

[fffggghhh111]

Решил всё-таки проверить расчудесность xfs.
Винт 1.5т, кэш 32 метра, кеширование при записи включено, режим sata - расширенный.

Фс создавал с параметрами:
mkfs.xfs -d agcount=368 -l size=256m /dev/sda1

Монтировал:
mount /dev/sda1 /home/ -o noatime,noquota,allocsize=256k,logbufs=8,logbsize=64k

Начал ессно с копирования обратно каталога /home, никаких особо данных там не было, ни видео, ни музыки, чисто настройки системы, ну и так по мелочи, пока копировалось успел попить чаю, засомневался, думаю что-то уж шибко долго, взял скопировал тот же /home на другой винт с ext3 с ordered журналированием,
скопировалось за минуту максимум, попробовал опять на xfs, ну вдруг как-то хитро закэшировалось, тот же результат. Большие файлики на xfs копировались быстрее примерно на 15%, но вот маленькие и удаление... я был в ужасе.
На ext3 копирует со стабильной крейсерской скоростью, на xfs всё рывками, скопирует файлика 3, ждёт чего-то, ещё 5, опять ждёт, винт вроде всё время пишет,
можно попытаться свалить это на какую-то чудесную буферизацию, из-за которой файловые менеджеры показывают копирование рывками, если бы не ужасно долгое время копирования в целом. Закончилось тем что создал раздел с ext4, с параметрами по умолчанию и остался доволен, все параметры на очень хорошем уровне. Если я что-то сделал не так при создании или монтировании xfs напишите пожалуйста, потому что в том виде что я её увидел она совершенно непригодна как минимум для десктопа.

Стоит отдельно отметить что ext4 показал себя ещё лучше ext3.

Lifewalker, советую попробовать ext4, я просто уверен что Вы будете поражены.

[Lifewalker]

Lifewalker, сколько техники работает у тебя в руках? Позволяет ли такое количество говорить за всех?

Весьма немного. И, разумеется, не позволяет говорить за всех. Но за себя-то я могу говорить, не так ли?
Пользователь решил продолжить мысль 10 Января 2010, 05:04:41:

Так всё-таки, почему ReiserFS - труп?..

Автор - в тюрьме. Контора - закрыта. Из основных поставщиков Linuxов только насколько я заметил Ubuntu поставляет эту ФС по дефолту. Перспективы не ясны, поддержка весьма туманна. Нужно ли говорить, что пациент скорее мёртв чем жив?
Пользователь решил продолжить мысль 10 Января 2010, 11:14:34:

Фс создавал с параметрами:
mkfs.xfs -d agcount=368 -l size=256m /dev/sda1
...
Lifewalker, советую попробовать ext4, я просто уверен что Вы будете поражены.

Впечатляет. Может быть у меня показатели производительности выше потому что я не ставлю таких запредельных значений параметров? Обычно я формачу с agcount не более 16. Маловероятно, что когда-нибудь мне потребуется параллельный доступ более чем к десятку наборов метаданных. -l size= я тоже выставляю не более 48..64 мегабайтов. Загадить журнал такого размера нужно постараться. Ещё я добавляю -i size=512, устраняя таким образом потребность выделении блоков под крошечные файлы. Может потому меня скорость работы XFS более чем устраивает на мелких файлах. Кстати, и по дефолту mkfs.xfs работает неплохо. Мои правки скорее от желания что-то настроить нежели от реальной потребности сделать это.

Ext4 может быть попробую когда-нибудь. Когда она будет называться BTRFS. А до той поры - увольте Как я писал выше, серия ФС типа Ext - это архаичное старьё с логикой работы, унаследованной от FFS разработки ... напомните, кажется 1970 года, не так ли?

[fffggghhh111]

agcount=368 выставил в соответствии с советами в инете, :/ написано оптимально один на каждые 4 гига. :/
попозжа попробую с Вашими параметрами.

[Frank]

Чем ext4 лучше третьей версии, можно прочитать на http://xgu.ru/wiki/ext4

[Lifewalker]

agcount=368 выставил в соответствии с советами в инете, :/ написано оптимально один на каждые 4 гига. :/
попозжа попробую с Вашими параметрами.

Нууу, на заборе тоже пишут разное, а там дрова лежат. Нужно же не только следовать тому, что в интернете написано, но и преломлять прочитанное через призму собственного разумения. Параметр agcount следует использовать помня о его предназначении.

[Softwayer]

Знакомый препод с универа согласился бы с Lifewalker'ом...

[Nebulosa]

Автор - в тюрьме. Контора - закрыта. Из основных поставщиков Linuxов только насколько я заметил Ubuntu поставляет эту ФС по дефолту. Перспективы не ясны, поддержка весьма туманна. Нужно ли говорить, что пациент скорее мёртв чем жив?

Вы так чудесно спутали Reiser4 и ReiserFS 
Не только Ubuntu предоставляет эту ФС по дефолту. Эта ФС достаточно новая, и разрабатывалась с учетом нынешних условий железок, великолепно работает сейчас с большими объемами и большим количеством файлов, неоднократно подтверждала свою жизнестойкость и продуманность. Сейчас из нынешних ФС она ничуть не хуже чем ext4, btrfs или даже zfs.

[sokolovss]

Так всё-таки, почему ReiserFS - труп?..

ReiserFS ни разу не труп. Отличная файловая система. Поддерживается разработчиками, иначе её не было бы в ядре. Reiser4, собственно говоря тоже, но так как поддержка пока плоховата её нет в ядре. Также, ReiserFS поставляется во ВСЕХ современных дистрибутивах наравне с ext3. В SUSE она даже была ФС по умолчанию.

Сейчас из нынешних ФС она ничуть не хуже чем ext4, btrfs или даже zfs.

На самом деле спорное утверждение. Ибо zfs как минимум во много раз лучше работает на SSD. А вот Reiser4 действительно не должна уступать ни одной из вышеперечисленных. Очень надеюсь, что её включат-таки хоть в 36-е ядро.

[revup]

Сколько раз пытался подружиться с XFS, все время какие-то ошибки возникают. Уже и не знаю что делать((. Надежность XFS у меня под бооольшим сомнением.
Первый раз пытался отформатировать раздел под домашний каталог. Это было где-то полгода назад, ядро приблизительно 2.6.30, система-арч, винт Сигейт Барракуда 7 на 40 гигов, ИДЕ, проц Атлон 2000+, 628 оперативки.
Раздел небольшой, 30 гигов. Форматировал по дефолту, без каких-либо опций

mkfs.xfs /dev/sda3

Через некоторое время при попытке скопировать (уже точно не помню) в логах летели ошибки наподобие

[<c1161aab>] ? blk_peek_request+0xeb/0x1b0                                           
[<c1064bc0>] ? ktime_get_ts+0xd0/0x100                                               
[<c12b82e9>] ? io_schedule+0x59/0xa0                                                 
[<c10aee45>] ? sync_page+0x35/0x40                                                   
[<c12b8965>] ? __wait_on_bit+0x45/0x70                                               
[<c10aee10>] ? sync_page+0x0/0x40                                                   
[<c10af093>] ? wait_on_page_bit+0x93/0xa0                                           
[<c105afc0>] ? wake_bit_function+0x0/0x60                                           
[<c10b9567>] ? pageout+0x1b7/0x220                                                   
[<c10b9ca5>] ? shrink_page_list+0x1f5/0x540                                         
[<c108ed0a>] ? __delayacct_blkio_end+0x2a/0x50                                       
[<c10c4531>] ? congestion_wait+0x61/0x80                                             
[<c10ba6e6>] ? shrink_list+0x6f6/0x780                                               
[<c1009d78>] ? sched_clock+0x8/0x10                                                 
[<c1060a64>] ? sched_clock_local+0xa4/0x180                                         
[<c10ba9b0>] ? shrink_zone+0x240/0x340                                               
[<c10bb768>] ? try_to_free_pages+0x208/0x360                                         
[<c10b8a40>] ? isolate_pages_global+0x0/0x1d0                                       
[<c10b4f86>] ? __alloc_pages_nodemask+0x346/0x5e0                                   
[<c10dd493>] ? __slab_alloc+0x163/0x670                                             
[<c10ddbe8>] ? kmem_cache_alloc+0xb8/0x150                                           
[<c8c7ffe4>] ? kmem_zone_alloc+0x74/0xb0 [xfs]                                       
[<c8c7ffe4>] ? kmem_zone_alloc+0x74/0xb0 [xfs]                                       
[<c8c80031>] ? kmem_zone_zalloc+0x11/0x50 [xfs]                                     
[<c8c78654>] ? _xfs_trans_alloc+0x24/0x70 [xfs]                                     
[<c8c78878>] ? xfs_trans_alloc+0x78/0x80 [xfs]                                       
[<c1060a64>] ? sched_clock_local+0xa4/0x180                                         
[<c8c65a88>] ? xfs_iomap_write_unwritten+0x88/0x250 [xfs]                           
[<c10366db>] ? finish_task_switch+0x3b/0xa0                                         
[<c12b7b59>] ? schedule+0x2f9/0xa30                                                 
[<c8c80990>] ? xfs_end_bio_unwritten+0x0/0x70 [xfs]                                 
[<c8c809f4>] ? xfs_end_bio_unwritten+0x64/0x70 [xfs]

Затем она вообще не примонтировалась, пришлось xfs_repair делать. В общем, на тот момент я от нее отказался в пользу Ext4.


Недавно купил новый винт WD Caviar Green EARS 1.5тб и вновь встал вопрос о подходящей ФС. К слову, т.к. винт САТАшный, а разъемов в материнке нет, то дополнительно был куплен контроллер STLab A-224 на sil3114 чипсете и благополучно прошит из режима РАЙД в ИДЕ последней версии - 5.5.0.0. Система та же - арч, но уже с ядром 2.6.32, пакет xfs_progs несколько раз поменял версию, комп тот же. Я вновь посмотрел в сторону XFS, на этот раз более основательно. Создал раздел, отформатировал так:

mkfs.xfs -f -b size=4096 -d agcount=64 -i size=512 -l size=32m /dev/sdb5

Система проработала около дня - и вновь ошибки при попытке скопировать данные!! В логах ругался на повреждение журнала, или чтото в этом духе. Точно сказать не могу, т.к. проверив винт на сбойные сектора, я обнаружил один и поэтому в тот же день его отвез поменять. Отговорка была в виде битого сектора.
"Ладно",-подумал я: "На новом винте все будет как надо".

На поменяном винте битых секторов не оказалось - 2 раза проверял. Система - все тот же арч с ядром 2.6.32, но комп другой - 3пень 750, мать акорп 6ZX85, ВНИМАНИЕ(может это важно будет?) 128мбайт оперативки, контроллер СТЛаб, новый винт. Вновь отформатрировал раздел, но немного по-другому

mkfs.xfs -f -b size=4096 -d agcount=64 -i size=512 -s size=4096 -l size=32m /dev/sdb5

ВНИМАНИЕ - Размер сектора -s size=4096 выбран потому это был WD Caviar Green EARS 1.5, то у него хитрый АППАРАТНЫЙ размер сектора в 4096 байт, ПРОГРАММНО (имеется ввиду программа внутри винта) реализовано, что для оси секторы видны как 512. Кстати, я вообще это зрая сделал или нет??

Но счастье продлилось недолго. Через сутки работы в логах ОПЯТЬ посыпались ошибки

INFO: task xfsconvertd/0:556 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
xfsconvertd/0 D c7288800     0   556      2 0x00000000
c70f54f0 00000046 c73b3a88 c7288800 c1161aab c7288800 00000000 2a838f08
00000a28 c787d800 c7906540 c144a2a0 c144a2a0 2a827f55 00000a28 c70f56a0
c1445764 c70f56a0 c144a2a0 c144a2a0 00663f06 c1064bc0 610ce0e3 00000000
Call Trace:
[<c1161aab>] ? blk_peek_request+0xeb/0x1b0           
[<c1064bc0>] ? ktime_get_ts+0xd0/0x100               
[<c12b82e9>] ? io_schedule+0x59/0xa0                 
[<c10aee45>] ? sync_page+0x35/0x40                   
[<c12b8965>] ? __wait_on_bit+0x45/0x70               
[<c10aee10>] ? sync_page+0x0/0x40                     
[<c10af093>] ? wait_on_page_bit+0x93/0xa0             
[<c105afc0>] ? wake_bit_function+0x0/0x60             
[<c10b9567>] ? pageout+0x1b7/0x220                   
[<c10b9ca5>] ? shrink_page_list+0x1f5/0x540           
[<c108ed0a>] ? __delayacct_blkio_end+0x2a/0x50       
[<c10c4531>] ? congestion_wait+0x61/0x80             
[<c10ba6e6>] ? shrink_list+0x6f6/0x780               
[<c1009d78>] ? sched_clock+0x8/0x10                   
[<c1060a64>] ? sched_clock_local+0xa4/0x180           
[<c10ba9b0>] ? shrink_zone+0x240/0x340               
[<c10bb768>] ? try_to_free_pages+0x208/0x360         
[<c10b8a40>] ? isolate_pages_global+0x0/0x1d0         
[<c10b4f86>] ? __alloc_pages_nodemask+0x346/0x5e0     
[<c10dd493>] ? __slab_alloc+0x163/0x670               
[<c10ddbe8>] ? kmem_cache_alloc+0xb8/0x150           
[<c8c7ffe4>] ? kmem_zone_alloc+0x74/0xb0 [xfs]       
[<c8c7ffe4>] ? kmem_zone_alloc+0x74/0xb0 [xfs]       
[<c8c80031>] ? kmem_zone_zalloc+0x11/0x50 [xfs]       
[<c8c78654>] ? _xfs_trans_alloc+0x24/0x70 [xfs]       
[<c8c78878>] ? xfs_trans_alloc+0x78/0x80 [xfs]       
[<c1060a64>] ? sched_clock_local+0xa4/0x180           
[<c8c65a88>] ? xfs_iomap_write_unwritten+0x88/0x250 [xfs]
[<c10366db>] ? finish_task_switch+0x3b/0xa0           
[<c12b7b59>] ? schedule+0x2f9/0xa30                   
[<c8c80990>] ? xfs_end_bio_unwritten+0x0/0x70 [xfs]   
[<c8c809f4>] ? xfs_end_bio_unwritten+0x64/0x70 [xfs] 
[<c105710f>] ? worker_thread+0x11f/0x260             
[<c105af80>] ? autoremove_wake_function+0x0/0x40     
[<c1056ff0>] ? worker_thread+0x0/0x260               
[<c105acd4>] ? kthread+0x74/0x80                     
[<c105ac60>] ? kthread+0x0/0x80                       
[<c1004627>] ? kernel_thread_helper+0x7/0x10                               

Таких записей было около 10. Система вела себя крайне нестабильно и непредсказуемо - процессы не убивались даже от рута, проц не был загружен, задержки при открытии папок огромные итп. В общем, я в тупике(((

Да, и еще, как мне кажется, немаловажный момент. Во всех случаях XFS использовалась как файлопомойка для торрентов (монтировалась во всех случаях с опциями default). Т.е. На нее все время писались скачиваемые файлы (клиент - transmission) и так целые сутки. Может быть это подорвало систему?? Имхо бред, не должно быть такого, но все равно, выше я писал о том, что оперативки мало, может в этом и есть проблема (к сожалению, в момент сбоя не обратил внимания на количество памяти, но в инете подобные вещи писали например
http://oss.sgi.com/archives/xfs-masters/2009-10/msg00016.html
http://lkml.indiana.edu/hypermail/linux/kernel/0910.2/01146.html
Будет еще один сбой (конечно будет :-)), обязательно это проверю)

[sokolovss]

У меня после отрубания электричества даже никаких ошибок не возникало, ни то что при копировании. XFS стоит на 2 подопытных ноутах. Всё круто.

[Lifewalker]

revup, какое отношение всё изложенное Вами имеет к теме "Размер журнала в ext4"?

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

Я сто раз читал и слышал фразы типа "файловая система ХХХ фигня, потому что ошибок типа УУУ вагон". В 99% случаев обнаруживалось, что причина проблем в железе и условиях его эксплуатации. 1% случаев (патологический) - прокладка. Полагаю, совершенно очевидно, что к revup этот 1% никак не подходит

Да, кстати, про размер сектора. Не важно какого размера сектор на пластинах, важно какой размер сектора наружу представляет электроника диска. Насколько я понимаю, электроника говорила про 512-байтный секторы. Тогда зачем извращения в виде параметра mkfs.xfs -s size=4096 ?

[ploop]

(Нажмите, чтобы показать/скрыть)

Интересно, а почему производители накопителей (HDD, SSD, флешек всяких) не встроят в девайсы собственную ФС, наиболее подходящую для конкретного образца? А наружу простой и документированный интерфейс, типа как ОС предоставляет программам.

[Frank]

этот интерфейс - лишняя сущность
у винчестера есть сектора, и всё
электроника даёт доступ к ним по стандарту SATA (PATA).
операционная система использует ту ФС, какую захочет.

[Lifewalker]

операционная система использует ту ФС, какую захочет.

+1
Или вообще никакую не  использует, предоставляя некоторым программам типа СУБД диски в "сыром" виде без логической структуры, лишь в виде набора блоков от 0 до ХХХХХХХ.