LINUX.ORG.RU
Форум — Desktop  

Свершилось: поломалась btrfs на ноуте

 ,


4

7

Дано: ноут Thinkpad с Core i5 и SSD на 256 Гб. Arch, ядро последнее ванильное арчевское, что-то типа 6.2.3 Около полугода (как выдали ноут на работе) установлен Arch на btrfs, dm-crypt, два раздела btrfs (/ и /home) с subvolumes, сжатием, снапшотами (snapper).

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

Удалил все снэпшоты снэппер, безрезультатно.

Попытался загрузиться в rescue режим, запустил btrfsck на /home и /

На /home отработал без ошибок, на / - миллиард незаканчивающихся ошибок…

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

Но осадочек остался, хотя Arch и btrfs пользуюсь уже лет 15. Правда, раньше не пользовался снэпшотами (за исключением того, что их использует докер).

Не знаю зачем пишу, знаю, что в меня полетят помидоры за Arch и btrfs. Просто предупреждение, наверное.

 ← 1 2 3 4 5 →

Короче, я решил проверить утверждение про то, что переполнение файловой системы убивает BTRFS. И ЭТО НЕПРАВДА!!!

~
❯ cd /tmp                                    

/tmp
❯ fallocate -l 10G btr_container

/tmp
❯ mkfs.btrfs btr_container    
btrfs-progs v6.3
See https://btrfs.readthedocs.io for more information.

NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)

Label:              (null)
UUID:               d6fd4ff4-c2fb-4db9-a741-759abc271f54
Node size:          16384
Sector size:        4096
Filesystem size:    10.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP             256.00MiB
  System:           DUP               8.00MiB
SSD detected:       no
Zoned device:       no
Incompat features:  extref, skinny-metadata, no-holes, free-space-tree
Runtime features:   free-space-tree
Checksum:           crc32c
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1    10.00GiB  btr_container


/tmp
❯ losetup -f --show btr_container 
losetup: cannot find an unused loop device

/tmp
❯ sudo losetup -f --show btr_container
/dev/loop0

/tmp
❯ sudo mkdir /mnt/test_btr               

/tmp
❯ sudo mount /dev/loop0 /mnt/test_btr

/tmp
❯ sudo btrfs su sh /mnt/test_btr
/
        Name:                   <FS_TREE>
        UUID:                   8eacb7da-3d15-4494-82ef-9aad7ad95971
        Parent UUID:            -
        Received UUID:          -
        Creation time:          2023-06-07 12:10:05 +0300
        Subvolume ID:           5
        Generation:             5
        Gen at creation:        0
        Parent ID:              0
        Top level ID:           0
        Flags:                  -
        Send transid:           0
        Send time:              2023-06-07 12:10:05 +0300
        Receive transid:        0
        Receive time:           -
        Snapshot(s):

/tmp
❯ cd /mnt/test_btr

/mnt/test_btr
❯ sudo mkdir -m 0777 test

/mnt/test_btr
❯ cd test                    

/mnt/test_btr/test
❯ touch 1

/mnt/test_btr/test
❯ for ((i=0;i<10*1024;i++)); do dd if=/dev/urandom of=$i.dat bs=1M count=1; done

...
dd: error writing '10239.dat': No space left on device
1+0 records in
0+0 records out
0 bytes copied, 0.00266202 s, 0.0 kB/s

/mnt/test_btr/test 34s
❯ btrfs fi us .
WARNING: cannot read detailed chunk info, per-device usage will not be shown, run as root
Overall:
    Device size:                  10.00GiB
    Device allocated:             10.00GiB
    Device unallocated:            1.00MiB
    Device missing:                  0.00B
    Device slack:                 16.00EiB
    Used:                          9.51GiB
    Free (estimated):                0.00B      (min: 0.00B)
    Free (statfs, df):               0.00B
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:               10.45MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,single: Size:9.48GiB, Used:9.48GiB (100.00%)

Metadata,DUP: Size:256.00MiB, Used:14.94MiB (5.83%)

System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)

/mnt/test_btr/test
❯ cd .. 

/mnt/test_btr
❯ sudo rm -rf test

/mnt/test_btr
❯ sudo touch foo                   

/mnt/test_btr
❯ sudo dd if=/dev/sda of=dump bs=1M count=1024              
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.18514 s, 337 MB/s

/mnt/test_btr
❯ ls -ahl
total 1.1G
drwxr-xr-x 1 root sergey   14 Jun  7 12:26 .
drwxr-xr-x 1 root root    124 Jun  7 12:11 ..
-rw-r--r-- 1 root root   1.0G Jun  7 12:26 dump
-rw-r--r-- 1 root root      0 Jun  7 12:25 foo

Я добился перевыполнения файловой системы, я удалил файлы, создал новый и все работает. ЧТЯНТ?

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

Все это туфта. Шишкин многолетний дебил, который рассуждал о btrfs исходя из знаний примерно 2015 года, автор сломал файловую чеком, переполнение убить ЕЕ ТОЧНО НЕ МОЖЕТ. Так что всей хейтеры могут умерить мел и выйти из чата. Самое забавное, что я сам поверил в эти все рассуждения и даже повелся на авторитет великого разраба никому ненужной фс

uwuwuu
()
Последнее исправление: uwuwuu (всего исправлений: 1)
Ответ на: комментарий от uwuwuu 
/mnt/test_btr
❯ sudo btrfs fi us .                          
Overall:
    Device size:                  10.00GiB
    Device allocated:              1.53GiB
    Device unallocated:            8.47GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                          1.00GiB
    Free (estimated):              8.48GiB      (min: 4.25GiB)
    Free (statfs, df):             8.48GiB
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:                3.50MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,single: Size:1.01GiB, Used:1.00GiB (98.84%)
   /dev/loop0      1.01GiB

Metadata,DUP: Size:256.00MiB, Used:1.23MiB (0.48%)
   /dev/loop0    512.00MiB

System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
   /dev/loop0     16.00MiB

Unallocated:
   /dev/loop0      8.47GiB

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

uwuwuu
()
Последнее исправление: uwuwuu (всего исправлений: 2)
Ответ на: комментарий от greenman

Бред все. Он скорее всего сначала проверку запустил либо недостаточно свободного места для восстановления было (я так понимаю что нужно все «дерево» перезаписать), и утилита начала файловую систему восстанавливать, а новые блоки ей писать некуда, вот и файловую систему «убило». А убило в кавычках, потому что его файлы целы хоть он и пытался все уничтожить, не осознавая этого

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

Я подозреваю, что для восстановления файловой системы нужно столько же свободного места сколько DUP Size показывает:

Metadata,DUP: Size:5.00GiB, Used:3.23GiB (64.57%)
   /dev/nvme1n1p1         10.00GiB

Иначе все сломаешь

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

Так лучше?

# compsize /mnt/root_btrfs/
Processed 209 files, 11559 regular extents (11559 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       99%      276G         276G         276G
none       100%      276G         276G         276G
zstd        35%       18M          52M          52M

# btrfs fi us -T /mnt/root_btrfs/
Overall:
    Device size:                 278.09GiB
    Device allocated:            278.09GiB
    Device unallocated:            2.02MiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        276.67GiB
    Free (estimated):             64.00KiB      (min: 64.00KiB)
    Free (statfs, df):            64.00KiB
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              305.66MiB      (used: 0.00B)
    Multiple profiles:                  no

             Data      Metadata  System
Id Path      single    DUP       DUP      Unallocated Total     Slack
-- --------- --------- --------- -------- ----------- --------- -----
 1 /dev/sda3 248.07GiB   2.00GiB 16.00MiB     1.02MiB 250.09GiB     -
 2 /dev/sda1  28.00GiB         -        -     1.00MiB  28.00GiB     -
-- --------- --------- --------- -------- ----------- --------- -----
   Total     276.07GiB   1.00GiB  8.00MiB     2.02MiB 278.09GiB 0.00B
   Used      276.07GiB 308.62MiB 48.00KiB

# dd if=/dev/urandom of=/mnt/root_btrfs/@data/test/test4.dat bs=1 count=1
dd: error writing '/mnt/root_btrfs/@data/test/test4.dat': No space left on device
1+0 records in
0+0 records out
0 bytes copied, 0,597058 s, 0,0 kB/s

Файл создался при этом. Удаляю весь тестовый каталог

# ls /mnt/root_btrfs/@data/test/test4.dat
/mnt/root_btrfs/@data/test/test4.dat
# du -sh /mnt/root_btrfs/@data/test/
18G     /mnt/root_btrfs/@data/test/
# rm -rf /mnt/root_btrfs/@data/test/
# btrfs fi us -T /mnt/root_btrfs/@data/
Overall:
    Device size:                 278.09GiB
    Device allocated:            278.09GiB
    Device unallocated:            2.02MiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        259.46GiB
    Free (estimated):             17.17GiB      (min: 17.17GiB)
    Free (statfs, df):            17.17GiB
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              305.66MiB      (used: 0.00B)
    Multiple profiles:                  no

             Data      Metadata  System
Id Path      single    DUP       DUP      Unallocated Total     Slack
-- --------- --------- --------- -------- ----------- --------- -----
 1 /dev/sda3 248.07GiB   2.00GiB 16.00MiB     1.02MiB 250.09GiB     -
 2 /dev/sda1  28.00GiB         -        -     1.00MiB  28.00GiB     -
-- --------- --------- --------- -------- ----------- --------- -----
   Total     276.07GiB   1.00GiB  8.00MiB     2.02MiB 278.09GiB 0.00B
   Used      258.90GiB 286.84MiB 48.00KiB
NyXzOr ★★★
()
Ответ на: комментарий от NyXzOr

И писали на неё не почти не сжимаемый urandom, а вполне себе сжимаемые файлы.

Вижу сжатыми 52M

Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       99%      276G         276G         276G
none       100%      276G         276G         276G
zstd        35%       18M          52M          52M

Распакуй туда исходники ядра, firefox-a, libreoffice…

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

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

Это просто эпидемия какая то. Этот noatime застрял у людей в мозгах и каждый второй его в fstab пихает. Ну прочитайте вы man mount уже наконец! СОВРЕМЕННЫЙ man mount, не времён мамонтов и динозавров. Аналог noatime, relatime, который во всём как noatime, только «какой то почтовый клиент зачемто» не ломает, используется ПО УМОЛЧАНИЮ начиная с ядер версии 2.6.30. Не нужно больше ничего писать, уже давным давно.

relatime
           Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than the current modify or change time.
           (Similar to noatime, but it doesn’t break mutt(1) or other applications that need to know if a file has been read since the last time it was modified.)

           Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime was specified), and the strictatime option is required to obtain traditional
           semantics. In addition, since Linux 2.6.30, the file’s last access time is always updated if it is more than 1 day old.
Jameson ★★★★★
()
Ответ на: комментарий от NyXzOr

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

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

Все равно проблема не воспроизводится. Сейчас создал свеженькую BTRFS, включил сжатие через compress-force, полностью забил файловую систему исходниками ядра Linux, так что даже mkdir выдавал ошибку о нехватке места, но все равно получилось все файлы удалить и после этого снова можно было писать их. И так несколько раз сделал.

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

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

и, кстати, твои там рассуждения про то что там что-то нужно тестировать… я сейчас протестировал что же произойдет, если неожиданно сдохнет устройство, будет извлечено и тп. - ничего. все так же работать будет, а ошибки можно увидеть только через sudo btrfs device stats <mount>

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

Дык, если бы все проблемы так просто воспроизводились. Для начала, у меня ещё использовались сабвольюмы и снэпшоты, причём несколько раз вложенные: /var - это сабвольюм, который снэпшотился через snapper, плюс на нём хранятся например образы докера, которые докер тоже реализует через сабвольюмы и/или снэпшоты.

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

И я вот че не понимаю. А что должно было произойти? Я думал мож это вопрос с подвохом, ведь для меня очиведно, что raid - серверная технология, а сервер должен обработать каждый запрос во чтобы то ни стало, записать данные на диск даже если один из них неожиданно сдохнет. И тут RAID-1 точно такой же как везде. И я не понимаю как меня можно обвинять в том, что я не провел тест сродни какому примеру из реальной жизни, типа вот если мы бросили в огонь шкаф и тот сгорел, а давайте бросим в огонь младенца, а вдруг он не сгорит…

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

и, кстати, твои там рассуждения про то что там что-то нужно тестировать… я сейчас протестировал что же произойдет, если неожиданно сдохнет устройство, будет извлечено и тп. - ничего. все так же работать будет, а ошибки можно увидеть только через sudo btrfs device stats

А теперь вставьте НОВЫЙ чистый диск и восстановите raid, если получится, то поздравляю - вы прошли один из этапов стандартной ежемесячной тренировки техников ДЦ.

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

Логика тут другая, «b-trees» в btrfs (я не спроста взял их в кавычки) не соответствуют законам чистой и незамутнённой теории алгоритмов и структур данных. Либо вы делаете правильно, либо у вас получается btrfs. Всё очень просто и предельно понятно.

Ты не можешь апеллировать к авторитету науки используя теологический подход ссылки на мнение авторитетов. Научное возражение может ссылаться на конкретную ошибку, например на использование метода за границами его применимости, но никак не на то что «вы ничего не понимаете в научной науке». Так что Шишкин и ты просто чешете языками. И если ещё можно представить как акадэмик отмахивается от назойливого кулибина таким образом, то левша, желающий довести до царя то что «англичане ружья кирпичом не чистят» просто не может себе позволить такое высокомерие, по его собственным словам он потратил время на анализ кода, нашел ошибку, написал эксплоит, проверил, убедился в реальности проблемы, и только когда пришло время опубликовать и собрать лавры его вдруг одолела лень. Так не бывает. Да и вообще, я вот хочу верить в лучшее в людях, поэтому я бы скорее поверил, что Шишкину обидно что он оказался мейнтейнером ненужнофс и он со зла распространяет о конкурентах сплетни чем в то что он реально мудак, который знает о серьёзной уязвимости в продукте, используемом миллионами людей, но вместо того чтоб исправить или хотя бы указать на проблему из-за мелких обидок позволяет злу торжествовать.

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

Например для виртуальных машин zfs

… не слишком пригодна в случае интенсивной случайной ПЕРЕзаписи. Ибо дает большую write amplification и множественные read даже во время примитивной рандомной записи.

Да, я делал тесты. ZFS прекрасная ФС для случаев «пишем один раз и потом много раз читаем». Если это не ваш случай - CoW-based FS вам не нужна.

no-dashi-v2 ★★
()
Ответ на: комментарий от Jameson

разве не должен в ядре вестись некий «черный» их список, запрещающий для них те или иные «фичи» ФС?

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

no-dashi-v2 ★★
()
Ответ на: комментарий от Vsevolod-linuxoid

Не устраивает то, что ZFS работает в юзерспейсе и что у неё отдельный, а не системный дисковый кеш

Есть несколько реализаций, и ZFS-on-Linux (майнстрим) работает в ядре. Там даже при каждом апдейте приходится модули специально пересобирать. У меня для этих игрищ заведена виртуалка с 9-й центосью и ZFS.

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

Какой-нибудь кингмакс, кингспек или адата? :-)

Ноут - корпоративный бизнес-ноут Lenovo, не помню, что в нём, ещё не брался за переустановку, но точно не китайское г-но.

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

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

С таким подходом можете начать отрицать вообще всю науку. Станете плоскоземельщиком, борцом с Анунаками и почётным ловцом НЛО сачком. Шишкин - специалист высшего класса, отрицать его мнение = отрицать фундаментальную науку.

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

С таким подходом можете начать отрицать вообще всю науку

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

Шишкин - специалист высшего класса

Я уже в котором треде пытаюсь узнать, наконец, практические результаты работы этого специалиста. За что-то же ему Хуавей зарплату платит. Что-то триумфального развития хранилок на рейзере не видно.

отрицать его мнение = отрицать фундаментальную науку

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

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

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

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

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

Обязанность доказывать истинность суждения лежит на утверждающем.

Не можете прочитать такой код и понять алгоритмы и структуры

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

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

А если могу

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

считаю Шишкина необоснованно пафосным мудаком

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

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

обсудим

Обсудим что? Эксплойтов-то нет. Есть заява некоего г-на. Всё.

То что вы считаете вообще никого не интересует

Так ты уж определись, интересует или нет, научный ты наш.

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

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

Эксплойтов-то нет.

Ну да, а ФС падает от внезапного окончания свободного места просто так )

Так ты уж определись, интересует или нет, научный ты наш.

Копипаста предметных частей кода с вашими комментариями конечно интересует. Всё остальное не интересует совсем.

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

Шишкин - специалист высшего класса, отрицать его мнение = отрицать фундаментальную науку.

Верить Шишкину тоже не научно. Из статьи «Научный метод» в вики: Важной стороной научного метода, его неотъемлемой частью для любой науки, является требование объективности, исключающее субъективное толкование результатов. Не должны приниматься на веру какие-либо утверждения, даже если они исходят от авторитетных учёных.

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

Верить Шишкину тоже не научно.

У тех кто не верит Шишкину есть возможность взять код btrfs и всячески его проанализировать на предмет применяемых алгоритмов и структур. Но нет же, у не верящих Шишкину лишь один аргумент - «я и Вася пользуемся btrfs и нам нравится, значит ФС хорошая». Зашибись аргументация )

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

А у тех кто верит, есть возможность помочь Шишкину собрать доказательную базу, экспериментальные данные. Есть у Шишкина научная статья о проблемах btrfs? Или только интервью? Я так понимаю, он математик и должен уметь писать научные труды.

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

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

https://superuser.com/questions/654119/btrfs-huge-metadata-allocated

нужно было баланс запускать

И вот он эту проблему описал в 2020 или 2021 я уж забыл какого года статью позавчера читал. ПРОБЛЕМА В ТОМ, ЧТО ЕГО ЗНАНИЯ ПРОТУХЛИ, те не готовился к интервью, посчитал лишним перепроверить факты. Тут я так же обосрался когда написал мол zfs требует специальное ядро, раньше нужно было его компилить с недефолтными флагами, сейчас - нет. Но я никто и звать меня никак, я аноним, а вот у прохфессора репутация есть и ему нежелательно чушь нести

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

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

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

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

Я использую btrfs не помню с какого года, но очень давно, наверное где-то с 2011-2012. На самых разных устройствах. Развалилась она у меня только сейчас, спустя более, чем 10 лет.

Гооврить, что она разваливается на ровном месте - безосновательное утверждение.

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

Я использую btrfs не помню с какого года, но очень давно, наверное где-то с 2011-2012. На самых разных устройствах.

На серверах с хайлоад i/o использовали? Если только на ПК и ноутах, то это ничего не значит.

P.S. Я мог бы понять попытки использовать кривое решения, если бы не было альтернатив. Но есть прекрасные классические ФС - XFS, ext4 и лучшая cow fs - ZFS, созданные настоящими инженерами. а не дилетантами с тройкой по математике в дипломе.

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

Ну так привел бы хоть какие-нибудь факты в доказательство своего голословия. А то ведешь себя как клоуны из года в год, копипастящие выковыряную из носа простыню про недостатки Манжаро, не меняющуюся с 2015го.

То как тебе «btrfs не интересен» всем и так понятно - второй день тут торчишь, приследуешь прохожих.

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

Ну так привел бы хоть какие-нибудь факты в доказательство

Когда вы школе учились, то, судя по вашей «логике», вы требовали у преподавателя немедленно доказать, что 3 закона Ньютона не противоречат вашему убеждению о плоской Земле? Вот тут тоже самое. Не можете сами - слушайте специалистов, не нравятся мнения специалистов - поднимайте свой технический уровень и делайте выводы на основе фундаментальных знаний, а не «ощущений».

приследуешь прохожих

прИследуешь. Извините, не сразу понял с кем имею дело.

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

требовали у преподавателя немедленно доказать

Конечно же нет. Он (точнее, она) сам, на первом же уроке, досптупным языком объясняет эти формулы и входящие в них переменные. Да так, что они будут понятны пятикакласнику. Без двухдневных росказней о космических струнах, сингулярности черных дыр и природе темной энергии.

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

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

досптупным языком объясняет эти формулы и входящие в них переменные

Вам и Шишкин доступным языком объясняет, что в btrfs реализацию b-tree делали дебилы и, что характерно, он абсолютно прав. Если хотите возразить, то рекомендую сначала посмотреть исходники.

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

P.S. Я мог бы понять попытки использовать кривое решения, если бы не было альтернатив. Но есть прекрасные классические ФС - XFS, ext4 и лучшая cow fs - ZFS, созданные настоящими инженерами. а не дилетантами с тройкой по математике в дипломе.

Это не в XFS ли недавно была сделана какая-то ошибка?..

ext4 — надёжная, да, но примитивная, по сравнению со всеми другими альтернативами. Может быть, оно и неплохо, но я на ноуте, например, хочу использовать сжатие, а она его не поддерживает. Она вообще ничего не поддерживает, сверх простого хранения файлов.

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

Это прямо жыр какой-то. Ты лично проверял дипломы у авторов ZFS и у авторов btrfs? Человек с дипломом не может сделать фигню? Ты лично в курсе, что при создании ZFS использовались строгие доказательства и алгоритмы?

Ей-богу, помешательство какое-то.

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

Когда вы школе учились, то, судя по вашей «логике», вы требовали у преподавателя немедленно доказать, что 3 закона Ньютона не противоречат вашему убеждению о плоской Земле?

Т.е. термин «аксиоматика» в школе не учили, я так понимаю? Про Лагранжеву механику я в принципе промолчу.

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

Это не в XFS ли недавно была сделана какая-то ошибка?..

Нет. Это базовая ФС у Red Hat.

ext4 — надёжная, да, но примитивная, по сравнению со всеми другими альтернативами.

В чём она более примитивна, чем другие классически не-cow ФС? Я ответ знаю, интересно послушать Ваше мнение.

Ты лично проверял дипломы у авторов ZFS и у авторов btrfs?

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

Herabora
()
 ← 1 2 3 4 5 →
Desktop