LINUX.ORG.RU

Проскакивала новсть, что btrfs уже стабильна. Я в этом не уверен.

 


0

2

Ядро 3.17.1 x86_64. Монтируем btrfs с опцией compress-force=lzo и пишем в 2-3 потока всего лишь на скорости гигабитной сетки. Через 10-30 минут (как повезёт), система наглухо виснет вот с таким выхлопом:


Call Trace:
Nov 3 03:21:49 DRIVE kernel: [ 859.630880] [<ffffffff817a3e05>] _raw_write_lock+0x25/0x30
Nov 3 03:21:49 DRIVE kernel: [ 859.630888] [<ffffffffc01be3a9>] btrfs_tree_lock+0xc9/0x1d0 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630891] [<ffffffff810b3eb0>] ? add_wait_queue+0x60/0x60
Nov 3 03:21:49 DRIVE kernel: [ 859.630896] [<ffffffffc015b92b>] btrfs_lock_root_node+0x3b/0x50 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630901] [<ffffffffc0160dd7>] btrfs_search_slot+0x787/0x880 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630907] [<ffffffffc0178048>] btrfs_lookup_file_extent+0x38/0x40 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630914] [<ffffffffc01983f1>] __btrfs_drop_extents+0x151/0xdf0 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630915] [<ffffffff8109da1c>] ? ttwu_do_wakeup+0x2c/0x100
Nov 3 03:21:49 DRIVE kernel: [ 859.630917] [<ffffffff811cd773>] ? kmem_cache_alloc+0x1b3/0x1f0
Nov 3 03:21:49 DRIVE kernel: [ 859.630922] [<ffffffffc015b3ba>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630926] [<ffffffffc015b3ba>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630932] [<ffffffffc018867b>] insert_reserved_file_extent.constprop.64+0xab/0x310 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630938] [<ffffffffc0185880>] ? start_transaction.part.35+0x80/0x530 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630944] [<ffffffffc018ee35>] btrfs_finish_ordered_io+0x475/0x580 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630951] [<ffffffffc01cd6d1>] ? end_compressed_bio_write+0x31/0xf0 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630957] [<ffffffffc018ef55>] finish_ordered_fn+0x15/0x20 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630964] [<ffffffffc01b49ae>] normal_work_helper+0x7e/0x1b0 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630971] [<ffffffffc01b4c52>] btrfs_endio_write_helper+0x12/0x20 [btrfs]
Nov 3 03:21:49 DRIVE kernel: [ 859.630972] [<ffffffff8108ce2e>] process_one_work+0x14e/0x460
Nov 3 03:21:49 DRIVE kernel: [ 859.630973] [<ffffffff8108d7ab>] worker_thread+0x11b/0x3f0
Nov 3 03:21:49 DRIVE kernel: [ 859.630975] [<ffffffff8108d690>] ? create_worker+0x1e0/0x1e0
Nov 3 03:21:49 DRIVE kernel: [ 859.630976] [<ffffffff810932b9>] kthread+0xc9/0xe0
Nov 3 03:21:49 DRIVE kernel: [ 859.630977] [<ffffffff810931f0>] ? flush_kthread_worker+0x90/0x90
Nov 3 03:21:49 DRIVE kernel: [ 859.630978] [<ffffffff817a46fc>] ret_from_fork+0x7c/0xb0
Nov 3 03:21:49 DRIVE kernel: [ 859.630979] [<ffffffff810931f0>] ? flush_kthread_worker+0x90/0x90
Nov 3 03:21:49 DRIVE kernel: [ 859.630980] Code: 90 8b 0a 84 c9 66 90 75 f6 89 ce 89 c8 83 ce 01 f0 0f b1 32 39 c8 75 e7 b9 ff 00 00 00 eb 0a 0f 1f 84 00 00 00 00 00 f3 90 8b 02 <83> f8 01 75 f7 f0 0f b1 0a 83
f8 01 75 ee eb b3 0f 1f 40 00 8b


Это просто сама стабильность.

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

А как в ZFS?

ZFS отлично жмёт резреженные файлы, даже если в начале файла нечто несжимаемое.

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

Какая то особая, уличная магия.

Реально интересно. Какая степень сжатия на zfs и перенеси этот файл на пустую btrfs с compress-force и покажи df?

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

ZFS так тормозит без огромного кэша.

Вот опять ты вбрасываешь. Не тормозит она, либо понятие «огромный» у нас сильно различается.

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

Реально интересно. Какая степень сжатия

степень сжатия от алгоритма сжатия зависит, а не от FS.

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

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

я не тебя спрашивал. или ты и.о.К.О.?

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

Реально интересно. Какая степень сжатия на zfs и перенеси этот файл на пустую btrfs с compress-force и покажи df?

С 3-го раза получилось, да и то с небольшим файлом. Исходный файл 10Гб.
ZFS:


zstorage/vm/minecraft 3,1T 5,3G 3,1T 1% /zstorage/vm/minecraft


BTRFS (compress-force=lzo):

/dev/sdc 1,4T 4,2G 1,4T 1% /mnt/btrfs

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

я правильно понял, на zfs файл сжался до 5.3гб, а на btrfs до 4.2гб

и где здесь преимущества zfs? я вижу обратное

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

я правильно понял, на zfs файл сжался до 5.3гб, а на btrfs до 4.2гб

Правильно.

и где здесь преимущества zfs?

На zfs сжатие работает всегда, а на btrfs только при определенных условиях. compress-force, который изображает работу схожую с zfs, неработоспособен вовсе.

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

Юлишь, весь тред ты говорил иное.

Как тебе верить в других тредах, если ты врешь.

Считай что на zfs всегда включен compress-force, зато в btrfs больше гибкости, хочешь всегда, хочешь автоматически, ...

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от sdio

Юлишь, весь тред ты говорил иное. Как тебе верить в других тредах, если ты врешь.

Что за припадок паранои? Я весь тред говорил, что разреженный файл на btrfs c compress=lzo не жмётся вовсе, а на zfs жмется. Так оно и есть. Где я вру?

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

Ты так говоришь, будто это что-то хорошее.

Для хранения образов ВМ это очень-очень хорошо. На zfs, кстати, включить и выключить сжатие я могу на любой ФС, а на subvolume btrfs нет.

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

Ты хотел чтобы было как в zfs, для этого в btrfs нужно compress-force, тут только тебя можно мокнуть в незнание мат.части. Кроме того ты утверждал что в zfs еще и жмется лучше. Соврал.

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

Для хранения образов ВМ это очень-очень хорошо

А для кинопомойки или музыкальной коллекции это только бессмысленная трата проца и памяти на попытки сжать несжимаемое.

На zfs, кстати, включить и выключить сжатие я могу на любой ФС, а на subvolume btrfs нет

Я в курсе. Будет запилено в будущих версиях.

pedobear
()
Ответ на: комментарий от sdio

для этого в btrfs нужно compress-force, тут только тебя можно мокнуть в незнание мат.части

Ты начало треда читал? Я включил compress-force, чтобы сжимало, но это не работает, потому что btrfs бажная и валит систему.

ты утверждал что в zfs еще и жмется лучше. Соврал.

Не соврал, на zfs жмётся, на btrfs нет. compress-force не работает )

King_Carlo ★★★★★
() автор топика
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от pedobear

А для кинопомойки или музыкальной коллекции это только бессмысленная трата проца и памяти на попытки сжать несжимаемое.

zfs set compress=off zpool/fs и заметьте, без всякого перемонтрования, на лету.

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

А перед этим нужно разложить файлопомойку по томам в зависимости от типов файлов. Удобно шо капец, лол.

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

разложить файлопомойку по томам в зависимости от типов файлов

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

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

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

pedobear
()
Ответ на: комментарий от King_Carlo

Ну вообще довольно странно, что я не могу вдруг этого захотеть.

Тот же logrotate как правило жмет логи после ротирования, и в итоге хорошо жмущиеся обычные логи находятся рядом с уже пожатыми, а fs пытается сжимать и те и другие.

ещё есть, например git, который в .git/objects хранит сжатые файлы, а в working tree - очень даже несжатые

maloi ★★★★★
()
Последнее исправление: maloi (всего исправлений: 1)
Ответ на: комментарий от pedobear

Зачастую так и получается.

Можно и так конечно, бардак это лично дело каждого. Я включаю компрессию на весь пул и очень редко выключаю сжатие на отдельной ФС, крайне редко. Сжатие не жрёт современый процессор, как ограничить потребление памяти всем известно. Не вижу проблем.

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

У меня работает, а проблемы одминов шерифа не волнуют.

Позиция понятна, на твоём локалхосте можно использовать любую бажную ФС, всё равно ценность данных стремится к нулю. Для меня данные важны, поэтому я выбираю адекватное, надёжное решение.

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

Сжатие не жрёт современый процессор

Опять враньё. Святой дух работает, вместо процессора.

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

Мне вруны не интересны.

Где я соврал?

Опять враньё. Святой дух работает, вместо процессора.

3-5% от одного ядра. Жалко? И ты это, полегче, тебя заклинило на лжи, которой нет, это пранойя называтся.

King_Carlo ★★★★★
() автор топика
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от pedobear

А для кинопомойки или музыкальной коллекции это только бессмысленная трата проца и памяти на попытки сжать несжимаемое.

ну вот, видишь? Теперь ты понимаешь, почему в EXT4 сжатие непрозрачное, а только вручную, и только разжатие прозрачное, да и то в mainline никто его не спешит костылить?

emulek
()
Ответ на: комментарий от King_Carlo

3-5% от одного ядра

При каком потоке данных? Ты тоже поумерь свой пыл, все у тебя на zfs так шоколадно... и сжатие без просадки рессурсов, а банальный gzip сделаешь и все упирается в CPU даже на скоростях простого hdd

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

Как хорошо, что я не одмин, лол.

То есть ты считаешь, что когда на твоём, моём и вооон того парня локалхостах btrfs кладёт систему это нормально и должно настораживать только админов? ))

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

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

pedobear
()
Ответ на: комментарий от sdio

При каком потоке данных?

Ну скажем при 100Мб/сек, на сраном Xeon E3-1270V3.

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

Почему упоминание zfs так тебя раздражает?

King_Carlo ★★★★★
() автор топика
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от King_Carlo

Для меня данные важны, поэтому я выбираю адекватное, надёжное решение

если ты ЯКОБЫ стремишься выбирать надёжные решения — то скажи, когда ты разберёшься в чём истинная причина kernel-panic на компьютере с btrfs (который на твоей стороне)...

...то ты сообщишь нам о причине, или стыдливо промолчишь? :)

[подсказываю сразу: низкая вероятность что причина в именно btrfs.. вероятнее причина в том что ты что-то затюнинговал]

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

низкая вероятность что причина в именно btrfs.. вероятнее причина в том что ты что-то затюнинговал

Никакого тюнинга, всё сток.

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

Никакого тюнинга, всё сток.

а как ты тогда скопипастил kernel-panic из экрана?

прям вот мышкой выделил и скопировал? :-)

а не виртуалка ли у тебя там какая? :-)

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

Пруф давай.

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

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

а как ты тогда скопипастил kernel-panic из экрана?

Резетом перезагрузил комп и, не поверишь, залез в /var/log/syslog ))

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

В Ext4 нет никакого сжатия. Точка.

ой, да и хрен с тобой. Если ты не можешь осилить коротенький текст по ссылке, то разве это моя проблема? Жри свой любимый кактус дальше, я не против.

emulek
()
Ответ на: комментарий от King_Carlo

Резетом перезагрузил комп и, не поверишь, залез в /var/log/syslog ))

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

вроде не должна была разделиться.

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

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

В Ext4 нет никакого сжатия. Точка

Есть есть, не надо тут. Товарищ верно говорит, что собственно возможность сжатия в самой ФС предусмотрена (ещё со времён ext2). То, что она не реализована в ванильном ядре - это отдельный вопрос (просто никому не нужно).

no-such-file ★★★★★
()
Ответ на: комментарий от user_id_68054

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

Потому что терминал был открыт не на весь экран.

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

> почему тогда у тебя разделалась одна длинная строчка на две разные строчки (в середине лога)?

Потому что терминал был открыт не на весь экран.

что же ты меня постоянно пытаешься обмануть! :-) :-D

[Screencast from 03-11-14 15:54:34.webm]

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

Пруфы покажи

Пруфы чего, что в ext2/3/4 предусмотрено сжатие на лету? Ок, смотрим /usr/src/linux/fs/ext4/ext4.h

...

/*
 * Inode flags
 */

...

#define EXT4_COMPR_FL                   0x00000004 /* Compress file */

...

/* Reserved for compression usage... */
#define EXT4_DIRTY_FL                   0x00000100
#define EXT4_COMPRBLK_FL                0x00000200 /* One or more compressed clusters */
#define EXT4_NOCOMPR_FL                 0x00000400 /* Don't compress */
#define EXT4_ECOMPR_FL                  0x00000800 /* Compression error */
/* End compression flags --- maybe not all used */

...
no-such-file ★★★★★
()
Ответ на: комментарий от King_Carlo

Где я облажался?

Предложи лучше.

Как в ZFS.

King_Carlo ★ (03.11.2014 13:24:15)

А как в ZFS?

ZFS отлично жмёт резреженные файлы, даже если в начале файла нечто несжимаемое.

я правильно понял, на zfs файл сжался до 5.3гб, а на btrfs до 4.2гб

Правильно.

и где здесь преимущества zfs?

На zfs сжатие работает всегда, а на btrfs только при определенных условиях. compress-force, который изображает работу схожую с zfs, неработоспособен вовсе.

Враньё, жмет лучше чем zfs, жмет все при опции compress-force как в zfs, ... Если ты делаешь стойку на слово force, то оно в zfs по-умолчанию тоже force.

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

жмет все при опции compress-force как в zfs, ... Если ты делаешь стойку на слово force, то оно в zfs по-умолчанию тоже force.

Вот ты странный человек, я уже всё разжевал, написал несколько раз, для тебя повторю в последний раз. Чтобы сделать для тебя тест с compres-force мне пришлось взять самый мелкий файл, потому что на файлах большего размера btrfs роняла ядро. Поэтому я делаю очевидный вывод, что если compress-force не работает в btrfs, то zfs жмёт лучше, потому что там это работает, причём по-умолчанию. Это настолько простая логика, что, я уверен, она тебе вполне понятна, но ты упорно строишь из себя святую невинность. Тебе просто нравится придираться ко мне?

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

Дефайны в хидере - это не «предусмотрено».

Т.е. их там просто так натыкли, с бодуна? Ну да, иноды же резиновые фигли не запихать туда ещё 4 флага?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Т.е. их там просто так натыкли, с бодуна?

Могли просто на перспективу. Ты покажи пруфы, что сжатие в Ext4 работает.

pedobear
()
Ответ на: комментарий от King_Carlo

Тебе просто нравится придираться ко мне?

Ты меня раскусил и btrfs не готов.

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

Ты покажи пруфы, что сжатие в Ext4 работает

Нет, ты всё таки клинический случай. Есть ФС ext4, а есть её реализации в linux. В дефолтной реализации сжатие не поддерживается (но блджад, структуры под него зарезервированы). Есть патч, запиливающий поддержку сжатия. Если тебе так хочется пощупать - ну пойди и накати патч, скомпиляй ядро и проверяй. Мне лениво - 15 лет назад эта штука работала, а сейчас мне сжатие нафиг не нужно.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Есть ФС ext4, а есть её реализации в linux

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

15 лет назад эта штука работала

Да, вот только Ext4 появилась только в 2006-ом. Вещай ещё.

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

Да, вот только Ext4 появилась только в 2006-ом. Вещай ещё.

Да, вот только ext4 обратно совместим с ext2/3. Да и патч подпиливали под новые ядра.

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

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Где-то летал патч, реализующий и снапшоты в Ext4, только это не значит, что сама по себе Ext4 умеет снапшоты.

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от pedobear

Где-то летал патч, реализующий и снапшоты в Ext4, только это не значит, что сама по себе Ext4 умеет снапшоты

В отличие от снапшотов сжатие впилили в формат ещё ext2.

сама по себе Ext4

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

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

а нифига вообще пилят это самое прозрачное сжатие?

Экономия места и увеличение скорости i/o. lzo не просто быстр, он реактивен, и рамы кушает всего ничего (десятки килобайт на рапаковку, емнип).

pedobear
()
Ответ на: комментарий от no-such-file

В бтр снапшоты тоже не с луны свалились.

В btrfs снапшоты реализованы изначально, ибо CoW by design.

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

рамы кушает всего ничего (десятки килобайт на рапаковку, емнип)

Дык на _каждую_ распаковку. А сколько распаковок идёт параллельно?

И ещё вопрос (я просто не в теме), а что в бтр файлы пакуются целиком или экстентами/блоками? Какой размер экстента?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Возможно, это ответ на твой вопрос:

 Can a file data be compressed with different methods?

Yes. The compression algorithm is stored per-extent. 
pedobear
()
Ответ на: комментарий от pedobear

А как в ZFS?

В ZFS сжатие поблочное. Сжался первый блок или нет не оказывает никакого влияния на сжатие последующих. Если блок сжимается плохо, например если блок в 4 КБ (8 секторов) не удалось сжать до 3,5 КБ (7 секторов) или менее - он хранится без компрессии.

Блоки из нулей, кстати, при включенном сжатии превращаются во вполне себе полноценные дырки, превращая файл в sparse.

anonymous
()
Ответ на: комментарий от pedobear

Это слишком ресурсоёмко, нафиг надо.

Голословное заявление.

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

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

Или алгоритм сжатия поменяй на менее ресурсоемкий. А то некоторые включат gzip-9 и ожидают, что все будет так же быстро и жрать столько же CPU, как и с lzjb.

anonymous
()
Ответ на: комментарий от axelroot

vxzvxz, ты жалок в своей бессильной злобе — покажи хоть одно мое сообщение, где я ругал (безосновательно) zfs. Вы же фанатики любую критику возводите в ранг бохульства и призываете к сожжению еретика.

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

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

erzent ☆☆
()
Ответ на: комментарий от erzent

У него 2 экаунта, кроме оригинального, но это юзер может и без тебя заявить ошибаюсь я или нет.

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

По делу нечего сказать, как ярлыки вешать: "фанатику инквизиции zfs" ты здесь, а как пруф выдать, так слышно только:"сам дурак, иди лечись"

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Мне лениво - 15 лет назад эта штука работала, а сейчас мне сжатие нафиг не нужно.

оно в 2013ом работало. Хотя я и согласен, что оно не нужно.

emulek
()
Ответ на: комментарий от pedobear

а нифига вообще пилят это самое прозрачное сжатие?

Экономия места

нахрена?

увеличение скорости i/o

это если жмётся. А откуда у тебя такие файлы? У меня нету.

emulek
()
Ответ на: комментарий от sdio

vxzvxz, ты жалок в своей бессильной злобе

точно, мания преследования

anonymous
()
Ответ на: комментарий от sdio

покажи хоть одно мое сообщение, где я ругал (безосновательно)

Ну давай, расскажи поподробнее о своих основаниях вот тут

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

Ты в том сообщении увидел наезд на ZFS? Ты должен уточнить у своего психиатра что в действительности «мания преследования» и у кого она.

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

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

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

Была заява «zfs никогда не ломается, даже при откл. питания», я взял ближайший вопрос из гугла «Отключилось питание, zfs поломался» и !внимание! спросил местных специалистов «Что там произошло?», заметьте не глумился, не радовался просто попросил технический анализ.

И вместо анализа ситуации вы переходите на личности. Так что где вы увидели с моей стороны наезд на zfs и почему я должен приводить аргументы (анализ той ситуации по линку) мне не понятно.

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

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

я взял ближайший вопрос из гугла «Отключилось питание, zfs поломался»

С тем же успехом можно спросить гугл «Чупакабра терроризирует украину» и обсудить это с местными специалистами. Не увидев опровержения заявить, что так оно и есть.

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

Не увидев опровержения заявить, что так оно и есть.

А это было?

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

Была заява «zfs никогда не ломается, даже при откл. питания», я взял ближайший вопрос из гугла «Отключилось питание, zfs поломался» и !внимание! спросил местных специалистов «Что там произошло?»

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

И вместо анализа ситуации вы переходите на личности. Так что где вы увидели с моей стороны наезд на zfs и почему я должен приводить аргументы (анализ той ситуации по линку) мне не понятно.

На указание такой простой штуки, как «после того не означает вследствие того» ты стал нести непоймичто. Никто тебя и не просит приводить анализ той ситуации (ибо ты у нас, как известно, свидетель LVM ;) ), но признать, что «после того не означает вследствие того» и, следовательно, приведенный тобой пример не вполне корректен - было бы разумно и профессионально.

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