URL: https://ssl.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 83130
[ Назад ]

Исходное сообщение
"Патч, увеличивающий производительность Btrfs на 5-10%"

Отправлено opennews , 19-Фев-12 13:25 
Мяо Се (Miao Xie) представил (http://www.mail-archive.com/linux-btrfs@vger.kernel.org...) в списке рассылки разработчиков Btrfs патч с реализацией  кэширования буфера экстентов для каждого i-node. Использование подобного кэша снимает необходимость поиска элементов в корневом дереве b+, что позволяет заметно сэкономить время поиска и уменьшить число блокировок при одновременном доступе к корневому дереву. В частности, оценка производительности операций записи тестом sysbench при использовании патча показала ускорение на 5-10%.

URL: http://www.phoronix.com/scan.php?page=news_item&px=MTA1ODY
Новость: https://www.opennet.ru/opennews/art.shtml?num=33132


Содержание

Сообщения в этом обсуждении
"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено freenam , 19-Фев-12 13:52 
отлично, осталось узнать когда этот патч будет в ядре?

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено fetisheer , 19-Фев-12 14:09 
Наиболее вероятно в 3.4

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено VoDA , 19-Фев-12 13:59 
годно!

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено jedie , 19-Фев-12 14:18 
5-10% это тебе не хухры мухры когда дело касается файловой системы.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 14:27 
Это с наибольшей степени зависит от задачи.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено x0r , 19-Фев-12 14:43 
I have do small file write performance (inline file) by sysbench for the patch,
and found it can make btrfs 5%~10% faster.

Surely, I will do function test(such as xfstests) and run more performance test
next to validate this patch. And there is some redundant code in this patch. I
will cleanup it in the next version.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Клыкастый , 19-Фев-12 18:19 
интересно как стало с памятью?

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено angra , 19-Фев-12 20:16 
Скоро придут к прожорливости ZFS. Кеширование всегда было обменом скорости на потребление памяти. Зато в разных бенчмараках можно подкручивать опции и показывать нужные результаты.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 21:14 
Ты не в курсе, но у ZFS размеры памяти весьма спокойно регулируются системными параметрами. В Солярисе, разумеется, а не в жалком подобии левой руки.

И эти параметры зело удобно подкручиваются под любые потребные ворклоады.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 22:53 
У пингвинов кеш тоже подкручивается. Но гораздо прикольнее что он умеет жрать большую часть оперативы под кеш сам, если она никому не сдалась. И немедленно отдавать ее обратно если оперативка все-таки кому-то потребовалась, что прямо по дефолту обеспечивает весьма приятное поведение большинства файловых систем при том что никто не замечает никакого "дикого жрача памяти" т.к. осетр динамически урезается по мере необходимости.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 05:11 
А если запастись бесперебойником, то можно устроить "извращенный" тюнинг системы и добиться ошеломляющих результатов (моя плакать как вспомню форточки на этом железе).

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 11:30 
> (моя плакать как вспомню форточки на этом железе).

А в форточках с файловыми системами все не просто убого а очень убого.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 18:51 
Если бы убогость была только в файловых системах ..

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено iZEN , 20-Фев-12 17:56 
> В Солярисе, разумеется, а не в жалком подобии левой руки.

"Подобие левой руки":

% sysctl -a | grep zfs
1 PART ada4p3 635801600000 512 i 3 o 4295115776 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b
1 PART ada3p3 635801600000 512 i 3 o 4295115776 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b
1 PART ada2p3 635801600000 512 i 3 o 4295115776 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b
1 PART ada1p3 635801600000 512 i 3 o 4295115776 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b
1 PART ada0p3 624028736000 512 i 3 o 16106275840 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b
1 PART ada0p2 16106127360 512 i 2 o 148480 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b
z0xfffffe00098d2100 [shape=box,label="ZFS::VDEV\nzfs::vdev\nr#4"];
z0xfffffe0009b7eb00 [shape=box,label="ZFS::ZVOL\nzfs::zvol::roxy/swap\nr#1"];
      <name>zfs::vdev</name>
      <name>zfs::zvol::roxy/swap</name>
        <type>freebsd-zfs</type>
        <label>store_zfs_S23TJDSZ305854</label>
        <type>freebsd-zfs</type>
        <label>selena_zfs</label>
        <type>freebsd-zfs</type>
        <label>store_zfs_S23TJDSZ305881</label>
        <type>freebsd-zfs</type>
        <label>store_zfs_S23TJDSZ305883</label>
        <type>freebsd-zfs</type>
        <type>freebsd-zfs</type>
vfs.zfs.l2c_only_size: 0
vfs.zfs.mfu_ghost_data_lsize: 16912384
vfs.zfs.mfu_ghost_metadata_lsize: 3105792
vfs.zfs.mfu_ghost_size: 20018176
vfs.zfs.mfu_data_lsize: 660932096
vfs.zfs.mfu_metadata_lsize: 16531456
vfs.zfs.mfu_size: 718804480
vfs.zfs.mru_ghost_data_lsize: 29484544
vfs.zfs.mru_ghost_metadata_lsize: 7831552
vfs.zfs.mru_ghost_size: 37316096
vfs.zfs.mru_data_lsize: 975147520
vfs.zfs.mru_metadata_lsize: 115844096
vfs.zfs.mru_size: 1217885696
vfs.zfs.anon_data_lsize: 0
vfs.zfs.anon_metadata_lsize: 0
vfs.zfs.anon_size: 8892928
vfs.zfs.l2arc_norw: 1
vfs.zfs.l2arc_feed_again: 1
vfs.zfs.l2arc_noprefetch: 1
vfs.zfs.l2arc_feed_min_ms: 200
vfs.zfs.l2arc_feed_secs: 1
vfs.zfs.l2arc_headroom: 2
vfs.zfs.l2arc_write_boost: 8388608
vfs.zfs.l2arc_write_max: 8388608
vfs.zfs.arc_meta_limit: 1673831424
vfs.zfs.arc_meta_used: 579813432
vfs.zfs.arc_min: 836915712
vfs.zfs.arc_max: 6695325696
vfs.zfs.dedup.prefetch: 1
vfs.zfs.mdcomp_disable: 0
vfs.zfs.write_limit_override: 0
vfs.zfs.write_limit_inflated: 24088375296
vfs.zfs.write_limit_max: 1003682304
vfs.zfs.write_limit_min: 33554432
vfs.zfs.write_limit_shift: 3
vfs.zfs.no_write_throttle: 0
vfs.zfs.zfetch.array_rd_sz: 1048576
vfs.zfs.zfetch.block_cap: 256
vfs.zfs.zfetch.min_sec_reap: 2
vfs.zfs.zfetch.max_streams: 8
vfs.zfs.prefetch_disable: 0
vfs.zfs.mg_alloc_failures: 8
vfs.zfs.check_hostid: 1
vfs.zfs.recover: 0
vfs.zfs.txg.synctime_ms: 1000
vfs.zfs.txg.timeout: 5
vfs.zfs.scrub_limit: 10
vfs.zfs.vdev.cache.bshift: 16
vfs.zfs.vdev.cache.size: 0
vfs.zfs.vdev.cache.max: 16384
vfs.zfs.vdev.write_gap_limit: 4096
vfs.zfs.vdev.read_gap_limit: 32768
vfs.zfs.vdev.aggregation_limit: 131072
vfs.zfs.vdev.ramp_rate: 2
vfs.zfs.vdev.time_shift: 6
vfs.zfs.vdev.min_pending: 4
vfs.zfs.vdev.max_pending: 10
vfs.zfs.vdev.bio_flush_disable: 0
vfs.zfs.cache_flush_disable: 0
vfs.zfs.zil_replay_disable: 0
vfs.zfs.zio.use_uma: 0
vfs.zfs.version.zpl: 5
vfs.zfs.version.spa: 28
vfs.zfs.version.acl: 1
vfs.zfs.debug: 0
vfs.zfs.super_owner: 0
kstat.zfs.misc.xuio_stats.onloan_read_buf: 0
kstat.zfs.misc.xuio_stats.onloan_write_buf: 0
kstat.zfs.misc.xuio_stats.read_buf_copied: 0
kstat.zfs.misc.xuio_stats.read_buf_nocopy: 0
kstat.zfs.misc.xuio_stats.write_buf_copied: 0
kstat.zfs.misc.xuio_stats.write_buf_nocopy: 3304
kstat.zfs.misc.zfetchstats.hits: 2901270
kstat.zfs.misc.zfetchstats.misses: 1312400
kstat.zfs.misc.zfetchstats.colinear_hits: 143
kstat.zfs.misc.zfetchstats.colinear_misses: 1312257
kstat.zfs.misc.zfetchstats.stride_hits: 2860436
kstat.zfs.misc.zfetchstats.stride_misses: 13
kstat.zfs.misc.zfetchstats.reclaim_successes: 2845
kstat.zfs.misc.zfetchstats.reclaim_failures: 1309412
kstat.zfs.misc.zfetchstats.streams_resets: 11
kstat.zfs.misc.zfetchstats.streams_noresets: 40821
kstat.zfs.misc.zfetchstats.bogus_streams: 0
kstat.zfs.misc.arcstats.hits: 1170954
kstat.zfs.misc.arcstats.misses: 71036
kstat.zfs.misc.arcstats.demand_data_hits: 546342
kstat.zfs.misc.arcstats.demand_data_misses: 6056
kstat.zfs.misc.arcstats.demand_metadata_hits: 529428
kstat.zfs.misc.arcstats.demand_metadata_misses: 50332
kstat.zfs.misc.arcstats.prefetch_data_hits: 4212
kstat.zfs.misc.arcstats.prefetch_data_misses: 2481
kstat.zfs.misc.arcstats.prefetch_metadata_hits: 90972
kstat.zfs.misc.arcstats.prefetch_metadata_misses: 12167
kstat.zfs.misc.arcstats.mru_hits: 348117
kstat.zfs.misc.arcstats.mru_ghost_hits: 11
kstat.zfs.misc.arcstats.mfu_hits: 727674
kstat.zfs.misc.arcstats.mfu_ghost_hits: 57
kstat.zfs.misc.arcstats.allocated: 102039
kstat.zfs.misc.arcstats.deleted: 35
kstat.zfs.misc.arcstats.stolen: 0
kstat.zfs.misc.arcstats.recycle_miss: 0
kstat.zfs.misc.arcstats.mutex_miss: 0
kstat.zfs.misc.arcstats.evict_skip: 1364
kstat.zfs.misc.arcstats.evict_l2_cached: 0
kstat.zfs.misc.arcstats.evict_l2_eligible: 0
kstat.zfs.misc.arcstats.evict_l2_ineligible: 8192
kstat.zfs.misc.arcstats.hash_elements: 84274
kstat.zfs.misc.arcstats.hash_elements_max: 84274
kstat.zfs.misc.arcstats.hash_collisions: 51137
kstat.zfs.misc.arcstats.hash_chains: 18054
kstat.zfs.misc.arcstats.hash_chain_max: 5
kstat.zfs.misc.arcstats.p: 3347333120
kstat.zfs.misc.arcstats.c: 6695325696
kstat.zfs.misc.arcstats.c_min: 836915712
kstat.zfs.misc.arcstats.c_max: 6695325696
kstat.zfs.misc.arcstats.size: 2224170584
kstat.zfs.misc.arcstats.hdr_size: 26500552
kstat.zfs.misc.arcstats.data_size: 1945591808
kstat.zfs.misc.arcstats.other_size: 252078224
kstat.zfs.misc.arcstats.l2_hits: 0
kstat.zfs.misc.arcstats.l2_misses: 0
kstat.zfs.misc.arcstats.l2_feeds: 0
kstat.zfs.misc.arcstats.l2_rw_clash: 0
kstat.zfs.misc.arcstats.l2_read_bytes: 0
kstat.zfs.misc.arcstats.l2_write_bytes: 0
kstat.zfs.misc.arcstats.l2_writes_sent: 0
kstat.zfs.misc.arcstats.l2_writes_done: 0
kstat.zfs.misc.arcstats.l2_writes_error: 0
kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0
kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0
kstat.zfs.misc.arcstats.l2_evict_reading: 0
kstat.zfs.misc.arcstats.l2_free_on_write: 0
kstat.zfs.misc.arcstats.l2_abort_lowmem: 0
kstat.zfs.misc.arcstats.l2_cksum_bad: 0
kstat.zfs.misc.arcstats.l2_io_error: 0
kstat.zfs.misc.arcstats.l2_size: 0
kstat.zfs.misc.arcstats.l2_hdr_size: 0
kstat.zfs.misc.arcstats.memory_throttle_count: 0
kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0
kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0
kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0
kstat.zfs.misc.arcstats.l2_write_in_l2: 0
kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0
kstat.zfs.misc.arcstats.l2_write_not_cacheable: 4
kstat.zfs.misc.arcstats.l2_write_full: 0
kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0
kstat.zfs.misc.arcstats.l2_write_pios: 0
kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0
kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0
kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0
kstat.zfs.misc.vdev_cache_stats.delegations: 0
kstat.zfs.misc.vdev_cache_stats.hits: 0
kstat.zfs.misc.vdev_cache_stats.misses: 0

А что настоящая левая рука умеет подкручивать?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Neandertalets , 19-Фев-12 22:23 
Ой. А мой знакомый ZFS под FreeBSD даже на Atom-е с 512Мб памяти заводил. Подтормаживала, конечно (всё таки атом, да и маловато памяти), но работала безглючно. Наверное всё таки опыт (мантайнер) сказывается.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 22:58 
> Ой. А мой знакомый ZFS под FreeBSD даже на Atom-е с 512Мб памяти заводил.

А iZEN собрал райд из 3 ноутбучных дисков. Ну круто, чо.

> Подтормаживала, конечно (всё таки атом, да и маловато памяти),

Ну вы сами все сказали. А btrfs не должен в сильную опу падать и при небольшом объеме оперативы.

> но работала безглючно. Наверное всё таки опыт (мантайнер) сказывается.

Не, конечно можно из точки А в точку Б ездить на асфальтоукладчике, и даже без топлива в баке, толкая его сзади лично. Но говорят что есть более быстрые и менее мучительные способы...


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено анон , 20-Фев-12 07:44 
> А btrfs не должен в сильную опу падать и при небольшом объеме оперативы.

Потому как он там перманентно.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 11:32 
> Потому как он там перманентно.

Error: E_TROLL_IS_TOO_FAT.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено iZEN , 20-Фев-12 17:59 
>> Ой. А мой знакомый ZFS под FreeBSD даже на Atom-е с 512Мб памяти заводил.
> А iZEN собрал райд из 3 ноутбучных дисков. Ну круто, чо.

Из пяти. Не рейд, а пулы: stripe, mirror и raid-z.

>> но работала безглючно. Наверное всё таки опыт (мантайнер) сказывается.
> Не, конечно можно из точки А в точку Б ездить на асфальтоукладчике,
> и даже без топлива в баке, толкая его сзади лично. Но
> говорят что есть более быстрые и менее мучительные способы...

zfs set checksum=off poolname/fsname ?



"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 19:00 
Хорошее дело, увеличение производительности всегда приятно, но ...

Но кажется они не тем занимаются, где "чинилка" для бтрфс ?
Обещали 14 февраля выпустить. У меня раздел повредился, а
починять было нечем. Так зачем мне 10% прироста производительности?
Причём ошибка стала вылазить после одной из нормальных перезагрузок.
Снёс нафиг сел на екст4.

"Федорино Горе" вон в очередной раз отказалось от перехода на бтрфс,
как дефолтной фс. Такое ощущение, что они бтрфс никогда не допилят
до продакшена.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 19:22 
Чинилка в гите. Как я понял, они считают, что она не до конца отлажена. А с вопросами о починке стоит обращаться напрямую в рассылку btrfs. Там посоветуют, что делать и стоит ли запускать чинилку.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено sam002 , 19-Фев-12 20:10 
Эм... btfsck у меня стоит и пашет себе прекрасно, пару раз уже пользовался. Debian testing. Там ещё не всё реализовано, да и фс ещё доделывается, просто она получается технологически очень новой и вокруг неё огромный ажиотаж.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 23:57 
> Они так считают уже долгие годы, это просто смех. Нафига выдавать "на-гора"
> фс без возможности её чинить ?

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 05:15 
Мало вирусов через флешку ходит в MS TrojanKeeper Operation System: "В августе 2008 года рейс 5022 авиакомпании Spanair разбился практически сразу после вылета из аэропорта Мадрида. 154 человека погибли, выжило всего 18 пассажиров.Эксперты, которые расследуют причину крушения самолета, установили, что центральная компьютерная система, которая использовалась для определения возможных технических неисправностей судна, была заражена вирусом.В результате система не смогла распознать три технические неисправности самолета, сообщает MSNBC. В случае их обнаружения судно могло бы остаться на земле, утверждают эксперты.Попасть вирус в бортовой компьютер мог через USB-накопитель или удаленное VPN-соединение с меньшей степенью защиты, чем у компьютеров авиакомпании."

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 11:34 
> установили, что центральная компьютерная система, которая использовалась для
> определения возможных технических неисправностей судна, была заражена вирусом.
> В результате система не смогла распознать три технические неисправности самолета,

Офигенная жо. А MS что-то молчит о таких достижениях в гетзефаксах...


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 18:49 
Ранее самолеты падали под windows NT.

//Все подобные факты замалчиваются, т.к. неудобные. Но это очередные методы быдла под себя любимого. Ником от этого не легче, т.к. я и/или моя семья или родственники могут быть в самолете под ОС написанной чертовыми тупыми быдлокодерами. Ненавить к MS и бгейсту лично за то что несмотря на тикие финансовые возможности продукт не доводит до ума: очевидо что цель - бабло а не качество. Компании подобные microsoft и люди подобные бгейтсу (как и компания легкомысленно строящая самолеты) должны быть изолированы от общества, чтобы не было у них возможности влиять на что-либо или кого-либо прямо или косвенное кроме себя или тех кто согласился добровольно под их воздействие. Быдлы, не рефлексируйте если вы не осознаете или не понимаете сказанного. Лютая ненависть к быдлу. MustDie!!!


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Aleksey Salow , 20-Фев-12 20:39 
что за бред? http://en.wikipedia.org/wiki/Spanair_Flight_5022#Final_report

http://www.fomento.gob.es/NR/rdonlyres/C4A41FC7-89D7-42C5-B5...

Проблема с неработающим TOWS (откуда тут винда может взяться если это обычно жёсткая логика) и с персоналом, который не проверил самолёт по чеклисту перед вылетом.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 19:29 
Отличная фс..

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 19-Фев-12 20:13 
Согласен.
С декабря вытеснила все остальные с рабочего ноута с гентой на винте 500Гб

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 21:04 
Хочется острых ощущений? :-)

Почитай крики о помощи в интернетах, разделы слетают без видимых причин, а лекарства на данный момент нет.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 21:16 
> Хочется острых ощущений? :-)
> Почитай крики о помощи в интернетах, разделы слетают без видимых причин, а
> лекарства на данный момент нет.

Кто-то под дулом пистолета принуждает к переходу на недоделанную UFS-подобную ФС без наличествующей fsck? Нет? Тогда спасение утопающих - физические бэкапы, которые никто не отменил за 35 лет существования UNIX-like систем.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 22:06 
> Кто-то под дулом пистолета принуждает к переходу на недоделанную UFS-подобную ФС без
> наличествующей fsck? Нет? Тогда спасение утопающих - физические бэкапы, которые никто
> не отменил за 35 лет существования UNIX-like систем.

Даже не знаю что и ответить, на такой типичный тутошний вброс про "дуло пистолета"...


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 23:35 
> Кто-то под дулом пистолета принуждает к переходу на недоделанную UFS-подобную ФС

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 20-Фев-12 01:19 
Не суди по нику, да не судим будешь ;-)

> Почему виндус этого не знал - не понятно.

Да знал он, знал... просто Мэйсону поверил на слово, что "таблетка" будет допилена, а скорее всего и не понадобится вовсе, ибо все злобные баги уже давно выпилены, да к тому же Федора, Сюзя, Оракл и др. сказали, что в этот раз уж точно будут btrfs дефолтить.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 02:14 
> Не суди по нику, да не судим будешь ;-)

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

> Да знал он, знал... просто Мэйсону поверил на слово, что "таблетка" будет допилена,

Надо верить в лучшее, но предполагать хучшее. Тогда у вас будут только приятные сюрпризы.

> а скорее всего и не понадобится вовсе, ибо все злобные баги уже давно выпилены,

Это кто вам такое про баги сказал? В 3.2 удавили порцию довольно крутых багов, в 3.3 тоже порция изменений нехилая, в 3.4 тоже будет.

> да к тому же Федора, Сюзя, Оракл и др. сказали, что в этот раз уж точно будут btrfs
> дефолтить.

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 20-Фев-12 02:45 
> Просто я не понимаю желания очмырить откровенно тестовый пепелац.

Исходное сообщение выглядело так:

"Но кажется они не тем занимаются, где "чинилка" для бтрфс ?
Обещали 14 февраля выпустить. У меня раздел повредился, а
починять было нечем."

Где же тут попытка "очмырения" ? Одно только недоумение и досада, не более того.


Да, планы могут меняться, только не так часто они должны меняться. В этот раз не только Федора ( у которой уже третий облом с бтрфс случился ) громко заявила о желании бтрфс задефолтить, но и другие тоже.

Получается, что Мэйсон их всех убедил, что всё будет пучком, а практика показала обратное.

Или как?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 03:58 
> "Но кажется они не тем занимаются, где "чинилка" для бтрфс ?

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

> Обещали 14 февраля выпустить. У меня раздел повредился, а починять было нечем."
> Где же тут попытка "очмырения" ? Одно только недоумение и досада, не более того.

По-моему, досадовать тут надо в первую очередь на собственное непонимание того что есть тестовый образец технологии, а что - продакшновый. Грубо говоря, нормальный подход в такой ситуации - "повредился? Ну так для этого я его и гонял! Эй, разработкики, а если вот так и вот так делать - у вашей конструкции хвост отваливается! А может быть его можно обратно привинтить своими силами?!"

> Да, планы могут меняться, только не так часто они должны меняться. В этот раз не
> только Федора ( у которой уже третий облом с бтрфс случился ) громко заявила о
> желании бтрфс задефолтить, но и другие тоже.

Потому что пепелац постепенно достигает кондиции. Акулы видят что счастье уже близко, вот и точат зубы на вкусную плюшку.

> Получается, что Мэйсон их всех убедил, что всё будет пучком, а практика показала обратное.

Вероятно как обычно, т.е. 80% работы заняли 20% времени, зато остальные 20% - потребовали еще 80%...

> Или как?

Ну вот так. Вы такой забавный что как будто впервые в жизни видите как разрабатывается софт или вообще хоть какая-то технически сложная конструкция.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 05:07 
>> Не суди по нику, да не судим будешь ;-)
> Просто я не понимаю желания очмырить откровенно тестовый пепелац.

Чмырил его не он, а Шишкин, например: http://habrahabr.ru/blogs/linux/108629/


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 05:19 
> Чмырил его не он, а Шишкин, например: http://habrahabr.ru/blogs/linux/108629/

1) Это в каком году было? 2010? Так с тех пор много воды утекло и много коммитов в гит прилетело... как бы щеголяя баянами неплохо бы понимать что для активно разрабатываемого проекта значительная часть баяна может запросто стать недействительной через несколько месяцев, просто потому что разработчики и те кто заинтересован - критику тоже почитывают ;)
2) Вы в вашем праве пользоваться ФС от Шишкина если вам так нравится больше, а я пешком постою. Ибо да простит меня Шишкин, один в поле не воин.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 08:51 
>> Чмырил его не он, а Шишкин, например: http://habrahabr.ru/blogs/linux/108629/
> 1) Это в каком году было? 2010? Так с тех пор много
> воды утекло и много коммитов в гит прилетело... как бы щеголяя
> баянами неплохо бы понимать что для активно разрабатываемого проекта значительная часть
> баяна может запросто стать недействительной через несколько месяцев, просто потому что
> разработчики и те кто заинтересован - критику тоже почитывают ;)
> 2) Вы в вашем праве пользоваться ФС от Шишкина если вам так
> нравится больше, а я пешком постою. Ибо да простит меня Шишкин,
> один в поле не воин.

А что изменилось-то, из того, что говорил Эдуард? Избавились от Б-деревьев или от фрагментирования, ну или убрали айтемы в б-деревьях, может увеличили длину ключа, переписали балансировку?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 11:39 
> А что изменилось-то, из того, что говорил Эдуард? Избавились от Б-деревьев или
> от фрагментирования, ну или убрали айтемы в б-деревьях, может увеличили длину
> ключа, переписали балансировку?

Что изменилось?
Во первых, переделали размещение метаданных для клинического случая предложенного шишкиным, насколько я помню.
Во вторых, я не понял - зачем избавляться от б-деревьев?
В третьих - фрагментирование неизбежное следствие CoW дизайна, только вот у btrfs по этому поводу есть встроеный автодефраг, который делая GC заодно может и отдефрагать.
В четвертых, ВНЕЗАПНО балансировку действительно переписали, буквально недавно. Я уж не знаю как вы так угадали с желанием потроллить прямо. Чудеса.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено anonymous , 20-Фев-12 12:59 
В твоей голове - да, все это произошло. Но в реальном мире Btrfs ничего из этого не исправлено за исключением серии жутких анектодичных багов с оценкой свободного места на диске.

Про автодефраг и scrub уже просто утомили в этом треде - САМ МЕЙСОН, главный разработчик сказал что это за хрень если тебе лень исходники поглядеть. И объяснил почему это никак не тянет на FSCK и соответственно почему дефраг настолько неэффективен что можно сказать его и нет. Почитай список рассылки а не внутренние голоса.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 13:18 
> Про автодефраг и scrub уже просто утомили в этом треде - САМ
> МЕЙСОН, главный разработчик сказал что это за хрень если тебе лень
> исходники поглядеть. И объяснил почему это никак не тянет на FSCK

Ты что, упоролся? Где я говорил что дефраг - замена fsck? 0_0 Про это спич не шел, но видимо красная пелена застилает глаза и вот уже наш Дон Кихот бросается на очередную ветряную мельницу.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено anonymous , 20-Фев-12 15:56 
Упоролся ты, написав что я сказал что ты сказал что дефраг это замена FSCK.

Ты сказал что все претензии Тсо, Шишкина и других авторитетов файловых систем высказаные 4 года назад были учтены и исправлены.

Я сказал что это не так. Ни проблема с отсутствием главной идеи файловой системы ("покажите мне хоть одну научную статью по поводу оценки эффективности самой идеи" - спрашивал Шишкин, "что будет с Btrfs когда процент свободного места станет небольшим, какие хитрости вы сделаете для уменьшения жуткой фрагментации?" от Tco)  так и остались нерешенными. Плюс fsck. Плюс пипец с fsync.

Продолжай разговаривать с вооброжаемыми образами.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 17:00 
> Упоролся ты, написав что я сказал что ты сказал что дефраг это замена FSCK.

Не, погодите, а вон то что выше - что за бред? Или это так, просто много ругани в 1 строку, без какой либо логической разбивки?

> Ты сказал что все претензии Тсо, Шишкина и других авторитетов файловых систем
> высказаные 4 года назад были учтены и исправлены.

Где я сказал что _все_? Некоторые - устранили. А некоторые хоть у того же Шишкина, простите, высосаны из пальца. То ему процент метаданных на каком-то шизанутом размере тома размером с сидюк не нравился, то деревья ему не те. Ну вот прям все не так, если ФС не ты дизайнил, действительно :). А вы почитайте как в ZFS решения принимались, например. Там еще более странно все. А пипл однако ж хавает...

> Я сказал что это не так. Ни проблема с отсутствием главной идеи
> файловой системы ("покажите мне хоть одну научную статью по поводу оценки
> эффективности самой идеи" - спрашивал Шишкин,

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

> "что будет с Btrfs когда процент свободного места станет небольшим,

То же что и с остальными ФС - лапша на томе. Встроеный дефраг может даже немного спасет. Малоэффективно говорите? А у саней вон вообще не предусмотрено такого счастья как я понимаю и предлагается кушать маркетинговый шит о том как это не требуется их супер-пупер файловой системе. И если малоэффективную реализацию _можно_ улучшить, и это даже подъемная задача, то вот когда дефраг не был предусмотрен в изначальном дизайне - реализовать его может быть на редкость нетривиально. Достаточно вспомнить что гибкость в использовании дискового пространства btrfs'ом заранее была заложена в дизайн и в этом плане там все явно умнее zfs сделано.

> какие хитрости вы сделаете для уменьшения жуткой фрагментации?" от Tco)  

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

> так и остались нерешенными.

Вы так говорите, как будто проблемы есть только у btrfs, а у остальных прямо тишь да гладь. А может, надо забить на идеализм и просто сранвить с иными дизайнами и их проблемами? :)

> Плюс fsck.

У ZFS, единственной реально сравнимой по возможностям ФС, такового даже в планах не значится, вместо этого опять маркетинговый шит от санок. Как и с дефрагером. И да, почему бы не спросить у них что будет если забить ФС под завязку?  

> Плюс пипец с fsync.

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

> Продолжай разговаривать с вооброжаемыми образами.

И кого они там вооб-рожают? И да, жду ваших более конструктивных предложений. Что вы нам предложите на завтра? Классику, которая вообще не умеет журналирование записи с нормальной скоростью by design? Неведомый пепелац Шишкина, который в теории крут, но на практике - от него только голый каркас без нифига? ZFS, у которого странностей и неотвеченных вопросов на два btrfs хватит? Или чего? А то если вечно гнаться за идеалом - так на то и идеал чтобы никогда не быть достигнутым. С такими подходами вам к бсдунам, которые если б не сани вообще сейчас сидели бы с голым UFS, но зато концептуально верными слоями абстракций к нему.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено iZEN , 20-Фев-12 18:19 
>> Плюс fsck.
> У ZFS, единственной реально сравнимой по возможностям ФС, такового даже в планах
> не значится, вместо этого опять маркетинговый шит от санок. Как и
> с дефрагером. И да, почему бы не спросить у них что
> будет если забить ФС под завязку?

Давайте спросим... меня!

% zfs list media
NAME        USED  AVAIL  REFER  MOUNTPOINT
media   564G  6,91G    31K  /media

Так что же я вам скажу?

На пуле media у меня файлопомойка и торренто-качалка без всяких RAID. Тупо: один раздел диска выделен под ZFS. Так вот, примерно с 98-99% заполненности пула (около 11 ГБ свободного пользовательского пространства) начинаются дикие тормоза с многопоточной записью и чтением файлов с этого пула. Браузеры файловой системы, такие как Thunar, заметно подтормаживают с отрисовкой собственного интерфейса, если с файловой системы пула фоном идёт копирование фалов в другой пул; торрент-клиент приходится останавливать на время копирования, иначе операция растянется надолго. Интересно то, что "клинит" только приложения, которые непосредственно работают с файлами из этого пула, а не те, которые вообще к нему никак не относятся. То есть во время копирования можно спокойно пользоваться Firefox, Thunderbird и другими запущенными приложениями, а вот в Thunar приходится ждать секунд пять отрисовки его интерфейса на открытой папке пула. Курсор мыши не залипает.

>> Продолжай разговаривать с вооброжаемыми образами.
> И кого они там вооб-рожают? И да, жду ваших более конструктивных предложений.
> Что вы нам предложите на завтра?
> ZFS, у которого странностей и неотвеченных вопросов на
> два btrfs хватит?

Во всяком случае тебе никто не мешает ответить на все интересующие вопросы самому. Код ZFS открыт. Систем, реализующие возможности ZFS, две, а с вкоряченным в ядро Linux кодом ZFS дистрибутивом — три или четыре! Кто мешает тебе, User294, взять и самому как следует рассмотреть со всеми крэш-тестами на выживание ФС, так сказать? zdb в руки и вперёд.
НЕИМОВЕРНАЯ БАРАНЬЯ УПЁРТОСТЬ!


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 21-Фев-12 04:03 
> Давайте спросим... меня!

Ох, разбудили облолодателя ынтырпрайзных конфигов :)

> REFER  MOUNTPOINT
> media   564G  6,91G    31K  /media

Вообще, 6G как бы довольно большой кус места, я думаю что Теодор имел в виду намного более клинические условия. В 6Гб аллокатору даже есть где потрепыхаться, хоть оптимальность принятых решений и будет существенно снижена.

> Так что же я вам скажу?

Выдашь серию лулзов и некомпетентности, как обычно, имхо.

> На пуле media у меня файлопомойка и торренто-качалка без всяких RAID. Тупо:
> один раздел диска выделен под ZFS. Так вот, примерно с 98-99%
> заполненности пула (около 11 ГБ свободного пользовательского пространства) начинаются
> дикие тормоза с многопоточной записью и чтением файлов с этого пула.

Странно, iZEN сам сообщил нелестный факт о своей ФС. Не понимаю что за фигня. Он сегодня какой-то слишком честный.

> растянется надолго. Интересно то, что "клинит" только приложения, которые непосредственно
> работают с файлами из этого пула, а не те, которые вообще
> к нему никак не относятся.

А чего тут интересного? Программа запросила I/O. Запрос улетел в недра ядра. Ядро где-то в недрах отдало сие разруливать ФС и в итоге дисковой подистеме, которые раздуплятся как сумеют и не ранее того. Если это займет много времени - значит это займет много времени. В случае обычного блокирующего I/O программа будет висеть в вызове который должен непременно вернуть статус операции, ожидая завершения этой самой операции, пока ядро там раздупляется. Ядро просто не вернет управление программе пока не разрулит эту операцию, просто потому что продолжение выполнения зависит от этой операции. Если автор заранее не подумал о таком и использовал совсем олдскульные методы, это вполне может привести к клину интерфейса и отсутствию реакции на внешние раздражители. Если у проги был 1 поток и он намертво встрял в вызове, допустим, read(), программа не сможет больше ни на что реагировать пока read() не вернет нам результат. По этому поводу придумали асинхронное I/O, вынос тяжелых и медленных операций в отдельные треды, клин которых никому не создает проблем и прочая. Однако как ты понимаешь, просто вхреначить вызов чтения/записи не парясь последствиями - проще всего. А то что оно может на 100500 мс заклинить в этом месте если не повезет - упс. Не все это понимают, увы.

> То есть во время копирования можно спокойно пользоваться Firefox, Thunderbird
> и другими запущенными приложениями, а вот в Thunar приходится ждать секунд
> пять отрисовки его интерфейса на открытой папке пула.

Кэп намекает что тот кто застрял в синхронном I/O вызове надолго и не сделал несколько тредов - тот и кукует до возврата. На самом деле это крайне простая и логичная механика из разряда кто кого вызывает и кто чьи запросы разруливает. Посмотреть что там и где застревает можно буквально любым профилировщиком/трассиром попавшим под руку, но я и так могу себе представить как сие выглядит.

> Курсор мыши не залипает.

Ты уже достал с курсором. Просвети, блин, что у тебя за комплексы? Ты постоянно вопишь что он у тебя "не залипает" как мантру. А должен залипать? Я вот даже вспомнить не могу чтобы у меня курсор залипал. Ну может в новых виндах (виста/семерка) при сильном своплении пару раз видел клины курсора, и то это надо систему в своп свалить (впрочем винды в него валятся охотно by design). На моем десктопе и ноуте с пингвином курсор катается идеально. Я вообще не знаю что надо сделать чтобы его заклинило. Ни одна из типичных активностей к такому точно не ведут.

>> ZFS, у которого странностей и неотвеченных вопросов на два btrfs хватит?
> Во всяком случае тебе никто не мешает ответить на все интересующие вопросы самому.

А тебе слабо?

> Код ZFS открыт.

Только он сцуко здоровый и сложный, поэтому я удовольствовался тем что посмотрел на общий дизайн, понял что половина решений взято с потолка + процент маркетингового булшита от саней в документации мне не по вкусу. Учтя что его никогда не будет в релизном виде в симпатичной мне системе + я искренне полагаю что из дизайна btrfs можно выжать больше, я попросту не испытываю сильного желания изучать каждый битик данных сырцов.

> Систем, реализующие возможности ZFS, две,

При том одна - проприетарная на весьма невкусных условиях, а вторая - реализует такой "продакшн", конечно, что все списки рассылки зафлужены кучей неочевидных грабель на которые стандартный ответ - "дай угадаю, у тебя ZFS?!". Пардон, продакшна с висючими сисколами, маркетингом вместо ответа на некоторые злободневные вопросы мне как-то не требуется, thank you very much, sir.

> а с  вкоряченным в ядро Linux кодом ZFS дистрибутивом — три или четыре!

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

> Кто мешает тебе, User294, взять и самому как следует рассмотреть со
> всеми крэш-тестами на выживание ФС, так сказать?

В основном соотношение объема работ vs результат от оного для меня любимого. Если ты хочешь посмотреть как я загоню zfs в полный ахтунг - да не вопрос, а какие плюшки мне за эту не нyжную персонально мне долботню мне за это обломятся? Никаких? Ну ой, так не интересно. Грубо прикинуть свойства дизайна и что для него будет откровенно (не)удобно я могу и просто посмотрев на дизайн и результаты различных бенчей, это достаточно тривиально и не требует много времени и подготовки кучи конфигураций. Улови мысль: чтобы я побежал клепать lab-like окружение и что-то там изучать, мне это должно быть зачем-то надо.

> zdb в руки и вперёд.

Ага. Вот ружье а вот патроны. Правда я не допираю на кого охотимся и почему я в этом должен принять участие.

> НЕИМОВЕРНАЯ БАРАНЬЯ УПЁРТОСТЬ!

Что-то тебя сегодня прямо на честность пробило. То ты признаешь что zfs тормозить умеет, то что ты уперт.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено iZEN , 22-Фев-12 08:55 
>> Давайте спросим... меня!
> Ох, разбудили облолодателя ынтырпрайзных конфигов :)
>> REFER  MOUNTPOINT
>> media   564G  6,91G    31K  /media
> Вообще, 6G как бы довольно большой кус места, я думаю что Теодор
> имел в виду намного более клинические условия. В 6Гб аллокатору даже
> есть где потрепыхаться, хоть оптимальность принятых решений и будет существенно снижена.

Что он имел конкретно? Сколько места на ФС должно оставаться свободным, чтобы аллокатор ФС затормозил процессы, обращающиеся к ФС, окончательно?

>> Так что же я вам скажу?
> Выдашь серию лулзов и некомпетентности, как обычно, имхо.

Да ты вообще не пробовал этих устриц. Так что молчи.

> Странно, iZEN сам сообщил нелестный факт о своей ФС. Не понимаю что за фигня. Он сегодня какой-то слишком честный.

Я когда врал?

>> Курсор мыши не залипает.
> Ты уже достал с курсором. Просвети, блин, что у тебя за комплексы?
> Ты постоянно вопишь что он у тебя "не залипает" как мантру.
> А должен залипать? Я вот даже вспомнить не могу чтобы у
> меня курсор залипал.

Комплексы? По-моему, залипание курсора на десктопе в процессе копирования файлов — одна из серьёзнейших причин не использовать такую операционную ситсему на десктопе. Она утрачивает интерактивность. Не?

На всякий случай проверь:

cd /tmp && dd if=/dev/zero of=12309_is_here bs=1M count=16384


>>> ZFS, у которого странностей и неотвеченных вопросов на два btrfs хватит?
>> Во всяком случае тебе никто не мешает ответить на все интересующие вопросы самому.
> А тебе слабо?

По крайней мере, я отвечаю.

>> Код ZFS открыт.
> Только он сцуко здоровый и сложный, поэтому я удовольствовался тем что посмотрел
> на общий дизайн, понял что половина решений взято с потолка +
> процент маркетингового булшита от саней в документации мне не по вкусу.

Так некомпетентность в конкретном вопросе никто не отменял — если не разбираешься в исходных текстах, тогда подойди с позиций обывателя: просто попробуй в работе БИНАРНЫЙ_КОД.

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

Из дизайна Btrfs до сих пор не выжали то, для чего она, собственно говоря, предназначалась. А именно: организации автономной системы хранения без использования традиционного стекирования md+LVM с разноуровневой избыточностью и верификацией данных на замену традиционным ФС. Btrfs уже умеет RAID-5, полностью загрузочный?

>> Систем, реализующие возможности ZFS, две,
> При том одна - проприетарная на весьма невкусных условиях,

OpenIndiana проприетарная? В каком месте?

> а вторая -
> реализует такой "продакшн", конечно, что все списки рассылки зафлужены кучей неочевидных
> грабель на которые стандартный ответ - "дай угадаю, у тебя ZFS?!".

Ты очень много об этом говоришь. Дай, пожалуйста, ссылки на обсуждения и PR, где "угадывают, что у меня ZFS" и поэтому у меня ничего не должно работать/постоянно ломаться/теряться данные.

Странно, но за неполных пять лет использования ZFS я никаких файлов на ней не потерял. Scrub пулов пускаю регулярно.

>> а с  вкоряченным в ядро Linux кодом ZFS дистрибутивом — три или четыре!
> Не вижу смысла тратить время на код который никогда не будет реальным
> продакшном. Я не занимаюсь заведомо тухлыми начинаниями.

Отговорка хоть куда!

>[оверквотинг удален]
>> всеми крэш-тестами на выживание ФС, так сказать?
> В основном соотношение объема работ vs результат от оного для меня любимого.
> Если ты хочешь посмотреть как я загоню zfs в полный ахтунг
> - да не вопрос, а какие плюшки мне за эту не
> нyжную персонально мне долботню мне за это обломятся? Никаких? Ну ой,
> так не интересно. Грубо прикинуть свойства дизайна и что для него
> будет откровенно (не)удобно я могу и просто посмотрев на дизайн и
> результаты различных бенчей, это достаточно тривиально и не требует много времени
> и подготовки кучи конфигураций. Улови мысль: чтобы я побежал клепать lab-like
> окружение и что-то там изучать, мне это должно быть зачем-то надо.

Это надо прежде всего тебе. Мы-то, пользователи ZFS, довольно хорошо представляем возможности того, чем уже пользуемся много лет. А вот ты, судя по твоим высказываниям, не имеешь сколь-нибудь практических знаний о предмете разговора (ZFS).


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 19:45 
Юзер, прекращай стрелки переводить. Тебе говорят: "пирожки не вкусные", а ты: "в соседней булочной они такие же". Кого интересует соседняя булочная, мы не о ней говорим сейчас.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 21-Фев-12 00:01 
> Юзер, прекращай стрелки переводить. Тебе говорят: "пирожки не вкусные", а ты: "в
> соседней булочной они такие же".

А я говорю: из всех доступных пирожков эти - лучшие. То что их можно сделать лучше - круто, да. Но вы кажется предлагаете остаться голодным.

> Кого интересует соседняя булочная, мы не о ней говорим сейчас.

Все познается в сравнении. Как-то не прикольно ходить голодным лишь на том основании что рецепт пирожков вон той булочной не идеален и можно лучше. Можно? Окей, сделайте. Я с удовольствием буду пользоваться вашими пирожками если они окажутся лучше. Правда вот создание такой ФС - весьма масштабная задача. Это не работа 1 дня и не для 1 человека.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 20-Фев-12 15:01 
> САМ МЕЙСОН

Выступление Мэйсона может посмотреть каждый (и даже ты) в последней его презентации по 3 ссылке после новости.
Даже с демонстрацией порчи блоков.
Так что хватит нести чушь.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено anonymous , 20-Фев-12 16:07 
Враньё.

Прекращайте на самом деле.

Фокусы с парой блоков делали еще в 1990 годах во времена моды на рейд массивы, это просто смешно. По факту полетевший раздел с BTRFS чинить нечем кроме grep и hexedit. Если повезет что испорченый блок имеет дубль (по умолчанию для одного устройства есть 2 копии метаданных) то как и в случае рейд массива это ты даже не заметишь. Речь не о том а о полном восстановлении с любой ситуации, с качеством работв как у легендарного fsck от ext/1/2/3.

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено а.н.а.н.и.м , 19-Фев-12 22:45 
у меня - не слетают.
на крикунов - положить с прибором.
ещё вопросы?

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 23:12 
> у меня - не слетают.
> на крикунов - положить с прибором.
> ещё вопросы?

К тебе персонально вопросов нет, сиди отдыхай. Только когда у тебя раздел слетит ( не дай Бог конечно, я такого даже тебе не пожелаю ), тогда не забудь поделиться способом его починки.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 23:21 
> К тебе персонально вопросов нет, сиди отдыхай. Только когда у тебя раздел
> слетит ( не дай Бог конечно, я такого даже тебе не
> пожелаю ), тогда не забудь поделиться способом его починки.

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 19-Фев-12 23:27 
Не слетит.
Всё просто - я знаю что делаю.

Зыж
И да, интернет также полон криков об улетевших extX, ufs, zfs, ntfs, xfs,...
Идиотов хватает всегда.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 23:36 
> Не слетит.
> Всё просто - я знаю что делаю.

Вполне может слететь - тестовый прототип. И лучше пусть у нас разделы слетают при тестировании чем потом, в реальном продакшне уже.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 19-Фев-12 23:45 
Не слетит. По крайней мере вероятность не больше, чем в других фс.
Я хорошо знаю структуру этой фс (к слову уже больше года замороженную и
она не сложнее особо ext4, почему extX и можно легко сконвертить в бтр).

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 01:14 
> Не слетит. По крайней мере вероятность не больше, чем в других фс.

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

> Я хорошо знаю структуру этой фс (к слову уже больше года замороженную и
>  она не сложнее особо ext4, почему extX и можно легко сконвертить в бтр).

EXT4 конвертится в бтр довольно читерским методом, оформляясь как снапшот, но это лишь лишний раз подчеркивает гибкость бтрфс :)


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 19-Фев-12 20:09 
> Чинилка в гите. Как я понял, они считают, что она не до конца отлажена

Вы не правильно поняли.
"не до конца отлажена" считают разработчики федеры.
Потому что у них инсталятор с втр не работает.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 21:10 
>> Чинилка в гите. Как я понял, они считают, что она не до конца отлажена
> Вы не правильно поняли.
> "не до конца отлажена" считают разработчики федеры.
> Потому что у них инсталятор с втр не работает.

Читал и версию об инсталлаторе, только это дешёвая отмазка. Федерасты же не полные идиоты, чтобы фс без "чинилки" в продакшн выпускать.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 19-Фев-12 23:17 
Я понимаю, обычный троль не в курсе.... но могу напомнить:
В бтр аж 3 чинилки (именно чинилки, а не проверялки):
1. Он чинится сам (при некорретном выключении, при монтировании в режиме rw.  На моём 500Гб думает приерно 20-30с)
2. btrfs scrub (см. презентаху по ссылке 3 после новости. Примерно на 16 минуте 45 с.
Очень убедительно). К слову - в zfs только этот способ.
3. fsck свежесозданный. И то только для поддержки посикса.

Внимание! Вопрос:
Если система (вечно эксперементальная. и созданная для этой цели) не ставится на фс, то виноват fsck?
Для троля, плохо владеющего вопросом - да.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 23:19 
> Читал и версию об инсталлаторе, только это дешёвая отмазка. Федерасты же не
> полные идиоты, чтобы фс без "чинилки" в продакшн выпускать.

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 23:26 
>> Читал и версию об инсталлаторе, только это дешёвая отмазка. Федерасты же не
>> полные идиоты, чтобы фс без "чинилки" в продакшн выпускать.
> Вообще-то федерасты так по жизни - группа тестовых камикадзе, которые своими тушками
> протестируют технологии которые потом когда-то попадают в ынтырпрайзный красношляп. Чего
> на них очканули бтрфс затестить - не понятно :)

Зачем же так про них ? Они конечно любят инновации, но обвинять их в "людоедстве" пожалуй не стОит. :-)


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 01:17 
> Зачем же так про них ? Они конечно любят инновации, но обвинять
> их в "людоедстве" пожалуй не стОит. :-)

Не вижу где я их обвинял в людоедстве. А то что они своих пользователей за тестовых пилотов считают - заметно невооруженным глазом. Почему на них нельзя оттестить brtfs до кучи - не понятно. Федористам не привыкать, а для остальных полезное дело.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено anonymous , 19-Фев-12 22:26 
Проверялка а не Чинилка. Уже 4 года она там. А в рассылке btrfs многолетние завтраки.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено а.н.а.н.и.м , 19-Фев-12 22:53 

3-я ссылка после новости ( https://www.opennet.ru/opennews/art.shtml?num=32974 )
там презентация где специально грохают фс до такого состояния, что она не монтируется.
восстановление за парусек.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 23:05 
Третья ссылка после новости называется: "OpenNews: Oracle портирует под Linux системы DTrace и Zones"

Где там про btrfs и пару секунд ?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 19-Фев-12 23:37 
На 16 минуте и 45 секунде.
Херят блоки и восстанавливают.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 20-Фев-12 04:18 
>Третья ссылка после новости называется: "OpenNews: Oracle портирует под Linux системы DTrace и Zones"

повторяем:
1. Главная ссылка к новости (http://www.phoronix.com/scan.php?page=ne...)
2. OpenNews: Переход Fedora на Btrfs откладывается
3. OpenNews: Компания Oracle намерена использовать Btrfs в дистрибутиве Oracle Linux
4. OpenNews: Обновление пакета btrfs-progs
5. OpenNews: Изучение изменения размера кодовой базы Ext4, Btrfs и XFS


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено anonymous , 20-Фев-12 00:20 
Да сколько тут маслом глаза позаливали.

СКРАБ это СКРАБ а не fsck!!!!!!!!1!!!!!11!!!!!!!!!!1!!!!!!

задача fsck это полная замена хакера которому дают диск и говорят: все пропало, спасай!

задача SCRUB совершенно другая. "у вас сбойнул рейд массив? вы хотите чего то большего чем просто замена на лету сбойного блока? Хотите в полуофлайне когда на сервер мала нагрузка заодно проверить всю поверхность вашего дорогущего рейд массива? Тогда мы идем к вам!".

Они похожи, но это не одно и то же.

FSCK, про который так долго гооврят аноним, все еще нет.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено а.н.а.н.и.м , 20-Фев-12 03:58 
да бред вы несёте.
1. fsck - это утилита проверки и восстановления файловой системы (ещё раз - ФАЙЛОВОЙ СИСТЕМЫ)
2. fsck - это утилита проверки и восстановления файловой системы по стандарту POSIX.
причём всех доступных и поддерживаемых фс, на функциональность которой (вне зависимости от типа фс) может рассчитывать система. и вот тут zfs как белая ворона, а в btr таки сделали.
3. проверка носителя производится внешней утилитой -
man fsck.ext4
...
-c     This option causes e2fsck to use badblocks(8) program
4. fsck.btrfs - это тот же scrub, оформленный по другому стандарту (ну может плюс ещё кое-что, как например вышеуказанный -с в fsck.ext4, вызывающий badblocks)

>задача fsck это полная замена хакера

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Клыкастый , 20-Фев-12 04:34 
>  и вот тут zfs как белая ворона,

"HAMMER — это файловая система доступная немедленно даже после падения и перезагрузки системы, здесь нет fsck ;"

по ходу дела вы что-то проспали.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 11:41 
> "HAMMER — это файловая система доступная немедленно даже после падения и перезагрузки
> системы, здесь нет fsck ;"

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 05:04 
> 4. fsck.btrfs - это тот же scrub, оформленный по другому стандарту (ну
> может плюс ещё кое-что,

Просто fsck при оффлайн проверках может позволить себе несколько больше чем все остальное. И по времени работы, и по интрузивности вмешательства.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 23:01 
Вот один из последних "завтраков" на которые я надеялся ( правда не из рассылки )...

> . . .
> Und fsck? Laut Mason steht die Veröffentlichung einer Version, die nicht nur lesend,
> sondern auch schreibend/korrigierend auf Btrfs zugreifen kann, kurz bevor. Grund hierfür
> ist dem Anschein nach die sich nähernde Freigabe der kommenden Versionen von Oracle Linux
> und SLES. Beide Produkte peilen an, Btrfs als Standard einzusetzen, was ohne ein
> funktionierendes fsck wohl eher ein Wunschdenken als eine ernstzunehmende Option für ein
> Unternehmensprodukt ist. Dementsprechend scheint der Termin für die Fertigstellung des
> Tools von Masons Arbeitgeber bereits festgelegt zu sein, und zwar auf den 14. Februar.

. . .

Взято отсюда: http://www.pro-linux.de/news/1/18019/fsck-tool-fuer-btrfs-na...
( Заметка была опубликована 9 февраля 2012 )

Краткий смысловой перевод, дословно переводить лень: По словам Мэйсона, ничто не препятствует
выпуску версии fsck, которая не только может читать, но и писать, и КОРРЕКТИРОВАТь btrfs.
Судя по всему дата релиза назначена работодателем Мэйсона на 14 февраля.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено anonymous , 20-Фев-12 00:25 
> Взято отсюда: http://www.pro-linux.de/news/1/18019/fsck-tool-fuer-btrfs-na...
> ( Заметка была опубликована 9 февраля 2012 )
> Краткий смысловой перевод, дословно переводить лень: По словам Мэйсона, ничто не препятствует
> выпуску версии fsck, которая не только может читать, но и писать, и
> КОРРЕКТИРОВАТь btrfs.
> Судя по всему дата релиза назначена работодателем Мэйсона на 14 февраля.

Угу, уже 20 февраля а Германа все нет...


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 20-Фев-12 00:51 
:-))))))

Спасибо за цитату, точно к месту !!!


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 01:19 
> Спасибо за цитату, точно к месту !!!

Да, с таким ником btrfs вам ну точно как кость в горле. Только он у нас будет. Вай-вай. Представьте себе.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 20-Фев-12 01:27 
>> Спасибо за цитату, точно к месту !!!
> Да, с таким ником btrfs вам ну точно как кость в горле.
> Только он у нас будет. Вай-вай. Представьте себе.

Разве я где-то говорил, что его у вас не будет ? Или желал чтобы его у вас не было ?

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

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 20-Фев-12 01:31 
>> Спасибо за цитату, точно к месту !!!
> Да, с таким ником btrfs вам ну точно как кость в горле.
> Только он у нас будет. Вай-вай. Представьте себе.

П.С.: И чем мой ник плох ? Да я не в восторге от btrfs, точнее от того как идёт её разработка. Лично мне всегда была симпатична РайзерФС, и какое-то время, когда Сюзя
её активно поддерживала, я райзера пользовал и проблем не имел.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 03:04 
> П.С.: И чем мой ник плох ? Да я не в восторге
> от btrfs, точнее от того как идёт её разработка. Лично мне
> всегда была симпатична РайзерФС, и какое-то время, когда Сюзя
> её активно поддерживала, я райзера пользовал и проблем не имел.

А вот парни с www.amule.org и еще куча счастливчиков были не в восторге от того как работает fsck у рейзера, при том таким факапам много лет и за много-много лет ничего не изменилось.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Yuri , 19-Фев-12 19:25 
Пилят. Не будет же такая фс оставаться без нее.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено BratSinot , 19-Фев-12 19:47 
ТАКАЯ fs еще как может без неё обходиться.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено sam002 , 19-Фев-12 20:13 
> ТАКАЯ fs еще как может без неё обходиться.

Не совсем, там можно повредить данные о "снимках". Есть уже btrfsck она не стабильная просто, но я пару раз уже пользовался. kernel-3.2, debian testing.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 21:06 
>> ТАКАЯ fs еще как может без неё обходиться.
> Не совсем, там можно повредить данные о "снимках". Есть уже btrfsck она
> не стабильная просто, но я пару раз уже пользовался. kernel-3.2, debian
> testing.

И что даёт "btrfsck" ? Она же только диагностику проводит, это же не "таблетка" для лечения.

На медни поимев проблемы с рутовым разделом скачал последний гпартед, и он этой самой "btrfsck" проблему нашёл, только лечить её нечем было.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено sam002 , 19-Фев-12 21:19 
Какое у Вас ядро?

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 22:00 
Ведро было 3.2.2 из ОпенСюсиного Тумблвида, а какое в последнем гпартеде не помню, можно наверное глянуть у них на странице.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 22:22 
P.S.:

Вот чего у гпартед в новостях написано про последний релиз...


> 19 January 2012: GParted Live 0.11.0-10 Stable Release
> Thanks to Steven Shiau, we have another stable GParted Live release.
> New in this release:
>     Fixed PXE booting on a computer with 2 or more network cards
>     Based on Debian Sid repository (as of 2012/Jan/11)
> Curtis

Взято отсюда: http://gparted.org/news.php


А какое ведро в дебиане я не знаю, кажется 3.1.1 ???


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 23:16 
> А какое ведро в дебиане я не знаю, кажется 3.1.1 ???

А может с такими познаниями не стоит лезть в тестовые камикадзи то? Расшибетесь же.

1) Посмотреть версию кернела можно, пардон, в uname -a или dmesg (а еще 2*2 == 4).
2) Если уж хочется потестить что-то экспериментальное, хорошо бы почитывать список рассылки и прочая чтобы понимать какие проблемы есть, ну и куча разработчиков под боком для их решения никому не вредила.
3) А если б с 1) и 2) у вас не было проблем, вы бы знали что в ядре 3.2 исправлен ряд стремных багов.
4) Если вы пошли в летчики-испытатели, внезапно возникшая необходимость катапультироваться у вас не должна вызывать вопросов. Ну вы знали на что шли, или где?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 20-Фев-12 01:04 
>[оверквотинг удален]
> еще 2*2 == 4).
> 2) Если уж хочется потестить что-то экспериментальное, хорошо бы почитывать список рассылки
> и прочая чтобы понимать какие проблемы есть, ну и куча разработчиков
> под боком для их решения никому не вредила.
> 3) А если б с 1) и 2) у вас не было
> проблем, вы бы знали что в ядре 3.2 исправлен ряд стремных
> багов.
> 4) Если вы пошли в летчики-испытатели, внезапно возникшая необходимость катапультироваться
> у вас не должна вызывать вопросов. Ну вы знали на что
> шли, или где?

8-) И чем мне должно было помочь знание "uname -a" ? Я и без uname знал, что у меня ведро номер 3.2.2 стоит. И система работала нормально, до поры до времени, а однажды просто сказала, что не может больше писать в "/temp", запуск btrfsck показал, что имеется ошибка. Для верификации этого факта, был скачан последний релиз гпартеда и проведена проверка ещё и им. Гпартед проблему подтвердил. И что дальше ??? Лечить-то нечем !!!

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 01:27 
> И система работала нормально, до поры до времени, а однажды просто
> сказала, что не может больше писать в "/temp", запуск btrfsck показал,
> что имеется ошибка.

Круто. Если полагаете что это именно проблема btrfs - вон там Крис в списке рассылки, ну и прочая. Им наверняка это понравится. В том числе было бы хорошо не только понять как сие чинить но и понять "какого хрена оно _так_ сломалось".

> Для верификации этого факта, был скачан последний релиз
> гпартеда и проведена проверка ещё и им. Гпартед проблему подтвердил.

А он вообще при чем? Что-то слабо догоняю как он связан с btrfs сам по себе. Как сия проблема звучит то хотя-бы? А то такое крутое описание, конечно - "у меня проблема".

> И что дальше ??? Лечить-то нечем !!!

А вот Крису и предъявить факты, если вы в состоянии сделать это квалифицированно. Правда учтя что вы версию кернела не знаете - я что-то сомневаюсь в этом.

> Я прекрасно сознавал, что фс и её поддержка ещё сыровата, потому очень
> долго её не пробовал, но после хвалебных отзывов во многих местах
> интернетов рискнул таки поставить опенсюзю 12.1 на бтрфс, ибо fsck было
> обещано и Мэйсон зуб давал, что вот-вот, буквально после завтра... Два
> месяца оно бегало и не жужжало...

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 20-Фев-12 01:40 
> Круто. Если полагаете что это именно проблема btrfs

Я не полагаю, мне это btrfsck подтвердил, как "набортный", так и из gparted.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 02:04 
> Я не полагаю, мне это btrfsck подтвердил, как "набортный", так и из gparted.

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

С практической точки зрения я бы
1) Пока не юзал бы сие как корень основной ОС от отказа которой что-то всерьез зависит.
2) Если бы мне были нужны файлы - достал бы их вполне годной недеструктивной утилитой, потенциально прихранив образ диска или диск до лучших времен.
3) Налетев на баг - не грех отписаться, да? Это не майкрософт, у которых ntfs.sys уже 10-й год подряд в бсоды сыпется при определенном разрушении ФС, а всем похрену. Тут баги еще и чинят иногда.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 20-Фев-12 02:14 
Отписаться наверное следовало бы, но в порыве злобы всё было снесено подчистую. Данные, которых и было-то немного не потерял, потерял только время на переустановку и немного нервов.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 03:21 
> Отписаться наверное следовало бы, но в порыве злобы всё было снесено подчистую.

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

Что до качества и прочего, советую так:
- Если вы не хотите въезжать, ждите отмашки с официальным объявлением о стабильности, внедрежом по дефолту в ынтырпрайзные дистры, а совсем параноики могут еще 1-2 года погодить, дабы авангардисты ну уж совсем наверняка вытоптали все сколь-нибудь частые и стремные баги.
- Если вы хотите погонять тестовый прототип, вы должны понимать что он не обязан быть идеален и что это - некоторый риск. Закладываться на него в ситуации когда от отказа что-то реально зависит - вас не красит. Это превью технологии, оно может отказать. И даже более того, все слабые места должны быть пойманы на именно этом этапе, до того как в них влипнут обычные эксплуатационщики.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено а.н.а.н.и.м , 20-Фев-12 04:03 
>> Отписаться наверное следовало бы, но в порыве злобы всё было снесено подчистую.
>Странный какой-то подход - злиться на тестовый образец, специально выкаченный чтобы погонять и (возможно) раздолбать.

сомневаюсь что он вообще это проделывал.
по комментам вообще же плавает в теме.
просто троллит и всё.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 05:07 
> просто троллит и всё.

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 21-Фев-12 04:32 
> версия выглядит довольно правдоподобно

Не тролю, не имею таких наклонностей. Что за теории заговоров такие ?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 19-Фев-12 20:05 
Не поверишь, но она и без этой утили самовостанавливается.
В zfs вон вообще и не обещают даже.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 21:08 
> Не поверишь, но она и без этой утили самовостанавливается.
> В zfs вон вообще и не обещают даже.

Конечно не поверю, ибо не восстановилась, заявляю как очевидец.

Подкинуть ещё пруфов из различных форумов?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 21:18 
>> Не поверишь, но она и без этой утили самовостанавливается.
>> В zfs вон вообще и не обещают даже.
> Конечно не поверю, ибо не восстановилась, заявляю как очевидец.
> Подкинуть ещё пруфов из различных форумов?

Не трынди.

1. Избыточность с физическими зеркалами никто не отменял - это раз.

2. Передача снэпов по сетке на бэкап-сервер - и ты спасен почти от всего - это два.

3. Аманда бэкап поддерживает резервирование и восстановление всего, вплоть до корневых разделов на ZFS с bare metal с восстановлением загрузки - это три.

Форумы анонимных вась пупкиных имя которых никто и звать их никак мне лично вообще не авторитет. Есть целый банк, работающий на ZFS в продакшене, уже шесть с лишним лет сидит и не жужжит.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Виндус , 19-Фев-12 22:03 
. . .

> Форумы анонимных вась пупкиных имя которых никто и звать их никак мне
> лично вообще не авторитет. Есть целый банк, работающий на ZFS в
> продакшене, уже шесть с лишним лет сидит и не жужжит.

Товарищ, глянь на название статьи, какая ZFS?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 16:53 
ZFS не я тут приплетаю. И, будь добр, обрати внимание, что ZFS и BTRFS концептуальные РОДСТВЕННИКИ.

"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 23:08 
> 1. Избыточность с физическими зеркалами никто не отменял - это раз.

Повреждение ФС на логическом уровне в результате сбоев железа или софта никто не отменял. От этого резервирование спасти вообще не обязано.

> 2. Передача снэпов по сетке на бэкап-сервер - и ты спасен почти от всего - это два.

"Ну тогда и тормозная отказоустойчивая файловая система с зеркалами тебе ни к чему". На манер анекдота про жигуля и колеса.

> 3. Аманда бэкап поддерживает резервирование и восстановление всего, вплоть до корневых
> разделов на ZFS с bare metal с восстановлением загрузки - это три.

Вот только время на эту операцию _категорически_ не доставляет, при том машина все это время не сможет работать в нормальном качестве, что очевидно.

> Есть целый банк, работающий на ZFS в продакшене, уже шесть с лишним лет сидит и не жужжит.

Аж целый 1 банк. Вау. Аффтаритет \m/ \m/. А сбер вон использует WinXP варезную на банкоматах, это - показатель что так и надо? :)


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 16:56 
>> 1. Избыточность с физическими зеркалами никто не отменял - это раз.
> Повреждение ФС на логическом уровне в результате сбоев железа или софта никто
> не отменял. От этого резервирование спасти вообще не обязано.

Правильно. От этого спасают другие средства. Подсказать, какие, или и сам в состоянии допетрить?

>> 2. Передача снэпов по сетке на бэкап-сервер - и ты спасен почти от всего - это два.
> "Ну тогда и тормозная отказоустойчивая файловая система с зеркалами тебе ни к
> чему". На манер анекдота про жигуля и колеса.

Не передергивай, чувак. Нормальный человек не "вместо", а "вместе" делает. Для HA.

>> 3. Аманда бэкап поддерживает резервирование и восстановление всего, вплоть до корневых
>> разделов на ZFS с bare metal с восстановлением загрузки - это три.
> Вот только время на эту операцию _категорически_ не доставляет, при том машина
> все это время не сможет работать в нормальном качестве, что очевидно.

А зеркала и стэндбаи ты забываешь? Что в misson critical никто не ограничится только зеркалированием или только бэкапом - тебе надо объяснять? Или само догадаешься, о админ локалхоста?

>> Есть целый банк, работающий на ZFS в продакшене, уже шесть с лишним лет сидит и не жужжит.
> Аж целый 1 банк. Вау. Аффтаритет \m/ \m/. А сбер вон использует
> WinXP варезную на банкоматах, это - показатель что так и надо?
> :)

Не трынди мне про XP. Речь не о периферии второстепенной, а о серверной инфре. Это раз. Два - целый банк второго уровня одной весьма некислой страны. Примерно масштабов сбера. Еще вопросы будут?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 17:24 
> Правильно. От этого спасают другие средства. Подсказать, какие, или и сам в
> состоянии допетрить?

Ага, можно например забабахать распределенную ФС, так что вылет 2 серверов из 50 по любой причине - вообще никто и не заметит. Правда так не катит если серверов всего полторы штуки. Вот незадача.

>>> 2. Передача снэпов по сетке на бэкап-сервер - и ты спасен почти от всего - это два.
>> "Ну тогда и тормозная отказоустойчивая файловая система с зеркалами тебе ни к
>> чему". На манер анекдота про жигуля и колеса.
> Не передергивай, чувак. Нормальный человек не "вместо", а "вместе" делает. Для HA.

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

[...]
>>> разделов на ZFS с bare metal с восстановлением загрузки - это три.
>> Вот только время на эту операцию _категорически_ не доставляет, при том машина
>> все это время не сможет работать в нормальном качестве, что очевидно.
> А зеркала и стэндбаи ты забываешь?

"А вот у меня тут СОВЕРШЕННО СЛУЧАЙНО оказался РОЯЛЬ В КУСТАХ". Ну да, хорошо если у вас совершенно случайно рояли в кустах, всегда в нужном месте в нужное время. Кто же спорит? Однако в жизни так почему-то бывает не всегда.

> Что в misson critical никто не ограничится только зеркалированием или только
> бэкапом - тебе надо объяснять? Или само догадаешься, о админ локалхоста?

Количество апломба просто доставляет. А ты у себя дома файло тоже так хранишь, да? С отдельным серваком бэкапирования, кучей зеркал, ... ? Может у тебя еще и 19" холодильник дома установлен, забитый юнитами до отказа? :)

>> Аж целый 1 банк. Вау. Аффтаритет \m/ \m/. А сбер вон использует
>> WinXP варезную на банкоматах, это - показатель что так и надо?:)
> Не трынди мне про XP. Речь не о периферии второстепенной,

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

> а о серверной инфре. Это раз. Два - целый банк второго уровня одной
> весьма некислой страны. Примерно масштабов сбера. Еще вопросы будут?

Не, что вы, понтов достаточно. Чего уж там. Ну раз у вас столько понтов - можете отдуться за этот ваш понтовый ZFS вон там в треде выше. По предъявам Шишкина/Тсо/... :)


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Клыкастый , 19-Фев-12 22:22 
> В zfs вон вообще и не обещают даже.

scrub


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 19-Фев-12 23:03 
> scrub

До умений fsck по починке тома ему как пешком до пекина. И что самое веселое, если что-то идет не так - вы остаетесь 1 на 1 с огромной монструозной штукой и хексэдитором для ее колупания. Есть надежды что линуксоиды не будут жрать маркетинговый булшит и фанские визги и сделают все правильно.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Клыкастый , 20-Фев-12 01:25 
> До умений fsck по починке тома ему как пешком до пекина.

конкретнее?

> надежды что линуксоиды не будут жрать маркетинговый булшит и фанские визги и сделают все правильно.

у них есть расово верный булшит - вечнозелёная btrfs без ремонта вообще.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 01:58 
> конкретнее?

fsck должен делать проверку всех структур ФС на логическую непротиворечивость, корректность, и при необходимости - чинить откровенно некорректные метаданные или хотя-бы нейтрализовать их до состояния в котором это можно будет смонтировать (пусть в слегка потрепаном виде, перспектива руками и хексэдитором выдирать файлы парся том лично - хуже).

> у них есть расово верный булшит - вечнозелёная btrfs без ремонта вообще.

Зато будет доведен до ума, в отличие от бсдунов, которые еле успевают бэкпортить из соляры халявку, а о тулзах типа fsck даже заикаться боятся. Тут люди сами делают себе ФС и могут контролировать развитие. Оракловый архитект - задает мотив, но остальные как видим вполне могут предлагать полезные плюшки. А вы, пардон, судорожно копипастите^W бэкпортируете из соляры. Влияние бсдунов на процесс развития ФС - НОЛЬ. Апстриму такая стая прихлебателей как-то не сдалась - оркл вообще взял и закрыл соляру. В лине как-то умнее получилось, как обычно.

И да, какой-никакой fsck все-таки сделали. Да, пока примитивный и сырой. Так у вас даже такого и даже в проекте нет. А еще прикольная недеструктивная утиль для выуживания файлов с сильно убитого тома. Это не fsck, скорее что-то по мотивам утилей типа Tiramisu Data Recovery for FAT32/NTFS. Только вот от авторов ФС и занахаляву, в отличие от... - как я понимаю, и такого у вас тоже нет. А зря. Потому что 100% гарантии что починка сделает лучше чем было - нет, а вот так - всяко можно отколупать наиболее нужные файлы даже с очень серьезно убитых томов (лишь бы распарсились метаданные описывающие нужные файлы, что довольно мягкое требование к степени убитости тома).


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Клыкастый , 20-Фев-12 03:31 
>> конкретнее?
> fsck должен делать проверку всех структур ФС на логическую непротиворечивость, корректность, и при необходимости - чинить откровенно некорректные метаданные или хотя-бы нейтрализовать их до состояния в котором это можно будет смонтировать (пусть в слегка потрепаном виде, перспектива руками и хексэдитором выдирать файлы парся том лично - хуже).

я так понял, бегуна обвиняют в отсутсвие ремкомплекта к костылям?


>> у них есть расово верный булшит - вечнозелёная btrfs без ремонта вообще.
> Зато будет доведен до ума,

посмотри правде в глаза, мальчик: btrfs fsck пилит уже ооочень долго, под непрекращающийся вой фанбоев, что у фряхи zfs вот-вот отберут.


> в отличие от бсдунов, которые еле успевают бэкпортить из соляры халявку,

дружочек, это опенсорс. как забавно слышать обвинение в халявке от жадных деток, которые воют, что эппл из СВОЕГО купса ихнюю аваху выпилила...

кстати, а портирование ZFS в линупс - это ведь другое дело, верно? вы и денежки платите, и влияние на развитие оказываете, нет?

>  а о тулзах типа fsck даже заикаться боятся.

несомненно. там где надо fsck - оно во фре есть (UFS). где не надо - нет. всё просто, верно?

> А вы, пардон, судорожно копипастите^W бэкпортируете из соляры.

Деточка, это опенсорс.

> Влияние бсдунов на процесс развития ФС - НОЛЬ.

ты как-то совсем уж разволновался - дать платочек?

> В лине как-то умнее получилось, как обычно.

зоопарк недопиленых фс?

> И да, какой-никакой fsck все-таки сделали.

никакой :) это называется - никакой. но зато влияние на развитие - 100% :)

> А еще прикольная недеструктивная утиль для выуживания файлов с сильно убитого тома.

утиль - это отлично сказано.

> от... - как я понимаю, и такого у вас тоже нет.

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

> А зря. Потому что 100% гарантии что починка сделает лучше чем было - нет,

zpool import -F, scrub. а костылики фряшники вам оставят :)



"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 04:57 
> я так понял, бегуна обвиняют в отсутсвие ремкомплекта к костылям?

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

>> Зато будет доведен до ума,
> посмотри правде в глаза, мальчик: btrfs fsck пилит уже ооочень долго,

Нельзя ли пояснить - кто и где его "долго пилит"? Я смотрю правде в глаза. В самом логичном месте - списке рассылки бтрфс который я регулярно читаю. Поэтому я хорошо представляю себе что, где и как, в отличие от любителей бухтеть. Крис как-то его по жизни оставляет на потом, в основном руководствуясь довольно логичным соображением что в принципе ФС чинится довольно просто и потому он много времени не займет. То что Крис не всегда верно рассчитывает время - есть такое дело. С другой стороны, для такого масштабного проекта точно рассчитать время может только шарлатан.

> под непрекращающийся вой фанбоев, что у фряхи zfs вот-вот отберут.

Отобрать - не отберут. Правда опенсоляру - отобрали. Поэтому весь "вектор развития" сводится к бэкпортированию с очень большим отставанием. Перспективы такого подхода мне не ясны. Мне даже не ясно насколько оракл намерен развивать ZFS. По логике вещей, им намного выгоднее содержать одного Криса, задающего общий вектор развития дизайна новой ФС как архитект, а остальное пусть ядерщики пингвина и те кому этот дизайн нужен делают.

> дружочек, это опенсорс. как забавно слышать обвинение в халявке от жадных деток,

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

> которые воют, что эппл из СВОЕГО купса ихнюю аваху выпилила...

Как это - выпилила? Напротив, япл всегда был любителем протокола автодискавери "бонжур", который эта самая аваха и реализует в аккурат. Может до того как троллить стоит хоть минимально разобраться в вопросе? ;)

> кстати, а портирование ZFS в линyпс - это ведь другое дело, верно?
> вы и денежки платите, и влияние на развитие оказываете, нет?

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

> несомненно. там где надо fsck - оно во фре есть (UFS). где не надо - нет. всё просто, верно?

"У нас этого нет, поэтому это не нyжно". Знаем знаем. Не, я понимаю что выбирая из окаменевших какашек мамонта ака UFS и хоть чего-то еще - хотьчтотоеще в любом виде выглядит как спасительная соломинка. Однако посмотрев всяких лисяр, списки рассылки и прочее я как-то неожиданно для себя осознал что совсем не хочу так же бодаться при удобном случае. А поскольку факапы бывают разные, блеяние про "не надо" оставьте себе. Вам не надо? А _мне_ надо, просто потому что идея расколупывать кишки навернутого пепелаца хексэдитором не вызывает энтузазизма, хоть я и могу это изобразить если припрет. Для меня это достаточный критерий чтобы не юзать ФС в продакшне. Выбирая из полдюжины вполне приличных и работающих наименований ФС я вполне могу себе позволить не соглашаться с идеей "3й сорт - не брак". Это у вас там выбирать не из чего, поэтому приходится кушать то что есть.

>> А вы, пардон, судорожно копипастите^W бэкпортируете из соляры.
> Деточка, это опенсорс.

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

>> Влияние бсдунов на процесс развития ФС - НОЛЬ.
> ты как-то совсем уж разволновался - дать платочек?

Я вроде бы спокоен как удав и всего лишь капитаню понемногу. А чего мне нервничать то?

>> В лине как-то умнее получилось, как обычно.
> зоопарк недопиленых фс?

Заметьте, сие позволяет не жрать что попало по принципу "3-й сорт не брак". А у вас мало того что отставание от апстрима дикое, так еще и толпы багов. При том т.к. ваш апстрим клал на *бсд с прибором, а своих разработчиков у бсдунов полтора землекопа - у меня есть ощущение что ваш "какбы продакшн" так и останется в типичном для него "качестве" навечно, когда списки рассылки и форумы засраны визгами, а единственным вариантом фикса серьезно убитой ФС является парсинг хексредактором и мозгом. По крайней мере причин почему бы это стало не так - я придумать не смог. Сабжевые новости вот почему-то про бтр.

>> И да, какой-никакой fsck все-таки сделали.
> никакой :) это называется - никакой. но зато влияние на развитие - 100% :)

Ну так у вас ничего эквивалентного даже в фазе planning нет. Значит в ближайшие 3-5 лет этого у вас гарантированно не будет даже в таком состоянии. Тем более что Крис хвастался что btrfs с самого начала был задизайнен так что его должно быть довольно просто чинить. Хорошо если архитект заранее о таком подумал на фазе дизайна. Потом - хреновее. Вот сани и кормят всех маркетинговым шитом что мол а нам оно не нyжно, и вообще, бэкапы вам в руки, блабла.

>> А еще прикольная недеструктивная утиль для выуживания файлов с сильно убитого тома.
> утиль - это отлично сказано.

Ага. Позволяет не сдавать в утиль файловую систему когда ее можно починить.

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

Наши загрузчики - вполне нормальные. Они работают. Нас устраивает. У нас их даже более 1 есть, на разные вкусы. От простеньких типа u-boot, которые целиком заменяют bios-like окружение на эмбеддовке, до монстриков типа grub2 являющихся по сути мини-операционкой и умеющих все что угодно. И рэйды запросто читать, и с btrfs грузиться, и что я там еще забыл. В общем троллинг не удался - тролль туповат и не рубит в вопросе.

>> А зря. Потому что 100% гарантии что починка сделает лучше чем было - нет,
> zpool import -F, scrub. а костылики фряшники вам оставят :)

Только вот упомянутое - и близко не аналог fsck по эффективности хардкорного репайра совсем убитой ФС, которую все-таки хочется смаунтить но совсем не хочется пересоздавать с нуля и целиком ресторить из бэкапа, ибо сие долго и геморройно.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Клыкастый , 20-Фев-12 06:05 
В тебе гибнет Толстой.

>> я так понял, бегуна обвиняют в отсутсвие ремкомплекта к костылям?
> В случае с бегуном и костылями - проблемы будут только у бегуна.
> А вот когда механика файловой системы облажается настолько что драйвер это
> переварить не сможет

Дружище, HAMMER вааще без fsck. И в ZFS он без (особой) надобности. И, по идее в btrfs, если то, с чего они рисовали воплощено без косяков.

> Крис как-то его по жизни оставляет на потом, в основном руководствуясь довольно логичным соображением что в принципе ФС чинится довольно просто и потому он много времени не займет.

:)

>[оверквотинг удален]
> не ясны. Мне даже не ясно насколько оракл намерен развивать ZFS.
> По логике вещей, им намного выгоднее содержать одного Криса, задающего общий
> вектор развития дизайна новой ФС как архитект, а остальное пусть ядерщики
> пингвина и те кому этот дизайн нужен делают.
>> дружочек, это опенсорс. как забавно слышать обвинение в халявке от жадных деток,
> Я не вижу где я кого обвинял. Я всего лишь отметил что
> не считаю такой "стиль взаимодействия с апстримом" эффективным и ведущим к
> какому-то осмысленному результату.
>> которые воют, что эппл из СВОЕГО купса ихнюю аваху выпилила...
> Как это - выпилила?

здрааассьте. https://www.opennet.ru/opennews/art.shtml?num=33126

> А ZFS надо весь целиком пилять самостоятельно, потому что с комьюнити как-то не сложилось, патчи типа сабжа что-то никто не шлет.

Ну я думаю оракль это переживёт.

> "У нас этого нет, поэтому это не нyжно". Знаем знаем. Не, я
> понимаю что выбирая из окаменевших какашек мамонта ака UFS и хоть
> чего-то еще - хотьчтотоеще в любом виде выглядит как спасительная соломинка.

UFS + geom вполне себе даже.

> я и могу это изобразить если припрет. Для меня это достаточный
> критерий чтобы не юзать ФС в продакшне. Выбирая из полдюжины вполне
> приличных и работающих наименований ФС я вполне могу себе позволить не
> соглашаться с идеей "3й сорт - не брак". Это у вас
> там выбирать не из чего, поэтому приходится кушать то что есть.

у нас в продакшне как ufs с примочками, так и zfs. zfs за 6 лет ремонтировалось единожды. успешно.


> родил оракль. Хотя номинально это опенсорс, взаимодействие апстрима и даунстрима почти
> отсутствует и эффективность всего этого процесса в долговременном плане вызывает ряд
> вопросов.

именно поэтому с марта прошлого года зреет мысль пилить в меньшей зависимости от оракля.

> Заметьте, сие позволяет не жрать что попало по принципу "3-й сорт не
> брак".

ZFS это самый что ни на есть высший сорт. Из претендентов на этот высший сорт только btrfs, reiser4, HAMMER. Последнее нишевое, предпоследнее слегка в загоне.


> А у вас мало того что отставание от апстрима дикое,

кому оно мешает?

> так еще и толпы багов.

ZFS в стэбле и в общем, заслуженно.

> Сабжевые новости вот почему-то про бтр.

но кроме экспериментаторов Федоры охотников её втыкать немного.

> Ну так у вас ничего эквивалентного даже в фазе planning нет. Значит в ближайшие 3-5 лет этого у вас гарантированно не будет даже в таком состоянии.
> Тем более что Крис хвастался что btrfs с самого начала был задизайнен так что его должно быть довольно просто чинить. Хорошо если архитект заранее о таком подумал на фазе дизайна.

сани хвастались что вообще не нужно :)

> Потом - хреновее. Вот сани и кормят всех маркетинговым шитом что мол а нам оно не нyжно,

Мэтью с хаммером тоже считает, что не нужно.

> И рэйды запросто читать,

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


> Только вот упомянутое - и близко не аналог fsck по эффективности хардкорного
> репайра совсем убитой ФС,

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


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 13:50 
> В тебе гибнет Толстой.

А в тебе - толстый...

> Дружище, HAMMER вааще без fsck.

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

> И в ZFS он без (особой) надобности.

Ну мало ли. Кому-то и страховка кажется ненужной, можно же по вертикальной скале и без нее шпарить. Правда паштет потом убирать нравится не всем. Вот я - не люблю паштет из файловых систем под хексэдитором колупать. Хоть и умею в принципе.

> И, по идее в btrfs, если то, с чего они рисовали воплощено без косяков.

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

[тут было много букв]
>> Как это - выпилила?
> здрааассьте. https://www.opennet.ru/opennews/art.shtml?num=33126

Да, спасибо. Ща я вас цитатой с вашей же ссылки и огрею:
======
> Но CUPS пока не умеет взаимодействовать с Avahi,

======

В каком месте тут говорится о том что яппл что-то связанное с Avahi _удалил_? Они удалили какой-то иной метод автодискавери.

>> А ZFS надо весь целиком пилять самостоятельно, потому что с комьюнити как-то не
>> сложилось, патчи типа сабжа что-то никто не шлет.
> Ну я думаю оракль это переживёт.

Они корпорация. Они бабки зарабатывают. Если клиентура начинает хотеть линь а там еще и половину разработки можно на майнлайн ядерщиков сгрузить - sounds like a plan! Можно подумать ораклу большая разница что продавать. Я думаю их устроить продавать и unbreakable linux как подстилку под их БД, они вон уже понтуются что затюнено и обходит шапку там и сям на столько-то и столько-то. А почему бы и нет? Уж наверное они могут под себя тюнить лучше чем красношапка, являющаяся general purpose.

> UFS + geom вполне себе даже.

Выкрасить и выбросить. Устройство всех базовых дисковых структур там архаичное до неприличия. Совсем олдскульный дизайн, из линуховых сравнить можно с чем-то типа ext2 по уровню развития, не больше. Так ведь EXTы и то за столько лет окультурили, ext4 даже ничего так вышел. А эти зассали - ресурсов мол на это нет. Куча крЮтых уровней абстракции к одной древненькой ФС с антикварненьким устройством - труЪ bsd way. Подумаешь, ездит хреново. Зато как музейный экспонат и фетиш академика - вещь. Зато если бенчи посмотреть - так сразу и не понятно, чего же там хорошего. Как задизайнено так и работает.

[...потерто...]
> у нас в продакшне как ufs с примочками,

Примерно как сказать "а я тут на днях ext2 освоил". Такое новье и круть, конечно.

> так и zfs. zfs за 6 лет ремонтировалось единожды. успешно.

Если брать 1 сферического баклана в вакууме - у меня (а чем я хуже?) вот в последнее время и btrfs не получилось всерьез убить ни разу, даже с специальными подлянками. Это однако вовсе не значит что он - продакшн-риди.

>> и эффективность всего этого процесса в долговременном плане вызывает ряд вопросов.
> именно поэтому с марта прошлого года зреет мысль пилить в меньшей зависимости от оракля.

Плохо себе представляю техническую реализацию этой мысли. В случае с btrfs все получилось довольно естественно и хорошо и для оракла и для остальных. От них архитект, от ядерщиков остальные. Оракл может до некоторой степени влиять на результат, и остальные могут, о чем и сабж. И всем хорошо: и ораклу (который барыжит unbreakable linux и шкурно заинтересован), и остальным (которым такая штука тоже не помешает, а тут еще и оракл архитекта оплачивает к тому же). В случае с zfs по сути есть две параллельные вселенные: оракл который что-то там, внутри себя, и команда которая ораклу перпендикулярна, не приносит ему никакого профита и вообще до некоторой степени конкуренты, помогать которым да ну наф (ну нет у оракла никакого внятного бизнеса на *bsd вроде как)

>> Заметьте, сие позволяет не жрать что попало по принципу "3-й сорт не брак".
> ZFS это самый что ни на есть высший сорт.

Один из первых дизайнов подобного рода. Содержащий кучу спорных моментов. Даже без нормального экстентного аллокатора. Понятный пень что такой дезигн приходится подпирать тоннами оперативы чтоб не тормозило.

> Из претендентов на этот высший сорт только btrfs, reiser4, HAMMER. Последнее
> нишевое, предпоследнее слегка в загоне.

Ну вот лично я ставлю на то что первый в долговременном плане всех обрулит. Даже zfs.

>> А у вас мало того что отставание от апстрима дикое,
> кому оно мешает?

Чисто как индикатор процессов приведено, не более.

>> так еще и толпы багов.
> ZFS в стэбле и в общем, заслуженно.

У бсдунов? Ну знаете, с таким стэйблом и бтрфс можно пожалуй стэйблом объявлять. Scrub тоже умеет, а на 3 ноутбучных дисках - диск под нагрузкой помрет быстрее чем btrfs, пожалуй. А то что потом списки рассылки будут как у бсдельников - так стэйбл, ага :]

>> Сабжевые новости вот почему-то про бтр.
> но кроме экспериментаторов Федоры охотников её втыкать немного.

Ну так сначала экспериментаторы, потом ынтырпрайзы. У вас то все проще - нет ынтырпрайзов, нет проблем...

>> должно быть довольно просто чинить. Хорошо если архитект заранее о таком подумал на фазе дизайна.
> сани хвастались что вообще не нyжно :)

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

>> Потом - хреновее. Вот сани и кормят всех маркетинговым шитом что мол а нам оно не нyжно,
> Мэтью с хаммером тоже считает, что не нyжно.

А я считаю иначе. Хорошо что мне Мэтью и хаммер перпендикулярны. Потому что я вполне могу себе представить факапы которые требуют именно утиль класса fsck. Блеяние про не нyжно это конечно здорово. Пока не нарисуется перспектива колупать кишки довольно навернутой штуки хекс-редактором как вообще единственная оставшаяся альтернатива по приведению ее в монтируемое состояние и/или вытаскиванию оттуда новотщапрямблиннужныхпозарез файлов на которые как назло не оказалось бэкапа.

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

Подозреваю что grub2 может вообще просто взлететь с резервного трека и читануть этот ваш рэйд. А вариантов есть дохрена и валидных наверное можно придумать с полдюжины.

>> Только вот упомянутое - и близко не аналог fsck по эффективности хардкорного
>> репайра совсем убитой ФС,
> что такое "хардкорный репайр"?

В идеале - когда ФС доводится до монтируемого состояния даже при очень тяжелых разрушениях. Да, с потерей того что затронуто. Лучше cp или mc копировать файлики нежели хексэдитором самому их выколупывать, если что. Попроще как-то.

> что такое "совсем убитая фс"?

Это ФС, структуры которой были порушены несколько более чем те тепличные условия которые допущены всякими авторами ZFS, хаммеров и прочих - по их мнению бэдов на дисках не бывает, софт не сбоит, а если вдруг это не так - ну вы же не обломитесь раскатать бэкап на несколько терабайт, правда-правда? :)

> вытащить ещё _гарантировано_ живые файлы?

Как минимум.

> вытянуть файлы, неизвестно живые или нет?

Как улучшенная опция. Посмотреть глазами валидность файла проще чем хексэдитором по кусочкам его собирать по всему диску. Особенно не дай боже если там райд/сжатие/шифрование. Особенно прикольно если все вместе - "фантомас в очках на аэроплане" (c) анекдот.

> оно надо далеко не всем и не всегда.

Зато когда стало надо - хреново если этого нет.

> Например куски мускулевской базы... что делать
> если таблицы дохлые... живые могут не иметь смысла...

Я не спорю что _бывают_ повреждения при которых реально остается только достать файл из бэкапа. Однако сие совсем не повод забить на лишний шанс отколупать данные + избежать гемора с пересборкой пула с нуля + полной перераскаткой из бэкапа.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено ананим , 20-Фев-12 04:12 
>у них есть расово верный булшит - вечнозелёная btrfs без ремонта вообще.

врёшь.
btrfs scrub start [-Bdqr] <path>|<device>
        Start a new scrub.
btrfs scrub cancel <path>|<device>
        Cancel a running scrub.
btrfs scrub resume [-Bdqr] <path>|<device>
        Resume previously canceled or interrupted scrub.
btrfs scrub status [-d] <path>|<device>
        Show status of running or finished scrub.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Клыкастый , 20-Фев-12 04:41 
>>у них есть расово верный булшит - вечнозелёная btrfs без ремонта вообще.
> врёшь.
> btrfs scrub

"> scrub
До умений fsck по починке тома ему как пешком до пекина."

пролечи тогда анонима сам. а то уже задолбало: в btrfs скраб правильный, в zfs - нет. и так по каждому пункту.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 04:59 
> пролечи тогда анонима сам. а то уже задолбало: в btrfs скраб правильный,
> в zfs - нет. и так по каждому пункту.

Аноним в 100-й раз намекает что скраб - не есть аналог fsck. И то что он есть и в btrfs еще не значит то btrfs'у простят отсуствие fsck. Не прокатит так, это не бсдуны у которых выбирать не из чего.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Аноним , 20-Фев-12 17:02 
>> пролечи тогда анонима сам. а то уже задолбало: в btrfs скраб правильный,
>> в zfs - нет. и так по каждому пункту.

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

> Аноним в 100-й раз намекает что скраб - не есть аналог fsck.
> И то что он есть и в btrfs еще не значит
> то btrfs'у простят отсуствие fsck. Не прокатит так, это не бсдуны
> у которых выбирать не из чего.

Пуркуа, собссна?



"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено iZEN , 20-Фев-12 18:45 
>> scrub
> До умений fsck по починке тома ему как пешком до пекина.

fsck уже умеет выводить список повреждённых и невосстановимых файлов?
fsck уже не переименовывает найденные повреждённые файлы, давая новые бессмысленные имена, и не переносит такие файлы в одно место?

> И что самое веселое, если что-то идет не так - вы остаетесь
> 1 на 1 с огромной монструозной штукой и хексэдитором для ее
> колупания.

В ZFS scrub в конце работы на повреждённом пуле выносит вердикт (status) в виде человекочитабельного списка файлов, которые повреждены и которые не удалось восстановить силами ZFS. Будущий btrfsck или же сегодняшний btrfs scrub такой же список могут предоставить?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено pavlinux , 20-Фев-12 21:00 
> Будущий btrfsck или же сегодняшний btrfs scrub такой же список могут предоставить?

Накой он тебе? Сам не исправишь, на ночь, перед сном почитать если только.


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено iZEN , 20-Фев-12 21:45 
>> Будущий btrfsck или же сегодняшний btrfs scrub такой же список могут предоставить?
> Накой он тебе? Сам не исправишь, на ночь, перед сном почитать если только.

Ну, началось: "зачем он тебе?", "что ты будешь с ним делать?". И тут же идут предположения: "почитать на ночь" — очевидно, "чтобы крепче спать и больше не думать об этом". :))

Самому, что, не судьба понять, для чего нужен список покоцаных файлов с полными путями к ним?



"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено pavlinux , 22-Фев-12 04:31 
> Самому, что, не судьба понять, для чего нужен список покоцаных файлов с полными путями к ним?

Неа. А зачем?


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено iZEN , 22-Фев-12 08:34 
>> Самому, что, не судьба понять, для чего нужен список покоцаных файлов с полными путями к ним?
> Неа. А зачем?

К шефу с бамажкой с этим списком на ковёр: "вот тут у нас этими файлами случилась опа, а бэкапов нету".



"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено pavlinux , 22-Фев-12 23:50 
> ... случилась опа, а бэкапов нету".

Опа, уволен! :)


"Патч, увеличивающий производительность Btrfs на 5-10%"
Отправлено Клыкастый , 25-Фев-12 02:00 
...опытный :)