The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В OpenZFS выявлена ошибка, которая может привести к повреждению файлов

23.11.2023 11:17

Доступен промежуточный выпуск проекта OpenZFS 2.2.1, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Выпуск примечателен добавлением поддержки ядра Linux 6.6 и попыткой устранения проблемы, приводящей к повреждению данных (обнулению части блоков) в файлах после их копирования.

Изначально предполагалось, что проблема проявляется только в ветке 2.2.x и вызвана ошибкой во включённом в OpenZFS 2.2.0 механизме клонирования блоков, позволяющем создать копию файла или его части без дублирования данных, используя во второй копии ссылки на уже существующие блоки данных исходного файла без их фактического копирования. В версии OpenZFS 2.2.1 для блокирования проблемы механизм клонирования блоков был отключён по умолчанию, а для возвращения поддержки данного режима добавлена настройка zfs_bclone_enabled.

Позднее разработчики заявили о воспроизведении проблемы и в конфигурациях с веткой OpenZFS 2.1.x. Не подтвердились и предположения, что проблема проявляется на системах со старыми выпусками пакета coreutils - ошибку удалось воспроизвести во FreeBSD и в Linux-дистрибутивах со свежим выпуском coreutils 9.4. Для тестирования своих систем опубликован скрипт reproducer.sh.

Повреждение файлов проявляется при достаточно редком стечении обстоятельств, например, выполнение в Gentoo команды "emerge -1 dev-lang/go" приводит к установке инструментария для языка Go с повреждением файлов в каталоге /usr/lib/go/pkg/tool/linux_amd64/compile. Предполагается, что ошибка начала проявляться после выставления по умолчанию параметра "zfs_dmu_offset_next_sync=1" в версии openzfs 2.1.4. Источник ошибки пока не выявлен. В качестве рекомендованного обходного пути блокирования ошибки предложено выставить в 0 параметр "/sys/module/zfs/parameters/zfs_dmu_offset_next_sync".

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

  1. Главная ссылка к новости (https://github.com/openzfs/zfs...)
  2. OpenNews: Релиз OpenZFS 2.2, реализации ZFS для Linux и FreeBSD
  3. OpenNews: В инсталляторе Ubuntu 23.10 будет возвращена поддержка ZFS
  4. OpenNews: Ошибка в патчах FreeNAS, вызывающая скрытое повреждение данных в ZFS
  5. OpenNews: Уязвимость в OpenZFS, нарушающая обработку прав доступа во FreeBSD
  6. OpenNews: Выявлена несовместимость SMR-дисков WD с ZFS, которая может привести к потере данных
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60167-zfs
Ключевые слова: zfs, openzfs
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (386) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:30, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +20 +/
    Надежная ФС! Прям как оригинальная ZFS, только пишется не всякими мутными ораклами, а сообществом!
     
     
  • 2.7, Аноним (7), 11:42, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А вы чего хотели? Всё, что человечество изобретало последние 50 лет, впихнули в единую файловую систему, а теперь удивляются "Ой, ошибка, не может быть!"
     
     
  • 3.149, Аноним (-), 18:11, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А вы чего хотели? Всё, что человечество изобретало последние 50 лет,
    > впихнули в единую файловую систему, а теперь удивляются "Ой, ошибка, не может быть!"

    В энергосистему из которой вы электричество "качаете" - впихнули все что человечество лет 150 изобретало, но это худо-бедно работает же.

    p.s. но на фоне вот этого - и траблов рядом где у народа шифрование отваливается и что там еще, отдельные приветы bcachefs. Бывает так что experimental фича в rc1 - качественнее иного release у некоторых. В этом месте манагеры ряда фирм просто обязаны разбить лицо фэйспалмами.

     
     
  • 4.313, Аноним (313), 14:19, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    в энергетике хорошо работает естественный отбор: если делать плохо, то кого-то либо убьет, либо пожжет имущество. а в ИТ можно "и так сойдет!"
     
     
  • 5.319, Аноним (319), 23:29, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Припоминая как дефолтсити вырубился в 2005 - иногда, таки, естественный отбор выглядит гораздо забавнее. И как видите, случается же иногда, несмотря на все старания.

    Так что в этом смысле они обычные люди. С обычными технологиями, а иногда - и факапами. IT в этом смысле ничем не лучше и не хуже. А глюкавый ECU вас может угробить и побстрее чем высокое напряжение.

     
  • 4.364, User (??), 10:00, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Гм. Да. Записываем - про энергосистемы вы знаете примерно "ничего" - но аналогия на самом деле неплохая )))
     
  • 2.9, Аноним (9), 11:46, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +19 +/
    Как всегда больше всех ноют те, у кого ZFS вообще нет)
     
     
  • 3.21, Аноним (21), 12:06, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Точно, надо попользоваться, похерить файлы, а уж потом ныть.
     
     
  • 4.58, Всем Анонимам Аноним (?), 13:53, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    О чем как раз и сообщение, на которое вы ответили. Пишут только те, у кого её никогда не было, уж тем более без опыта массового использования для файлов и баз данных. Чисто диванная аналитика. Так держать, opennet.
     
     
  • 5.102, None (??), 15:23, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    У меня был опыт использования ZFS для файлов и баз данных. Раз в несколько дней восстанавливать трехтерабайтную постгресную базу - сомнительное удовольствие. Смена ФС решила проблему, больше никогда на ZFS не вернусь и даже смотреть в ее сторону не буду.
     
     
  • 6.109, OpenEcho (?), 15:48, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Смена ФС решила проблему

    Настоящее "инженерное" решение... А что ж тогда оно у других работает и со значительно большей постгрей чем 3 тб?

     
     
  • 7.158, pin (??), 18:52, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >  Раз в несколько дней восстанавливать трехтерабайтную

    ой-ли?

     
     
  • 8.214, OpenEcho (?), 01:42, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я боюсь, вы промахнулись кнопкой - ответить , т к я такой херней не страдаю... текст свёрнут, показать
     
  • 6.244, YetAnotherOnanym (ok), 11:00, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > и даже смотреть в ее сторону не буду

    Та же фигня, бро, только с глустером.

     
     
  • 7.347, пох. (?), 17:12, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> и даже смотреть в ее сторону не буду
    > Та же фигня, бро, только с глустером.

    не, ну он хотя бы - прикольный.


     
  • 7.365, User (??), 10:02, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Эм. Postgres поверх glusterfs?! Оно и поверх ZFS-то выглядит... интересно, но гластер кмк некторым образом "за гранью".
     
  • 4.117, tim2k (ok), 16:07, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    $uname -a
    [skipped] 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012

    Более 10 лет работы, сейчас аптайм 400+ дней. Машинка изолирована, хранилка для виртуальных машин бодрая.

     
     
  • 5.150, Аноним (-), 18:12, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > [skipped] 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012

    Так оно у тебя в рефлинки и не умело никогда. Нет фичи - нет проблем!

     
     
  • 6.153, Аноним (153), 18:32, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так о том и речь. Если фича не нужна, не беги обновляться.
     
     
  • 7.157, Аноним (-), 18:51, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Так о том и речь. Если фича не нужна, не беги обновляться.

    Правильно, зачем кому-то надо 100% легкий, эффективный моментальный "дедуп" без дикого жора проца и рамы. Еще не хватало время и деньги экономить.

     
     
  • 8.174, Аноним (174), 21:21, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я так понимаю у тебя проц вчерашнего выпуска, память, материнка навороченная Че... текст свёрнут, показать
     
     
  • 9.178, Аноним (-), 22:00, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Потом довольно часто почему-то оказывается что такие технологии и сотрудники фир... текст свёрнут, показать
     
  • 8.180, Аноним (180), 22:48, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Только вот эта пафосная демагогия никак не влияет на наличие zfs snapshot zfs cl... текст свёрнут, показать
     
     
  • 9.202, Аноним (202), 00:57, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну то-есть вы хотите сказать, что кодеры делавшие фичу - позеры и страдальцы фиг... текст свёрнут, показать
     
     
  • 10.207, Аноним (180), 01:11, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну то-есть мы опять наблюдаем фирменное 294-ое сруливание с темы ... текст свёрнут, показать
     
     
  • 11.215, Аноним (-), 01:48, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если хотелось мое мнение по теме, посмотрев на баг трек с какими-то несчастными ... большой текст свёрнут, показать
     
  • 4.135, анон (?), 17:14, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >похерить файлы

    вот не надо меня пугать, мне после отвалов btrfs еще на zfs такого не хватало.

     
     
  • 5.243, EULA (?), 10:57, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто в BTRFS отвалы тоже из ZFS позаимствованы
     
  • 3.32, Аноним (32), 12:34, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Именно поэтому у меня её нет и никогда не будет.
     
     
  • 4.87, BorichL (ok), 14:27, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да ты и дальше на FAT сиди.
     
     
  • 5.129, Аноним (129), 17:02, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Где-то fat норм использовать, только тебе в твоём коворкинге про это не расскажут. А так ext4, xfs кошер.
     
     
  • 6.155, Аноним (-), 18:38, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Где-то fat норм использовать, только тебе в твоём коворкинге про это не расскажут.
    > А так ext4, xfs кошер.

    Учитывая что первый вообще на integrity данных с прибором клал? У него чексум нет! Про то чтобы еще и репайрить в фоне побитое с другой копии - речь в этом чуде вообще не идет. А, да, так можно было.

    А второй - только-только пытаются научить фоновый scrub на манер btrfs/zfs. Правда, судя по недавним мсг в рассылке - это пока больше похоже на "пытался своершить посадку самолет номер 13...", видимо, майнтайер который резко сдриснул оттуда о перспективах догадывался, и решил что тонуть с кораблем - все же не его. Вон то оно само по себе тоже не умеет.

     
     
  • 7.385, User (??), 11:22, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, если у тебя data integrity парой уровней выше или наоборот, ниже - то почему бы и не "да"?
     
     
  • 8.394, Аноним (-), 21:37, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    1 Это такое довольно большое если 2 Которое к тому же имеет свойство стоит... текст свёрнут, показать
     
     
  • 9.395, User (??), 21:49, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Сюрприииз Как-то так оно в реальном мире и работает Enterprise у дешевле запла... большой текст свёрнут, показать
     
  • 6.170, BorichL (ok), 19:50, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Где-то fat норм использовать, только тебе в твоём коворкинге про это не
    > расскажут. А так ext4, xfs кошер.

    А чего ты HPFS386 и JFS забыл, или тогда ещё под стол пешком ходил?

     
  • 3.59, ИмяХ (ok), 13:54, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это не нытьё, а злорадство "как хорошо, что на моей любимой ext4 ничего подобного нету"
     
     
  • 4.71, Аноним (9), 14:15, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Больше выглядит как "я не разобрался, поэтому у меня ничего нету". Половина виндузятники, вторая половина вообще с телефонов. О проблемах с хранилищами не слышали даже из далека
     
     
  • 5.136, Аноним (136), 17:14, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Половина виндузятники, вторая половина вообще с телефонов. О проблемах с хранилищами не слышали даже из далека

    Сам-то понял, каким дном свою ZFS выставил, защитничек?

     
  • 4.125, Аноним (125), 16:42, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да, как же они на ехт4 то без чексумм узнают что у них там что-то повредилось
     
  • 4.156, Аноним (-), 18:40, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не нытьё, а злорадство "как хорошо, что на моей любимой ext4 ничего подобного нету"

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

     
  • 2.11, Пряник (?), 11:47, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    git blame?
     
  • 2.16, Аноним (16), 11:54, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Надежная ФС! Прям как оригинальная ZFS, только пишется не всякими мутными ораклами, а сообществом!

    факела бсдлюбов особенно хороши :) ext4 используй

     
     
  • 3.18, Аноним (9), 11:57, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Но вы же оба виндузятники, там нет ext4
     
     
  • 4.34, пох. (?), 12:35, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    там зато есть единственная существующая утилита для восстановления файлов рухнувшего zpool.
    Правда, она не работает с dRAID и с 2.2 наверное тоже, но у л@п4@тых и такой ведь нет.

    P.S. драйвер ext4, что характерно - есть, более того - некоторые граждане успешно использовали его для вытаскивания данных с ext4, которая, ВНЕЗАПНО, в линуксе не умеет читать саму себя если записана не на той архитектуре. А в вендепоганой - умеет.

     
     
  • 5.57, Аноним (153), 13:52, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > которая, ВНЕЗАПНО, в линуксе не умеет читать саму себя

    Нужны грязные подробности, если это не про поддержку атрибутов в разных версиях ext4.

     
     
  • 6.66, пох. (?), 14:11, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> которая, ВНЕЗАПНО, в линуксе не умеет читать саму себя
    > Нужны грязные подробности, если это не про поддержку атрибутов в разных версиях
    > ext4.

    если не умеешь в гугль - воспользуйся хотя бы поиском по сайту.

     
     
  • 7.262, Аноним (262), 13:14, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это оно?

    https://lkml.org/lkml/2018/12/27/155 "d_off field in struct dirent and 32-on-64 emulation"

    Даже если не оно, то тоже интересно. И на XFS не проявляется.

     
     
  • 8.337, пох. (?), 16:49, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не оно, но я не удивлюсь если тут и виндовый драйвер не поможет Спасибо, в копи... текст свёрнут, показать
     
  • 5.61, Аноним (-), 14:02, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > единственная существующая утилита для восстановления файлов рухнувшего zpool

    это какая? Там - это где?

     
     
  • 6.65, пох. (?), 14:10, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    где-где - ввенде!

    гуглем пользоваться уж как-нибудь сам учись.

     
  • 5.159, Аноним (-), 18:54, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > там зато есть единственная существующая утилита для восстановления файлов рухнувшего zpool.
    > Правда, она не работает с dRAID и с 2.2 наверное тоже, но у л@п4@тых и такой ведь нет.

    Да ващет в этом нашем btrfs - такая штука встроена прям в штатный тулкит ФС. И работает ессно в линухе. По этой причине тулсов для этсамого для виндов vs btrfs не очень то и есть, комерсам всю малину разработчики ФС испортили.

     
     
  • 6.179, Аноним (179), 22:07, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И об этом ты ещё до войны разговаривал с господином окружным начальником.
     
  • 6.261, Аноним (262), 13:10, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это какие? Которые ZFS сначала закрыли, чтобы барыжить, а потом поняли, что поздняк метаться и стали вдохновляться (переписывать исходники) ZFS в BtrFS. Вот это поворот! Оракле некомерсом назвали.
     
     
  • 7.283, Аноним (-), 18:30, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чего кого В btrfs офлайн парсер, позволяющий к тому же потыкаться в разные точк... большой текст свёрнут, показать
     
     
  • 8.368, Аноним (368), 10:36, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    zfs была открыта задолго до того как оракле понял, что она крута Так что Кри... большой текст свёрнут, показать
     
     
  • 9.372, Аноним (319), 20:25, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Оракл вообще купил в основном из-за соляры и явы как я понимаю, ну и чтобы энтер... большой текст свёрнут, показать
     
     
  • 10.386, User (??), 11:50, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну кагбыда, но в реальной жизни почему-то нагруженный MsSQL под NTFS запустить м... текст свёрнут, показать
     
     
  • 11.390, Аноним (390), 19:26, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Мне вот интересно - чего такого нагруженного на вот именно MS SQL вообше запус... большой текст свёрнут, показать
     
     
  • 12.392, User (??), 21:01, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И вот эти вот конпелятели ядра и заменятели катриджей что-то там про enterprise ... большой текст свёрнут, показать
     
     
  • 13.396, Аноним (-), 22:00, 28/11/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 13.397, Аноним (390), 22:06, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я готов поспорить что корпы где я это все щупал были в фортуне-500 сильно выше в... большой текст свёрнут, показать
     
     
  • 14.402, User (??), 07:51, 29/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Опыт замены катриджей офигенно релевантен вопросу, да Уровень своих не знаний ... большой текст свёрнут, показать
     
  • 10.400, Аноним (-), 02:41, 29/11/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.30, Аноним (30), 12:31, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Работает на серверах уже кучу лет, так что в надёжности можно не сомневаться.
    А нытье сколько угодно можно услышать практически про любую ФС начиная от fat и (ненужной и довольно ненадёжной, чтобы там не говорили виндузятники) ntfs, до ext (более чем надёжная, но и для неё есть культ плоскоземельщиков) и xfs ("оракл жи", а вот тут я и сам могу поныть, правда при весьма специфических условиях, но ведь вам не мешает ныть про ещё более специфические условия с zfs).
     
     
  • 3.33, Аноним (32), 12:35, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Просвяти на каких именно серверах и чем обусловлен выбор.
     
     
  • 4.50, BeLord (ok), 13:38, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Спроси у операторов большой тройки, что они сейчас используют-)))
     
     
  • 5.67, пох. (?), 14:12, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Спроси у операторов большой тройки, что они сейчас используют-)))

    Венду, венду и ... а, вот - венду!

     
  • 2.90, Аноним (90), 14:29, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    хоть новость бы дочитал

    "Повреждение файлов проявляется при достаточно редком стечении обстоятельств..."

     
     
  • 3.94, Tron is Whistling (?), 14:38, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. Проблема в том, что узнать, стекло или не стекло - невозможно. Пока не поймаешь.
     
  • 3.108, Kuromi (ok), 15:47, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вспомните про закон больших чисел. Есть ZFS будет на каждом ПК, то внезапно редкие обстоятельства станут не такими уж и редкими.
     
     
  • 4.145, Аноним (7), 17:48, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так наличие ZFS на компьютере - и есть то редкое обстоятельство.
     
  • 2.107, OpenEcho (?), 15:44, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я понимаю, что по утру бзднуть хочется, но оглядываться все же не мешает

    https://openzfs.org/wiki/Companies

     

     ....большая нить свёрнута, показать (72)

  • 1.3, Аноним (3), 11:35, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Ни на что не намекаю, но в Btrfs такой проблемы нет.
     
     
  • 2.6, Аноним (7), 11:40, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +7 +/
    А какая есть?
     
     
  • 3.8, Аноним (3), 11:42, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Ну например слишком стабильно работает, даже как-то скучно становится. Приходится искать, чем себя занять.
     
     
  • 4.10, Аноним (9), 11:47, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Пишешь из будущего?
     
     
  • 5.28, пох. (?), 12:31, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Из будущего альтернативной реальности - форкнулась где-то в 2010м. Там у них btrfs не только работает стабильно, но ее еще и не выкинули в пользу только что изобретенной новой поделки.

     
     
  • 6.195, Аноним (-), 00:41, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем выкидывать то Btrfs как раз до ума более-менее довели А это только нач... большой текст свёрнут, показать
     
  • 4.35, glad_valakas (?), 12:36, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >  слишком стабильно работает

    а если нагрузить по методике Шишкина - что будет ?
    или: от чего там ntfs умирала - все помнят ?

     
     
  • 5.42, Аноним (3), 13:05, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    по той самой методике, которую он никому не раскрыл?
     
     
  • 6.131, glad_valakas (?), 17:07, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    если подумать и поработать руками, то можно воспроизвести.
    задавшись вопросом "как быстро деградировать B-дерево, попутно нагадив в метаданные".
     
     
  • 7.137, Аноним (3), 17:19, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну подеградируй, подеградируй мое дерево. Деградируй мое дерево полностью. Ты сможешь? Сможешь подеградировать мое дерево?
     
  • 7.269, Аноним (269), 13:58, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Меньше слушайте всяких экспертов

    Date Fri, 18 Jun 2010 15:32:16 +0200
    From Edward Shishkin <>
    Subject Btrfs: broken file system design (was Unbound(?) internal fragmentation in Btrfs

    https://lkml.org/lkml/2010/6/18/144

    Проверяйте

    https://www.opennet.ru/openforum/vsluhforumID3/124332.html#419

     
     
  • 8.376, нах. (?), 23:53, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    нашел время прочитать наконец-то ахренеть, они несходящийся алгоритм ухитрили... текст свёрнут, показать
     
     
  • 9.381, Аноним (269), 06:36, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Как Васян, наслышавшийся анекдотов про у меня на виртуалке всё работает , я не... текст свёрнут, показать
     
     
  • 10.382, Аноним (-), 08:23, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вы то с похом офигенные эксперты Толи на ZFS осыпающемся, толи вообще на NTF... текст свёрнут, показать
     
     
  • 11.401, Аноним (269), 05:24, 29/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну ты то знаешь, зачем в ядре нужен префикс lock ... текст свёрнут, показать
     
  • 5.201, Аноним (202), 00:56, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >>  слишком стабильно работает
    > а если нагрузить по методике Шишкина - что будет ?

    Создать файлуху на 600 мегов и забить ее мелкотой? Можно, но вот что доказывает жалоба на то что межгалактический крейсер сложно на автопарковку втиснуть? Зачем его вообще туда? Пусть на орбите себе и висит, втираться на парковку - не его род занятий. Каким-то особым минусом этого дизайна сие не является. Ладно там еще Кенту который хочет заменять squashfs и явно козыряет компактностью структур это пенять, он сам напросился явной декларацией.

    > или: от чего там ntfs умирала - все помнят ?

    Создать том более 2 терабайт и посмотреть как оно себя протрет в ноль? На современных сторажах это уже давно протестировано, такие объемы уже не экзотика.

     
  • 4.177, lucentcode (ok), 21:59, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уже много лет на btrfs, тьфу-тьфу, ни разу пока проблем не вылезло. Но, это не значит, что в каком-то будущем релизе что-то подобное не добавят.
     
     
  • 5.216, Аноним (216), 02:08, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Уже много лет на btrfs, тьфу-тьфу, ни разу пока проблем не вылезло.
    > Но, это не значит, что в каком-то будущем релизе что-то подобное
    > не добавят.

    Ну так...
    1) btrfs интегрирован с майнлайном на тему разработки.
    2) авторы оного еще и умеют в запуск тестов
    3) кроме этого -rc ядра тестит довольно много народа в разных ипостасях.
    4) откровенно экспериментальные фичи предпочитают честно называть таковыми.
    5) разработчики фс явно наслаждаются тем что делают и горой за результат, насколько это к вон тем применимо - ахз.

     
  • 3.334, iZEN (ok), 12:16, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А какая есть?

    Недообследованная.

     
  • 2.14, Пряник (?), 11:49, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Текст в интернете всегда прав.
     
  • 2.113, OpenEcho (?), 15:58, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да ну?
    А что ж тогда на редите приколоченные гвоздями проблемы весят
     
     
  • 3.122, Аноним (3), 16:23, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это ошибка выжившего. Когда бтрфс работает, никто не приколачивает гвоздями посты типа "прикиньте, у меня уже неделю ничего не происходит, все хорошо". Поэтому ты про это остаешься не в курсе.
     
     
  • 4.211, OpenEcho (?), 01:35, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > это ошибка выжившего. Когда бтрфс работает, никто не приколачивает гвоздями посты типа
    > "прикиньте, у меня уже неделю ничего не происходит, все хорошо". Поэтому
    > ты про это остаешься не в курсе.

    Так, я не про них, я про те что уже ОЧЕНЬ долго гвоздями прибиты


     
  • 4.245, YetAnotherOnanym (ok), 11:07, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Гораздо чаще встречается ошибка вдовы - "у меня сдохло, значит, у всех сдохнет".
     
     
  • 5.348, пох. (?), 17:14, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Гораздо чаще встречается ошибка вдовы - "у меня сдохло, значит, у всех
    > сдохнет".

    товарищмайор, тут вдовроссии дискредитируют!


     

  • 1.4, beck (??), 11:37, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Продолжаем использовать ext4. Держите в курсе.
     
     
  • 2.22, Аноним (22), 12:10, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ntfs*
     
     
  • 3.307, Аноним (307), 10:33, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    fat16*
     

  • 1.13, Аноним (13), 11:49, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Шишкин прав был. Дерм..ще все эти ваши zfs, btrfs и т.п.
     
     
  • 2.24, Ахмат (?), 12:19, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    FAT16 сила!
     
     
  • 3.26, Аноним (26), 12:23, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Шишкин сила! Рейзер5 придет - порядок наведет!
     
     
  • 4.120, tim2k (ok), 16:12, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ему же пожизненное дали?
     
     
  • 5.175, Анонис (?), 21:40, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Файловой системе?
     
  • 5.217, Аноним (216), 02:09, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Ему же пожизненное дали?

    Шишкину то? Он конечно мерзкий зануда, но не настолько же?!

     
  • 3.29, Аноним (29), 12:31, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    win95.cih с тобой не согласен ;)
     
  • 3.154, Анонимпс (?), 18:38, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Единственная файловая система которую Я осилил сам запрограммировать за свою жизнь :D
    Остальные просто не пробовал:)
     
  • 2.68, penetrator (?), 14:12, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    btrfs - лучшая фс
     
     
  • 3.96, Аноним (96), 14:49, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Худшая из всех что тестировал.
     
     
  • 4.161, Аноним (-), 19:13, 23/11/2023 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 4.227, penetrator (?), 08:06, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Худшая из всех что тестировал.

    ога, тестировал он, во сне

     
  • 2.160, Аноним (-), 19:12, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Шишкин прав был. Дерм..ще все эти ваши zfs, btrfs и т.п.

    Ну он то как самый умный - не релизнул ФС вообще, reiser3 слил - нет файлух, нет проблем с ними. Все правильно сделал.

     

  • 1.19, еропка (?), 11:58, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ооооо, мне тут недавно один "специалист со стажем" расхваливал ZFS. Говорил, что конфетка а не фс. И что я глyпец, что на ext4 сижу
     
     
  • 2.25, Аноним (25), 12:21, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    OpenZFS был основан и портирован говнокодер сообществом Linux. Не путать с Oracle ZFS от динозавров.
     
     
  • 3.115, OpenEcho (?), 16:02, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > OpenZFS был основан и портирован говнокодер сообществом Linux.

    Это эти то https://openzfs.org/wiki/Companies говнокодеры?
    Даже боюсь спросить, кого же вы тогда представляете... с таким авторитетным мнением, чтоб тех "говнокодеров" перебить

     
     
  • 4.152, Аноним (153), 18:29, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Можно подумать там все эти компании что-то программируют. Они просто объединились в свой корпоративный синдикат, чтобы с важным видом обсуждать свои финансовые профиты, а для программирования могли нанять студентов на аутсорсе.

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

     
     
  • 5.164, пох. (?), 19:27, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно подумать там все эти компании что-то программируют.

    несколько штук таки есть. И да, это говнокодеры и саботажники.

    Начиная с дельфикс и "мы не можем исправить уже найденную и локализованную ошибку because luck of resources", продолжая iX не пожелавшими принимать готовый и вылизанный патч возвращающий memory pressure на протяжении трех лет и доломавших его совсем, а потом и вовсе выбросившей в помойку все наработки freebsd, и так далее.

    Остальное - собиратели гуанонасов из навоза и тому подобные мастера фуллшмяк программирования на пехепе.

     
     
  • 6.173, Аноним (-), 21:03, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Такой прозрачный намек - бабок хочется Создали себе кучу головняка на ровно... большой текст свёрнут, показать
     
  • 5.213, OpenEcho (?), 01:40, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Они просто объединились в свой корпоративный синдикат, чтобы с важным видом обсуждать свои финансовые профиты

    Это вам баб Маша в подьезде сказала?

    > а для программирования могли нанять студентов на аутсорсе.

    Кто? Амазон студентов на аутсорсе? Я здесь много телепатов видел, но вы - самый уникальный !

     
     
  • 6.240, Аноним (262), 09:57, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А из того списка только амазон пашет?

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

    И почему бы амазону не нанимать студентов.
    https://devby.io/news/amazon-budet-nanimat-na-pozitsii-inzhenerov-dzhunov-tolk

    К тому же, не обязательно амазон создал проблему.

     
     
  • 7.255, OpenEcho (?), 12:30, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Т.е. для тебя без 5-ти минут инженер и фрилэнцер - одно и тоже?

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

     
     
  • 8.263, нах. (?), 13:30, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    конечно нет - первый вообще ничего не умеет, а второй - ну хз, кто это просто и... текст свёрнут, показать
     
  • 8.264, Аноним (262), 13:35, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я и сам таким был когда-то А в амазоне работают такие же люди, которых сейчас в... текст свёрнут, показать
     
     
  • 9.304, OpenEcho (?), 07:29, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, теперь понятен уровень осведомленности о устройстве амазона Читайте дальш... текст свёрнут, показать
     
     
  • 10.305, Аноним (262), 09:49, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Твой источник новостей про самоотверженное кодирование zfs тыжбез5минутинженер-... текст свёрнут, показать
     
     
  • 11.315, OpenEcho (?), 18:28, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Видел, потому и говорю Легче стало Хороших выходных ... текст свёрнут, показать
     
  • 6.241, Аноним (262), 10:01, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А у амазона нет своей корпоративной почты?

    Что-то в этом списке их нет.
    https://github.com/openzfs/zfs/blob/master/AUTHORS

     
     
  • 7.256, OpenEcho (?), 12:44, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А у амазона нет своей корпоративной почты?

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

     
     
  • 8.266, Аноним (262), 13:40, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    FSx - это амазоновское корпоративное решение поверх openzfs То есть для общей р... текст свёрнут, показать
     
     
  • 9.274, OpenEcho (?), 14:46, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ох уж эти телепаты Для того, чтобы мыши прибегали на сыр, - он должен быть сь... текст свёрнут, показать
     
     
  • 10.278, Аноним (262), 16:53, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ух ты Так сыр, оказывается, несъедобный И поэтому они на его базе своё решение... текст свёрнут, показать
     
     
  • 11.303, OpenEcho (?), 07:24, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Закусывать надо ... текст свёрнут, показать
     
     
  • 12.325, Аноним (319), 01:28, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так он и закусил, видимо, живу плохо вино кислое, сыр плесневелый, машина без ... текст свёрнут, показать
     
  • 3.181, NetGhost (?), 22:49, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не Oracle ZFS а Sun ZFS. Оракул того и гляди закопает эту ФС
     
  • 2.27, rinat85 (ok), 12:30, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    я один из таких :D очень жду bcachefs но пока где можно всюду zfs. Неделю эксплуатирую зеркало на 2ТБ как раз на zfs 2.2, под podman хост в lxc контейнере, bclone никак не задействован, ошибок нет. Не то, чтобы сильно защищаю, это всё плохо, но вообще эта проблема проявляется при нагромождении факторов и в основном с версией 2.2 с её bclone фичей, которая релизнулась всего месяц назад, у кого-то при использовании ZFS 2.1 поверх LVM2 (что в общем-то не запрещается, но некоторое дублирование функционала выходит), в серьезном продакшн версию 2.2 точно рановато использовать, Proxmox собираются одновременно с переходом на linux 6.5 где-то в декабре, но только на бесплатном полутестовом репозитории.
     
     
  • 3.36, Аноним (32), 12:37, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    О каком серьёзном продакшне речь? Как ни спросишь - оказывается либо подкроватный сервак, либо proxmox.
     
     
  • 4.40, turbo2001 (ok), 12:53, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Hetzner в своём storage box использует zfs. Это достаточно серьёзный продакшн или ещё нет?
     
     
  • 5.44, Аноним (129), 13:14, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Понятия не имею. Хочется рабоче-крестьянского чёткого объяснения - мы используем там-то и потому-то. А то как у бсдшников получается - сплошные баззворды, нетфликс, сони, бла бла. А потом выясняется, что серьёзный продакшн - это качалка торрентов.
     
     
  • 6.79, Аноним (9), 14:20, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Рабоче-крестьянский слив защитан
     
  • 6.89, turbo2001 (ok), 14:28, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Из того, что наружу торчит - используются снапшоты и квоты (с учетом снапшотов). Могу предположить, что дедупликация и сжатие тоже нужно для снижения себестоимости услуги. Это приводит к выбору между btrfs и zfs, они выбрали последнее.
     
     
  • 7.132, Аноним (129), 17:07, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да причём тут "они"? Я спрашиваю лично серьёзные-продуктовики в этом треде как используют? Простой вопрос же. Кроме соплей веером и "вот у них то уххх!" у вас ничего нет)
     
     
  • 8.140, 1 (??), 17:35, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Господи Что для Вас означает серьёзные-продуктовики Ну вот мы отнюдь не ... текст свёрнут, показать
     
     
  • 9.260, нах. (?), 13:07, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    в netapp - по многим источникам таки какой-то свой клон zfs Вплоть до появлявши... текст свёрнут, показать
     
     
  • 10.267, 1 (??), 13:43, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да на своём клоне FreeBSD свой клон ZFS ... текст свёрнут, показать
     
     
  • 11.321, Аноним (319), 00:24, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Проприетарщики они такие А как апстрим в результате сдохнет и придется волочь н... текст свёрнут, показать
     
  • 6.116, OpenEcho (?), 16:05, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Хочется рабоче-крестьянского чёткого объяснения - мы используем там-то и потому-то.

    https://openzfs.org/wiki/Companies

    Достаточно ? Или нужно по кестьянски обяснить, что бизнесы просто так баблом не раскидываются

     
     
  • 7.133, Аноним (129), 17:09, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Достаточно

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

    Обьясни, пожалуйста. Я последние 10 лет в бизнесе, вдруг не знаю чего.

     
     
  • 8.212, OpenEcho (?), 01:37, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Бизнес - это про профит Если ты еще этого еще не понял, то я не верю что ты в б... текст свёрнут, показать
     
  • 4.41, rinat85 (ok), 12:58, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > О каком серьёзном продакшне речь? Как ни спросишь - оказывается либо подкроватный
    > сервак, либо proxmox.

    Если рассуждать так, то всё равно даже начиная от небольшой организации в 50 сотрудников отвечать за сохранность сервисов, файловых хранилищ, БД, тоже надо, и даже с этого уровня не будешь разворачивать или обновлять функционал файловой системы до версии, которая вышла всего-лишь месяц назад. Proxmox упомянул, потому что в тестовой среде у меня очередной, да и неплох как простой гипервизор под несложные инсталляции, где не надо ни кластеров больших, ни реального объединения ресурсов, банально чтобы избежать bare metal.

    Если ваш уровень это уровень облачного провайдера, поздравляю с успешной карьерой, но продакшн он когда и небольшой всё равно серьёзный ;)

     
     
  • 5.45, Аноним (129), 13:19, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >небольшой организации в 50 сотрудников

    Больше ничего можно было не писать, спасибо. Как я и говорил - "наш программист поставил нам 1С на сервер".
    >продакшн он когда и небольшой всё равно серьёзный ;)

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

     
     
  • 6.101, rinat85 (ok), 15:23, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    О, великий, снизошёл Даже на таком уровне Возможность собрать надежные зе... большой текст свёрнут, показать
     
     
  • 7.104, Аноним (104), 15:33, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ыстрый инкрементальный и очень частый бэкап: нужен

    Есть ощущение, что под словом "бэкап" вы понимаете что-то не то.

     
     
  • 8.199, rinat85 (ok), 00:46, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, есть ощущение, что вы думаете, будто я путаю бэкапы со снапшотами Уже отве... текст свёрнут, показать
     
  • 7.138, Аноним (129), 17:24, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да я с тобой не спорю, ты в самом начале своего пути, очень многое узнаешь позже. Например, что в твоём любимом серьёзном продакшене никто не бекапится снапшотами ФС. А есть специальные вещи, которые называются система резервного копирования, ленточные библиотеки, агентский бэкап и т.п. То что рассказываешь ты - это требования к ноутбуку в школе на информатике.
     
     
  • 8.196, rinat85 (ok), 00:41, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Простите, сударь, а вы можете внимательно читать Я про снапшоты написал отдельн... текст свёрнут, показать
     
  • 7.146, Аноним (7), 17:52, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Быстрый [...] и очень частый бэкап: нужен

    Всё, что нужно знать о ZFS.

     
     
  • 8.193, Аноним (30), 00:15, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Как говорится пользователи делятся на два вида те кто использует zfs и те кто п... текст свёрнут, показать
     
  • 8.198, rinat85 (ok), 00:44, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Что нужно делать бэкапы Ну да, нужно, а где не нужно ZFS в рамках своего функц... текст свёрнут, показать
     
  • 3.54, all_glory_to_the_hypnotoad (ok), 13:46, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это какой-то новый вид технического постироничного стендапа?
     
  • 3.162, Аноним (-), 19:15, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > я один из таких :D очень жду bcachefs но пока где можно всюду zfs.

    Оно уже в -rc 6.7, так что самое время потестировать на своих нагрузках. И кстати пока на нее компромата - меньше чем на вот это вот нашлось. Такая ерунда.

     

     ....большая нить свёрнута, показать (47)

  • 1.20, Аноним (104), 12:05, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Да ну, не может быть такого.

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

    > ошибку удалось воспроизвести во FreeBSD

    Вон докуда гентушники окоянные дотянулись

     
     
  • 2.39, glad_valakas (?), 12:48, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    вы будете смеяться, но когда я подбирал себе дистрибутив линукса,
    рекомендации для мигрантов с freebsd были такие: "arch linux или gentoo".
    gentoo я посмотрел и не осилил, остался только arch.
     
     
  • 3.52, Аноним (153), 13:40, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    gentoo - как фряха из портов
    arch - как фряха из пакетов

    Не самые плохие рекомендации.

     
  • 3.103, Аноним (104), 15:27, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вот видишь. А промолчал бы про бсд - глядишь, посоветовали бы какой-нибудь минт, и жил бы себе припеваючи
     
  • 3.318, Аноним (318), 22:54, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > подбирал себе дистрибутив

    Смотр зачем. Я п Арч не выбрал. Слишком много и часто возиться надо из-за обновлений...

     

  • 1.31, Аноним (30), 12:34, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Если проблему можно воспроизвести, то почему не найдут регресс через git bissect (это может не так просто, но вопрос времени, а не возможностей), а найдя коммит уже можно его препарировать
     
     
  • 2.37, пох. (?), 12:39, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    потому что ее можно воспроизвести только с определенной долей вероятности.

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

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

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

     
     
  • 3.92, Tron is Whistling (?), 14:35, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не, вот этот вот бисекс приятно работает в их вырожденном случае игр-однодневок и около, когда ошибка у одного землекопа вот в этих вот 50 строчках, которые конкретно вот этим вот юнит-тестом покрываются.

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

     
     
  • 4.200, Аноним (30), 00:48, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Сколько философов то развелось. Сами в жизни больших и сложных систем не видели иначе бы не писали такую ерунду: что пачка, что один коммит - совершенно не важно, раньше вообще флоу были по месячным, а то и годовым релизам, это сейчас фичаветки в основном используют; и тогда и сейчас искали точно также как делает бисект, только вручную; что ошибка в логике, что в интеграции, что в данных, что в одном коммите, что в пачках - если проблема воспроизводится, то бисект найдёт на каком изменении она появилась. Ну а вы дальше философствуйте о бесполезности юнит тестов, которые кстати и проблемы с некорректными данные находить могут через фаззинг тестирование.
     
     
  • 5.270, Аноним (269), 14:20, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    "When in doubt, use brute force."

    Кен Томпсон тоже не видел больших систем.

     
     
  • 6.338, пох. (?), 16:51, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Кен Томпсон тоже не видел больших систем.

    Увы. Боюсь что только системный (есть еще юзерленд) код zfs больше чем все то что он за всю жизнь написал сотоварищи.

    Компьютеры тогда были - большие.
    А вот память - нет.


     
  • 3.194, Аноним (30), 00:30, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > потому что ее можно воспроизвести только с определенной долей вероятности

    Похоже на твои домысли. В новости например про это ни слова.

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

    Так bisect и создан чтобы найти когда твои коммиты выстроились в ряд.

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

    Это тебе твоё чутье ванги подсказало как и с воспроизведением бага?

     
  • 3.277, Аноним (30), 15:48, 24/11/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 4.339, пох. (?), 16:56, 26/11/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.205, Аноним (-), 01:05, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если проблему можно воспроизвести, то почему не найдут регресс через git bissect
    > (это может не так просто, но вопрос времени, а не возможностей),
    > а найдя коммит уже можно его препарировать

    Ну, узнаете вы что это имплементация рефлинков косячная. И?! Даже если вы зафиксите 1 баг - есть уверенность что еще 5 новых таких же нет? А если посмотреть на их гитхаб... вашу ж 20.

    Там 1.1К открытых багов. И эти люди быкуют на btrfs, его пригодность к продакшну и проч. О..ть!

     
     
  • 3.246, нах. (?), 11:20, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    и просто отключаешь эту фичу и живешь счастливо восстановив пул из бэкапа, пото... большой текст свёрнут, показать
     
     
  • 4.280, Аноним (-), 18:06, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Когда возникают вопросы вида восстановив пул из бэкапа я рад что все это - не ... большой текст свёрнут, показать
     
  • 4.324, Аноним (319), 01:22, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > и просто отключаешь эту фичу и живешь счастливо (восстановив пул из бэкапа,
    > потому что оно не отключается на существующем).

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

     
  • 3.276, Аноним (30), 15:47, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее всего узнаю только на каком изменении баг появился. Но этого достаточно чтобы просмотреть изменяемые структуры и дебажить только их.
    Наличие других багов не повод вообще не править баги.
     
     
  • 4.279, Аноним (-), 17:47, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Скорее всего узнаю только на каком изменении баг появился. Но этого достаточно
    > чтобы просмотреть изменяемые структуры и дебажить только их.

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

    > Наличие других багов не повод вообще не править баги.

    Вот это бесспорно.

     
  • 3.340, пох. (?), 16:58, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну, узнаете вы что это имплементация рефлинков косячная. И?! Даже если вы

    Мы уже узнали что нет, не она.

    Она помогла наткнуться на баг, который где-то непонятно где.

    > Там 1.1К открытых багов. И эти люди быкуют на btrfs, его пригодность
    > к продакшну и проч. О..ть!

    действительно. нет бы позакрывать с wontfix первые 1k хотя бы.


     
     
  • 4.355, Аноним (319), 01:00, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да вообще, детектив целый получился По своему интересный, но к счастью, не у ме... большой текст свёрнут, показать
     
  • 2.273, OpenEcho (?), 14:42, 24/11/2023 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
     
  • 3.341, пох. (?), 16:59, 26/11/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 4.349, OpenEcho (?), 17:49, 26/11/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     

     ....ответы скрыты (19)

  • 1.38, Аноним (104), 12:46, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Ы

    На гитхабе https://github.com/openzfs/zfs/pull/15529
    два девелопера спорят, отключать эту фичу по умолчанию или нет:

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

    И чуть дальше

    "Presently, there's a few tests that Klara added months after the feature was integrated, that are all Linux-only as of this writing, and only exercise a limited number of things each, and as remarked above, FreeBSD had this feature disabled in its development releases until a few weeks ago, and it doesn't exercise the feature at all on FBSD stable trees because of the lack of any interface to doso."

     
  • 1.43, wergus (?), 13:13, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Какой-то наш мир очень однобокий.
    Когда новость про BTFS с критическими ошибками - "всё нормально! допилят!"
    А про новость про ZFS - "нууу, всё плохо! сидим на ext(ufs)"
    При этом, во много благодаря Proxmox, -  тысячи установок, все рады ... но, наверное, они не читают Opennet и чего-то не знают....
     
     
  • 2.82, Аноним (82), 14:22, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Психология... Они думали что их любят за пятачок и розовый бочок, а оказалось что ойти -- просто мясо и сало для буржуинов. Вот от злости и ходют сюда плеваться на всё подряд, болезные.
     
  • 2.83, Аноним (9), 14:22, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Деды на FAT16 сидели - и вы ДОЛЖНЫ страдать) За родину, за Сталина и вот это вот всё...
     
  • 2.86, Аноним (86), 14:26, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Ваш - это какой? Что btrfs, что zfs, нарушающие идеологию юникс ФС, имеющие массу недостатков, часто неочевидных. Их нужно уметь готовить - это уже признак проблемности. Нахваливать такие ФС могут только те, кто продают поддержку, работают на обслуге и т.д.
     
     
  • 3.142, аНОНИМ (?), 17:45, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А вы попробуйте реализовать все фичи без нарушения вашей "идеологии". Как минимум с проверкой целостности у вас получится городушка на dm_integrity, которое не сохраняет настройки в своём суперблоке и имеет проблемы с крешами (неоконченная запись данных И чексумм пометит записанные и соседние данные как испорченные), для решения которых, НАДО ЖЕ, там запилено логирование. Поверх этого что там будет, raid5/6? Ну да, с write hole против которого там тоже есть СВОЁ СОБСТВЕННОЕ логирование. Потом наверное будет lvm, уж не знаю насколько там быстры снапшоты и нужно ли там свое собственное логирование. Ну и наконец бесподобный ext4 с ещё одним своим логом. Офигенное ненарушение идеологии вышло, не правда ли?
     
  • 3.165, Аноним (165), 19:31, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > идеологию юникс

    Вам лишь бы какая, но только бы идеология, чтобы самому думать не надо было. Посмотрел в догмат — и дело с концом! Тьху, поколение инфантилов.

     
     
  • 4.309, Аноним (309), 11:29, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    По мне так философию Unix выше практичности обычно ставят люди постарше... когда они были помоложе. Борьба с systemd, с flatpak-snap из-за дублирования зависимостей и т.д.
     
  • 4.316, Аноним (307), 22:21, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Последователи любой религии смотрят на Вас осуждающе )
     
     
  • 5.352, пох. (?), 23:15, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Раввин смотрит на вас с недоумением...

     
  • 3.300, Аноним (-), 23:22, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да вообще охренеть - оказывается, до того как в кресло КВСа плюхнуться и перевез... большой текст свёрнут, показать
     
  • 2.105, None (??), 15:42, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Proxmox - неплохая штука, но как же иногда приходится изворачиваться, чтобы избежать использование ZFS. Так что из этих тысяч установок надо вычитать процент людей, которые уже прошли по граблям.
     
  • 2.106, Аноньимъ (ok), 15:42, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Потому что брбрфс всегда была кривой и багованной, в здравом уме её использовать не будут, но есть надежда что станет лучше.

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

     
     
  • 3.166, Аноним (165), 19:37, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > в зфс всё железобетонно

    Никогда не было. Софт это вообще не про железобетонность, а именно про возможность изменений в любой момент времени под требования текущего момента, и, как следствие, неизбежные ошибки во всём, что сложнее «Hello, world!». Железобетонно — это hardware. Там как напечатали, так и работает. И то заменяемую фирмварь суют, чтобы можно было хотя бы какие-то неизбежные ошибки исправлять. И только диванные с опеннета бухтят, мло раньше-то О-ГО-ГО диды-инженеры с профильным образованием, а сейчас все вокруг хипстеры-смузихлёбы-гуманитарии. Встал бы с дивана и показал как надо, но не покажешь ведь, потому что скиллов нет.

     
     
  • 4.220, Аноньимъ (ok), 02:25, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Встал бы с дивана и показал как надо, но не покажешь ведь

    Ломать то что работает как надо - не надо.

    Вот конкретно на диване сидеть и не ломать - вот так надо.

     
  • 3.208, Аноним (208), 01:13, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вообще-то она уже good enough для монстров размером с FB У тебя есть прод круче... большой текст свёрнут, показать
     
     
  • 4.219, Аноньимъ (ok), 02:22, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > даже базы на 30 терабайтов бывают

    Так и вижу excited soiboy face.
    Вау конечно, это целых три диска данных.

    > иметь наглость умничать
    > И вы после этого смеете

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

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

     
     
  • 5.225, Аноним (-), 03:05, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну говоря за себя - я так то boy весьма условный, дисков у меня и поболее 3 быва... большой текст свёрнут, показать
     
  • 2.281, Аноним (-), 18:10, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Какой-то наш мир очень однобокий.
    > Когда новость про BTFS с критическими ошибками - "всё нормально! допилят!"
    > А про новость про ZFS - "нууу, всё плохо! сидим на ext(ufs)"
    > При этом, во много благодаря Proxmox, -  тысячи установок, все рады
    > ... но, наверное, они не читают Opennet и чего-то не знают....

    Да ты не бойся, восстановление пула из бэкапа сллжно будет не заметить :)


     
  • 2.291, Аноним (-), 21:38, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Разработчики btrfs в курсе что фичи надо до релиза тестить И тестов у них есть ... большой текст свёрнут, показать
     

  • 1.46, Аноним (46), 13:21, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >ошибка, которая может привести к повреждению файлов

    Да несколько лет назад в течение довольно длительного времени в реализации ext4 в ядре Linux была ошибка, приводящая к повреждению фс, включая повреждение файлов, как системных, так и в home. В качестве вокрараунда я ставил полную проверку ФС на каждый перезапуск через добавление файла в корень через systemd unit и перезагружался почаще (каждая перезагрузка занимала долгое время). Если не перезагружаться почаще - можно было возможно вылететь, и после - загрузиться в initrd и полсистемы через пакетный менеджер переустанавливать. Я ещё подозревал аппаратные проблемы с жёстким диском, но диск был хитачи и имел хорошие SMARTы. Хорошо что купить новый диск я не мог, это были бы потраченные на ветер деньги.

     
     
  • 2.55, Аноним (153), 13:49, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже, только там были не нули в файле, а сам файл тупо обрезался до нулевой длины. Если я о том же баге вспомнил. Их тоже было не мало.
     
  • 2.64, Tron is Whistling (?), 14:08, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если не работает write barrier - это и сейчас может происходить.
     
     
  • 3.70, пох. (?), 14:14, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Если не работает write barrier - это и сейчас может происходить.

    write barrier ни от каких повреждений файлов не спасает. Он спасает от автоотката на состояние фс до сотворения мира при крэше.

    А silent data corruption (опять неумельцы пользуются поиском по сайту или идут найух) - он всегда с тобой.

     
     
  • 4.80, Tron is Whistling (?), 14:20, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почитай повыше - о чём речь. Речь об обрезке метаданных. В основном сие случается, когда кусок журнала с новыми метаданными потерян. А если нет write barrier - ты хоть как ужом вертись.

    Ну и да, silent data corruption - это вот то самое, чем ZFS в описанном в новости случае и занимается.

     
     
  • 5.247, нах. (?), 11:23, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > В основном сие случается, когда кусок журнала с новыми метаданными потерян. А если нет write
    > barrier - ты хоть как ужом вертись.

    write barrier всего лишь делает этот кусок ограниченным во времени (ценой потери производительности)

    ничего не меняя по сути.

    > Ну и да, silent data corruption - это вот то самое, чем ZFS в описанном в новости случае и
    > занимается.

    вроде бы нет - там портятся копируемые файлы, а не как у ext4, вообще лежавшие на диске и не трогаемые сто лет.

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

     
     
  • 6.292, Аноним (-), 21:52, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не ограниченная сверху потеря данных - черт, звучит многообещающе Зато какой сл... большой текст свёрнут, показать
     
  • 4.210, Аноним (-), 01:33, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Немного не так Если у тебя это не работает в железе - откат вообще сработать не... большой текст свёрнут, показать
     
     
  • 5.239, Tron is Whistling (?), 09:56, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Немного не так. Если у тебя это не работает в железе -

    Ну и я о том же. Write barrier должен работать от ведра до конечного диска.

     
     
  • 6.301, Аноним (-), 23:40, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну как бы это сказать В идеале, фс, особенно с избыточностью, должна бы пережив... большой текст свёрнут, показать
     
     
  • 7.306, Tron is Whistling (?), 10:07, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А Вы можете переставлять операционку после того как libc6 не прочитался,
    > я совершенно не против, если такой булшит бинго будет у вас.

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

     
     
  • 8.320, Аноним (319), 23:53, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это может свидетельствовать о самых разных вещах, как минимум 1 Удачливый ти... большой текст свёрнут, показать
     
  • 2.209, Аноним (-), 01:29, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    а чтобы не заниматься всей вот этой НЕВМЕНЯЕМОЙ ХРЕНЬЮ вместо эксплуатации си... большой текст свёрнут, показать
     
     
  • 3.238, Tron is Whistling (?), 09:54, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Та же проблема: как только у тебя факапнется метадата в силу программной ошибки - больше ты оттуда вообще ничего не выгребешь. На экстах хотя бы просто сканированием можно кое-что вытащить, файлы мешаниной по диску не размазаны.
     
     
  • 4.289, Аноним (289), 20:09, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    1 Вообще, сэр, я Data Recovery на полупро уровне с уклоном в линух занимаюсь ма... большой текст свёрнут, показать
     
     
  • 5.293, Tron is Whistling (?), 21:59, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    С перфокарт рекаверишь?
     

     ....большая нить свёрнута, показать (15)

  • 1.47, лютый арчешкольник... (?), 13:26, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ZFS и без этого бага мусорок... Кто её хвалит, снэпшотами то пробовали пользоваться хотя бы годик? Скорость падает ниже плинтусни...
     
     
  • 2.218, Аноним (-), 02:14, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > ZFS и без этого бага мусорок... Кто её хвалит, снэпшотами то пробовали
    > пользоваться хотя бы годик? Скорость падает ниже плинтусни...

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

    Другое дело что в ZFS на этот случай вообще совсем никакого плана нет. Дефрага нема.

     
     
  • 3.248, нах. (?), 11:26, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ты перепутал со своим любимым lvm. У CoW никакой дельты нет. Новые записи ВСЕГДА "дельта".
    Разница только в том что если старые зафиксированы в снапшоте - они не будут со временем перезаписаны чем-то другим.

    У меня снапшоты никак не влияют на скорость фс. Местный дypaчок скорее всего в очередной раз забил фс выше 90% но виноваты конечно снапшоты.

     
     
  • 4.296, Аноним (-), 22:26, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я как раз терпеть его не могу, считая отвратительным легаси CoW файлухи это эст... большой текст свёрнут, показать
     

  • 1.48, Аноним (153), 13:36, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Кто накосячил? Опять Клара или чудные линукс-смузихлёбы?

    Пока линуксоиды не начали программировать свой ZOL, всё было относительно неплохо. Давно ждал такой диверсии.

    Что вы не орёте теперь, что ZFS для FreeBSD разрабатывают линуксоиды.

     
     
  • 2.72, Аноним (-), 14:15, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А чё орать-то? Сидим на 12-й ветке FreeBSD, в которой православная ZFS, а не САБОТАЖ, и смотрим на обмазующихся свеженьким линуксом с некоторым недоумением, хотя пора бы уже и привыкнуть.
     
     
  • 3.148, Аноним (153), 18:02, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Так обычно про разработку zfs для freebsd линуксоидами орут сами линуксоиды. Они на 12-й ветке не сидят.

    А сейчас тихо, потому как баг.

    И неизвестно, вдруг линуксоиды накосячили, значит орать нельзя.

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

     
  • 3.275, Лёха (?), 14:47, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В 15 вроде тоже норм, жрать не просит, падать не валится, хоть и не труЪ православная... (оговорюсь -- на десктопе).
     
  • 2.77, пох. (?), 14:19, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто накосячил? Опять Клара или чудные линукс-смузихлёбы?

    похоже не клара - клара случайно вляпалась.
    С девушками это бывает.

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

    > Пока линуксоиды не начали программировать свой ZOL, всё было относительно неплохо. Давно

    э... там в том самом чудо-тредике передавали привет hole_birth
    Как ни странно, пока линуксоиды не начали - число багов было четным и оно не проявлялось.
    Баг, заметим, именно линуксоиды потом и исправляли.

    > ждал такой диверсии.

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

     
     
  • 3.88, Аноним (153), 14:27, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > вытащили на поверхность какой-то кал вероятно бывший там давно

    Ууу, так это санки виноваты, что в линуксе проявилось? Ах они, негодники! Всё заранее продумали. :D

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

    Вот именно, что не проявлялось. Пока кто-то не начал расшатывать.

    Но вопрос пока остаётся открытым.

    С таким раскладом фряхе остаётся только заменить все подсистемы ядра на линуксовые и сидеть бить баклуши. Что и происходит.

    Отличная работа, FreeBSD Foundation!

     
     
  • 4.98, пох. (?), 14:56, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Ууу, так это санки виноваты

    не помню кто там автор - возможно уже наследники из иллюмоса.

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

    Найдено и исправлено - линуксной тусовкой. Когда-то она такое - могла.

    > Отличная работа, FreeBSD Foundation!

    foundation не может ничего противопоставить дерьмоделам из iX.

     

  • 1.49, fidoman (ok), 13:37, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Всё, доломали легаси?
     
     
  • 2.100, пох. (?), 15:22, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    в том и дело что понять не могут. Если только легаси - выключаешь фичу и спишь спокойно.
    Но нет уверенности что это наоборот, не привет от бага из дремучего легаси, до которого случайно докопались вот сейчас.

     
     
  • 3.176, Аноним (-), 21:58, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > в том и дело что понять не могут. Если только легаси -
    > выключаешь фичу и спишь спокойно.
    > Но нет уверенности что это наоборот, не привет от бага из дремучего
    > легаси, до которого случайно докопались вот сейчас.

    Судя по https://github.com/openzfs/zfs/issues/15275 - покой вам только снится. Там если вокруг по ссылкам поклацать, можно надолго потерять спокойный сон. Такого даже у Кента хрен найдешь, пожалуй.

     
  • 2.121, OpenEcho (?), 16:17, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Всё, доломали легаси?

    И что теперь на хайпе, если ZFS стал легаси?

    Файл система БТР?

     

  • 1.51, fidoman (ok), 13:39, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, этим "разработчикам" не приходила в их светлые головы мысль, что если я копирую файл, то мне нужна КОПИЯ файла, а если я хочу чтобы эти два файла ссылались на одни и те же блоки, то я бы включил -o dedup?
     
     
  • 2.134, 1 (??), 17:12, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну и чем КОПИЯ (авторская раскладка сохранена) отличается от копии с автодупликацией ? Тебе на пользовательском уровне не всё равно
    Если тебе нужна прям КОПИЯ КОПИЯ - копируй в другое облачко.
     
     
  • 3.167, Аноним (165), 19:43, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и чем КОПИЯ (авторская раскладка сохранена) отличается от копии с автодупликацией ?

    Тем, что при повреждении носителя вероятность потерять все копии значительно ниже.

    > Тебе на пользовательском уровне не всё равно

    У пользователей Винда и Мак, на которых ZFS, очевидно, нет. При чём тут пользовательский уровень к серверным файловым системам?

    > Если тебе нужна прям КОПИЯ КОПИЯ - копируй в другое облачко.

    Я и есть «облачко». Что теперь делать прикажешь?

     
     
  • 4.172, Аноним (172), 20:11, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >У пользователей Винда и Мак

    Где Вы берёте таких пользователей?
    На более разумных не хватает ФОТ?

     
     
  • 5.203, Аноним (165), 01:01, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У 1% элитарных войнов-линуксойдов денег нет. Приходится с быдло99% возиться. А что сделать, элитность юзеров в тарелку не положишь.
     
  • 3.171, fidoman (ok), 20:06, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    1) меньше i/o, потому что при записи не надо аллочить блоки и обновлять счётчики ссылок.
    2) уверенность, что при перезаписи этого файла (если это образ виртуалки к примеру) неожиданно не кончится место - то есть информация о том что места не хватает вылезет в момент когда человек сидит за консолью и копирует, а не в 23:00 31.12

    Ах да, простите, наверное я всё же не ответил на ваш вопрос. С ПОЛЬЗОВАТЕЛЬСКОЙ точки зрения, конечно же, всё равно.

     
     
  • 4.235, 1 (??), 09:47, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > 1) меньше i/o, потому что при записи не надо аллочить блоки и обновлять счётчики ссылок.

    Т.е. Вы считаете что при копировании 2Тб файла i/o будет меньше чем при clone ? Я что-то пропустил и завезли новую математику ?
    > 2) уверенность, что при перезаписи этого файла (если это образ виртуалки к примеру) неожиданно не кончится место

    Это вот ближе к теме ... Правда не при "перезаписи", а при перемещении ... на другой датастор, например. Всегда есть вероятность, что при дедупликации и сжатии места не хватит при реаллокейте ... Но что-то я мало видел желающих проводить работы в 23:00 30.12.

    Тут же отвечу из поста повыше, по поводу порчи места на носителе... Там между носителем и FS ещё пара уровней имеется.

     
     
  • 5.257, fidoman (ok), 12:50, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Т.е. Вы считаете что при копировании 2Тб файла i/o будет меньше чем при clone ? Я что-то пропустил и завезли новую математику ?

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

     
     
  • 6.326, Аноним (319), 01:35, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну во первых оно займет место И это стоит денег Во вторых - IO таки грузит И ... большой текст свёрнут, показать
     
  • 2.197, Аноним (-), 00:42, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, этим "разработчикам" не приходила в их светлые головы мысль, что если
    > я копирую файл, то мне нужна КОПИЯ файла,

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

    Что актуально для деплоя десятка виртуалок из шаблона например. Они изначально одинаковые, отличаться могут маргинально, и в результате места сожрут в разы меньше. Без жора сотен рамы на дедуп и нагрузки на проц - виртуалки и сами по себе это покушать не против, еще ФС это давать.

     
     
  • 3.231, fidoman (ok), 09:19, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > явно запросил

    Откуда инфа про "явно"? В обсуждении пишут что оно автоматом стало делаться при копировании в свежих coreutils.

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

    сделай zfs clone шаблона и запускай
    Не так гибко в том плане что нельзя шаблон грохнуть, но по крайней фича старая и больше шансов, что работает нормально, и не включается сама там где её не просят.

     
     
  • 4.286, пох. (?), 19:32, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Откуда инфа про "явно"? В обсуждении пишут что оно автоматом стало делаться при копировании в
    > свежих coreutils.

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

    > сделай zfs clone шаблона и запускай

    Как жаль что zfs не умеет clone отдельных файлов (нет)

    Песок плохая замена овсу. Отсутствие у cow-based fs рефлинков - очень странная проблема. Как бы намекающая нам что в разработке все плохо (потому что попытки ее решить тянутся уже лет пять)

     
  • 4.290, Аноним (-), 20:19, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    С точки зрения файлухи - софт должен явно ioctl вхреначить на это дело, сигняля ... большой текст свёрнут, показать
     
     
  • 5.308, fidoman (ok), 11:19, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > из соображений сохранности

    Не о сохранности речь, если бы речь была о ней, то, допустим, сделать копию файлика в папочку save перед тем как вносить какие-то изменения - тут reflink был бы как раз уместен, эдакий снепшот 1 файла, разрастающийся только по мере того, как делается cow.
    Нет, вопрос если я делаю копию допустим файла БД или образа диска и хочу чтобы это была другая БД/виртуалка - тут уже однозначно надо, чтобы все блоки были сразу закопированы и у каждого файла они были свои - и дальнейшая работа с ними происходила без дрoчилова метадаты.

     
     
  • 6.322, Аноним (319), 00:52, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если это не интересовало, то идея делать вот именно полную честную копию, когда ... большой текст свёрнут, показать
     

  • 1.53, fidoman (ok), 13:45, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Выкинуть бы всё это "творчество", но проблема только в том, что другого решения для raid5/raid6 с хешами для проверки целостности данных на дисках в общем-то и нет, а обнуление секторов или просто их порча даже при не особо большом объёме данных происходят регулярно...
     
     
  • 2.62, Tron is Whistling (?), 14:03, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чего, простите?
    RAID5/6 собственно и позволяет проверить целостность...
     
     
  • 3.112, fidoman (ok), 15:58, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Чего, простите?
    > RAID5/6 собственно и позволяет проверить целостность...

    RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.

     
     
  • 4.139, аНОНИМ (?), 17:31, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.

    А вот RAID6 теоретически позволяет (если битые данные на одном диске из всех), но опять же нихрена такого mdraid не делает. Я проверял.

     
     
  • 5.226, Аноним (-), 03:12, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.
    > А вот RAID6 теоретически позволяет (если битые данные на одном диске из
    > всех), но опять же нихрена такого mdraid не делает. Я проверял.

    А на btrfs такое даже работает, я для RAID1 и DUP проверял - таки просекает какая копия битая, чинит, и продолжает работать как ни в чем ни бывало. Даже на сыпучей флешке выживает. Выглядит как потрошеный окунь в живой воде у стругацких, но при всем этом - еще и работает. Крутануть теорвер в свою пользу - по своему забавно.

     
     
  • 6.228, аНОНИМ (?), 09:09, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А на btrfs такое даже работает, я для RAID1 и DUP проверял - таки просекает какая копия битая, чинит, и продолжает работать как ни в чем ни бывало. Даже на сыпучей флешке выживает.

    На бтрфс с миррорами -- работает. С раид5-6 когда я проверял (довольно давно) -- НЕ работало. Отдавало примерно половину файлов или меньше, остальные io error. А вот OpenZFS что с миррорами, что с рейдZ1/2 -- тоже железобетонно всё отдавало.

    Я проверял очень просто -- писал файлы, потом делал dd if=/dev/urandom of=/весь/девайс/из/рейда и монтировал ФС взад. ZFS усралось спамить в dmesg, но всё железобетонно отдало. А после скруба стало как новое. btrfs с raid5/6 обломался.

    Допускаю, что сейчас там raid5 починили и он уже всё отдаст. Но проверить пока негде.

     
     
  • 7.323, Аноним (319), 01:16, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А я умею читать документацию, и если нечто озвучено как экспериментальная фича -... большой текст свёрнут, показать
     
  • 3.168, Аноним (165), 19:44, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я смотрю ты шаришь. Не объяснишь по простому, что такое write gap у RAID5/6?
     
     
  • 4.182, Tron is Whistling (?), 22:58, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не объясню - это ошибочный термин.
     
  • 4.183, Tron is Whistling (?), 23:00, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И применять его в контексте рейда не следует, термин write gap действительно существует - но он относится к аппаратуре записи магнитных накопителей, а вовсе не к рейду, и не имеет прямого отношения ни к надёжности, ни к производительности, хотя влияет на оба параметра.
     
     
  • 5.204, Аноним (204), 01:04, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тогда мне поясни за wright hole.
     
  • 2.63, Tron is Whistling (?), 14:04, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если у вас порча секторов происходит регулярно - есть смысл посмотреть в сторону стабильности платформы, скорее всего данные теряются до записи на диск.

    Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор не может.

     
     
  • 3.110, fidoman (ok), 15:49, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Если у вас порча секторов происходит регулярно - есть смысл посмотреть в
    > сторону стабильности платформы, скорее всего данные теряются до записи на диск.
    > Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор
    > не может.

    google:bitrot

     
     
  • 4.184, Tron is Whistling (?), 23:03, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Плджад. Там ECC. Причём на современных накопителях - не обязательно одноуровневый даже.
     
  • 4.191, Tron is Whistling (?), 23:37, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Поэтому никакой битврот вы получить не можете.
    Если вдруг ошибка пройдёт ECC, вероятность чего запредельно мала - вы вместо данных в секторе (512 байт или целых 4К ныне) получите кашу, потому что наборов данных, подходящих под один и тот же "хеш" ECC (там конечно не хеш, там многомерные поля, но не будем об этом) - не много.
     
  • 3.114, fidoman (ok), 15:59, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если у вас порча секторов происходит регулярно - есть смысл посмотреть в
    > сторону стабильности платформы, скорее всего данные теряются до записи на диск.
    > Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор
    > не может.

    ECC пропускает ошибки с вероятностью, которая на больших системах (или при длительной эксплуатации средних) заметна практически.

     
     
  • 4.185, Tron is Whistling (?), 23:05, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чего? Чтобы ECC современного накопителя пропустил ошибку - надо очень постараться.

    Современные HDD и SSD вообще только благодаря ECC можно сказать и работают, если чисто гипотетически убрать ECC - их использовать будет вообще толком невозможно.

    Ещё раз повторюсь: если у вас это возникает регулярно - смотрите в район платформы, а не накопителя.

     
     
  • 5.221, Аноним (-), 02:26, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Агаблин, а у меня есть текучая флеха где EXT4 за месяц - в труху Наверное это м... большой текст свёрнут, показать
     
  • 3.141, аНОНИМ (?), 17:36, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Потому что у накопителей свои ECC, и вот просто так "обнулиться" сектор не может.

    Странно как-то, "у накопителей свои ECC", но вот параметр BER для накопителей тем не менее приводят: https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/publ (1 ошибка на 10^15 бит). И если его пересчитать в терабайты прочитанного, это будет всего-то сотня терабайт. Откуда сразу следует вывод, что хранить данные на raidz1/raidz2, где каждый блок на каждом диске защищён отдельной чексуммой -- есть смысл.

    А кому собственные данные не важны -- ну те ext4 пользуются, вон как диванные эксперты вокруг.

     
     
  • 4.186, Tron is Whistling (?), 23:19, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Звон-то вы слышали Хоть бы потрудились сами почитать, что запостили Начнём с... большой текст свёрнут, показать
     
     
  • 5.187, Tron is Whistling (?), 23:19, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почему ныне не приводят BER? Цифирь слишком неприглядная. При штатном чтении многобитовая ошибка - норма жизни. Особенно на черепичках.
     
  • 5.190, Tron is Whistling (?), 23:32, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут правда я одну вещь не упомянул Наличие NCER не значит, что сектор не прочит... большой текст свёрнут, показать
     
     
  • 6.230, аНОНИМ (?), 09:15, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Наличие NCER не значит

    Вообще-то как раз и значит, иначе бы его маркетолухи не назвали бы "*NON*-correctable"

     
     
  • 7.232, Tron is Whistling (?), 09:41, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Для начала давай ещё раз поясню, что такое NCER в этом контексте. NCER - это значит, что сектор с первого раза корректно прочитать не удалось. Не просто ECC отработала (это BER, точнее не совсем BER, но опустим), а ECC сказала, что всё, задница. Но это не значит, что его не удастся прочитать со 2 захода например.

     
     
  • 8.254, аНОНИМ (?), 12:23, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это ниоткуда не следует И в даташите не написано Значит -- не факт и я имею пр... текст свёрнут, показать
     
     
  • 9.294, Tron is Whistling (?), 22:01, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Можешь предполагать чего угодно Если данные действительно ценные - надо совсем ... текст свёрнут, показать
     
  • 5.222, Аноним (-), 02:28, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > BER - оно и есть приблизительная оценка частоты срабатывания ECC в обычных
    > условиях работы, без повреждений накопителя. Как часто будет возникать ошибка ECC
    > при чтении в штатных условиях. Я выше написал: если бы не
    > ECC - да, накопителями бы вообще пользоваться невозможно было.

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

     
     
  • 6.233, Tron is Whistling (?), 09:43, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    То, что у тебя есть сыпучее китайское говно - это не значит, что его надо в серьёзном проде использовать.
    Ну, ты - можешь.
    И да, то, что ты видишь - далеко не BER.
    Это NC + ECC false positive. В китайских поделках встречается очень часто, поэтому что на ECC тоже экономят.
     
     
  • 7.327, Аноним (319), 02:02, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да вот знаете, чексуммы очень помогают понять что реально подсунули и как это ре... большой текст свёрнут, показать
     
  • 5.229, аНОНИМ (?), 09:14, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Не 1 на 10^15, а <1 на 10^15. Разницу улавливаете?

    Улавливаю. Жопоруки даже 1e-16 ниасилили.

    > и выдаст как нечитаемый сектор.

    Это утверждение нуждается в доказательства.

    > ECC false positive ratio же на несколько порядков меньше

    И это -- тоже. Ну вот прям для конкретного жопоруками сделанного накопителя.

     
     
  • 6.234, Tron is Whistling (?), 09:46, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Улавливаю. Жопоруки даже 1e-16 ниасилили.

    1e-15 - это было очень много на те же терабайтные драйвы в 3-4 болвашки.
    Объёмы выросли, а частота возникновения ошибок не уменьшилась.

    По идее со всем этим ростом размера ECC / улучшения алгоритмов - должно было бы быть лучше, но всё это "съелось" тем, что уменьшился размер ячейки записи + при записи внахлёст, которая обычно используется, всё реально очень плохо.

    Всё остальное - беллетристика.


     
  • 5.297, Аноним (297), 22:44, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Эту ошибку поймает та самая ECC, и выдаст как нечитаемый сектор

    К сожалению - нет. Всё, что смогла поймать ЕСС, она исправила. Эта ошибка - настоящая, никто её не заметил. Вы получаете блок, в котором ошибка. При больших объёмах вероятность ошибок становится существенной. Поэтому - только контрольные суммы, RAIDZ1/2/3, правильные серверные диски, которые при записи проверяют,что блок записался правильно. Т.е. просто бэкапы тут не помогут, разве что делать несколько и сравнивать их между собой, выбирая ошибки вручную. Получая в процессе записи-чтения бэкапов новые ошибки :)

     
     
  • 6.299, Tron is Whistling (?), 23:17, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то да, но продолжайте верить в булшит.
     
     
  • 7.314, Аноним (297), 16:04, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > продолжайте верить

    в безошибочность ЕСС :)

     
     
  • 8.317, Tron is Whistling (?), 22:39, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Обычно алгоритм ECC ловит немножко больше, чем способен исправить ... текст свёрнут, показать
     
     
  • 9.328, Аноним (319), 05:19, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    1 Сила FEC в роли абстрактной чексуммы совершенно не обязана быть чем-то этак... большой текст свёрнут, показать
     
     
  • 10.329, Tron is Whistling (?), 11:54, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Про объём уже писал, на современных хардах лет много уже ECC может добавлять п... текст свёрнут, показать
     
     
  • 11.357, Аноним (319), 02:18, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Раньше был еще более приличным - в процентном соотношении В частности 4K сектор... большой текст свёрнут, показать
     
  • 10.330, Tron is Whistling (?), 11:57, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И да, 2 256 - это всего-то ничего, 32 байта Объём современных ECC на сектор нес... текст свёрнут, показать
     
     
  • 11.356, Аноним (319), 02:01, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И тем не менее, это совершенно астрономическое число Даже 2 128 попыток обломно... большой текст свёрнут, показать
     
     
  • 12.371, Tron is Whistling (?), 14:10, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы про китайский хлам или что Так-то нормальные производители FEC берут с хорош... текст свёрнут, показать
     
     
  • 13.373, Аноним (319), 21:16, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А нормальные производители - это кто А то если взять допустим самсунь - у них н... большой текст свёрнут, показать
     
  • 8.333, Tron is Whistling (?), 12:08, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну смотри - пока ты искал битвротики в ECC - твоя ZFS тебе незаметно порола данн... текст свёрнут, показать
     
     
  • 9.335, Tron is Whistling (?), 12:21, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И вот конкретно поэтому лучше выбирать простые как доска стеки - ECC накопителя,... текст свёрнут, показать
     
     
  • 10.358, Аноним (319), 02:20, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Глядя на количество юзеров которым энтерпрайзне SSD вынесли ЭТО внезапным роялем... текст свёрнут, показать
     
  • 2.73, пох. (?), 14:16, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Выкинуть бы всё это "творчество", но проблема только в том, что другого
    > решения для raid5/raid6 с хешами для проверки целостности данных на дисках

    тебе решение для локалхоста или данные хранить? Для второго "другое" - не-open solaris, или хотя бы вот FreeBSD до эры тяпляперов (т.е. 11.1 какая-нибудь)

    > в общем-то и нет, а обнуление секторов или просто их порча
    > даже при не особо большом объёме данных происходят регулярно...

    э... понятно...


     
     
  • 3.111, fidoman (ok), 15:55, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> в общем-то и нет, а обнуление секторов или просто их порча
    >> даже при не особо большом объёме данных происходят регулярно...
    > э... понятно...

    В смысле, ты даже не читал статьи на тему того, зачем вообще контрольные суммы в ZFS ввели?
    И не встречал дисков, которые побитые сектора вместо того, чтобы записать в pending, тупо их ремапят, заполняя нулями? И не понимаешь почему стандартный RAID5 такое изменение не может корректно отработать?

     
     
  • 4.188, Tron is Whistling (?), 23:21, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > И не встречал дисков, которые побитые сектора вместо того, чтобы записать в
    > pending, тупо их ремапят, заполняя нулями?

    Это как правило диски под линейную циклическую видеозапись, зачем вы их такие берёте?
    Плюс стандартный RAID5 такое щщастье замечательно отработает.

     
     
  • 5.265, нах. (?), 13:40, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    причем прошлого десятилетия Я не слышал о подобных проблемах у пресловутых wd p... большой текст свёрнут, показать
     
  • 4.223, Аноним (-), 02:32, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это вообще - unspecified Фирмвара что хочет - то и делает Нет никаких требован... большой текст свёрнут, показать
     
     
  • 5.236, Tron is Whistling (?), 09:51, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> И не понимаешь почему стандартный RAID5 такое изменение не может корректно отработать?

    RAID 5/6 и не надо быть в курсе - и вменяемые контроллеры делают проверку при регулярных прогонах Patrol Read / Consistency Check. Нет, не при каждом хостовом чтении естественно, но при каждом чтении оно и не нужно - оно нужно чтобы как раз найти сектора, которые вот такие вот гнилые диски забили фигнёй.

     
     
  • 6.237, Tron is Whistling (?), 09:52, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В любом случае подобные диски и данные, которые жалко - это неюзабельный кейс, который не вижу смысла далее рассматривать.
     
  • 6.359, Аноним (319), 02:35, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    У меня другие идеи на этот счет С чексуммами соотношения явно лучше, при том до... большой текст свёрнут, показать
     
     
  • 7.366, Tron is Whistling (?), 10:04, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я тут уже пару раз писал, и в третий тебе напишу: за 15 лет ни одного обращения к бэкапам.
    Но вы продолжайте получать удовольствие.

    Из ненадёжных тазиков никакие надёжные структуры вы не соберёте. Нет - соберёте. До первого залетевшего дятла. Не вы первые, не вы последние. Даже гугл тазики такого типа ставит только на GGC, который потерять не жалко.

     
     
  • 8.374, Аноним (319), 21:25, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы ни разу не ответили мне на 1 простой вопрос - как вы вообще проверяли целостн... большой текст свёрнут, показать
     
     
  • 9.375, Tron is Whistling (?), 23:08, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего гугл не собрал Вы их самодельные тазики, которые сервис, а не no-problem... текст свёрнут, показать
     
     
  • 10.377, Аноним (-), 04:12, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не понимаете хотя это нормально, когда уровень обсуждаемого превышает способ... большой текст свёрнут, показать
     
     
  • 11.383, Tron is Whistling (?), 09:27, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы просто не понимаете, что это целый комплекс мер Распределённые структуры оче... текст свёрнут, показать
     
     
  • 12.388, Аноним (-), 15:50, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На мой вкус - сперва извольте ответить на вон тот простой вопрос, как вы вообще ... большой текст свёрнут, показать
     
     
  • 13.393, Tron is Whistling (?), 21:24, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Недорого и круто - это вообще не про гугл Следует Накладные расходы на распара... текст свёрнут, показать
     
     
  • 14.398, Аноним (390), 22:34, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это квинтэссенция гугл Одна из вещей которые конкурентам нечем крыть - они не п... большой текст свёрнут, показать
     
     
  • 15.403, Tron is Whistling (?), 09:38, 29/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, пока оно в пустоту пишется, инопланетяне сидят и строят индексы Ничего не и... текст свёрнут, показать
     
  • 13.409, Tron is Whistling (?), 21:37, 01/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В распределёнках самое интересное начинается именно тогда, когда НЕ совпал Вот ... текст свёрнут, показать
     
  • 5.287, пох. (?), 19:38, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Это вообще - unspecified. Фирмвара что хочет - то и делает. Нет никаких требований что должно
    > случиться если энный сектор прочитать не удалось.

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

    Если вы напоролись на диски которые вместо этого возвращают какие-то там нули - назовите конкретную модель.

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

     
     
  • 6.295, Tron is Whistling (?), 22:03, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не, такая серия у сигейта действительно была. Video-only. Этот треш действительно забивал сектора при ремапе (видеопотоку-то фиолетово), в рейды его категорически ставить было нельзя.
     
     
  • 7.310, Аноним (309), 12:45, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не, такая серия у сигейта действительно была. Video-only.

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

    ATA Streaming feature set появился не позже 2004, со специальными командами для "priority on the time to transfer the data rather than the integrity of the data". Заявление о дисках, которые переносят поведение специальных команд на обычные, звучит совсем неубедительно. Эти команды были придуманы, чтобы не менять поведение обычных, нужна конкретная багованная модель без обобщений.

     
     
  • 8.346, пох. (?), 17:07, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    да какая разница все равно ты в розницу это чудо не купишь Что-то специфичное ... текст свёрнут, показать
     
     
  • 9.351, Tron is Whistling (?), 22:49, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А вот это - да, верно ... текст свёрнут, показать
     
  • 6.361, Аноним (319), 03:07, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А кто его знает что в голове у тех разработчиков фирмварей Они решили делать во... большой текст свёрнут, показать
     

     ....большая нить свёрнута, показать (68)

  • 1.60, Tron is Whistling (?), 14:02, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Как ЖЫ ТАК. А вот эта вся сквозная целостность феерическая? Чексуммы на каждый чих, вдруг битик улетит (с диска-то, у которого свой ECC, и по шине с контролем чётности?)...

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

     
     
  • 2.249, нах. (?), 11:31, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну не торопись - мы же можем еще и наоборот - неправильно посчитать сумму правильных данных. И ХРЕН мы теперь тебе дадим их прочитать!

     

  • 1.69, Аноним (69), 14:12, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    ext4 - самая стабильная и надежная если хранить файлы
    xfs - кончается место - данные xfs_repair убивает
    zfs - просто рассыпается из-за неудачного ребута сервера
    btrfs - ничего сказать не могу, особо не юзал, но говорят данные теряет как xfs и zfs вместе взятые причем полностью и починке не подлежит

    есть еще ufs2 у фряшников, так то вообще не фс, а какое-то недоразумение

     
     
  • 2.76, Аноним (82), 14:18, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > ext4 - самая стабильная и надежная если хранить файлы
    > xfs - кончается место - данные xfs_repair убивает
    > zfs - просто рассыпается из-за неудачного ребута сервера
    > btrfs - ничего сказать не могу, особо не юзал, но говорят данные
    > теряет как xfs и zfs вместе взятые причем полностью и починке
    > не подлежит
    > есть еще ufs2 у фряшников, так то вообще не фс, а какое-то
    > недоразумение

    С ext4 без трёх бекапных копий вообще работать невозможно. Да ещё и 12309 донимает.

     
  • 2.78, Аноним (153), 14:20, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Но ты ufs2 в глаза не видел, особо сказать ничего не можешь, но всё же говоришь.
    Конечно фс со снапшотами против ext4 без них - недоразумение, куда ей до этого.
    И почитай историю ext-систем. Узнаешь, где ФС, а где нет. :)

     
  • 2.118, fidoman (ok), 16:08, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > zfs - просто рассыпается из-за неудачного ребута сервера

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

     
     
  • 3.192, Tron is Whistling (?), 23:40, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот в этой новости - оно самоубивается. До состояния "не вытащить никак". Ну, то, что убилось, конечно.
     
     
  • 4.389, Аноним (-), 19:11, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    С практической точки хрения, если у вас даже и убилась копия копии файла - это, ... большой текст свёрнут, показать
     
  • 2.123, OpenEcho (?), 16:26, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > ext4 - самая стабильная и надежная если хранить файлы
    > xfs - кончается место - данные xfs_repair убивает
    > zfs - просто рассыпается из-за неудачного ребута сервера
    > btrfs - ничего сказать не могу, особо не юзал, но говорят данные теряет как xfs и zfs вместе
    > взятые причем полностью и починке не подлежит
    >
    > есть еще ufs2 у фряшников, так то вообще не фс, а какое-то недоразумение

    Какой богатый опыт !!!

    И как же вы с такими руками еще EXT4 не сломали ?

     
     
  • 3.250, нах. (?), 11:32, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а как он ее сломает если в его винде - ntfs?

    Богатый опыт у него - чтения разной чуши в интернетах.

     

  • 1.74, Tron is Whistling (?), 14:16, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Самое прикольное за кадром осталось.

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

    Т.е. продолжайте есть кактус. Если bclone был - придётся копировать весь пул. Удачи, ребятО.

     
     
  • 2.81, пох. (?), 14:21, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Во-первых, обнаружить файлы, ссылающиеся на блоки с некорректным рефкаунтом - на данный

    fsck же для трусов. zfs без него обойдется, так все бандерлоги говорят и потому это правда!

     
     
  • 3.271, Аноним (269), 14:31, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Руководство по администрированию файловых систем ZFS Solaris 8226 Октябрь 200... большой текст свёрнут, показать
     
     
  • 4.345, пох. (?), 17:04, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Руководство по администрированию файловых систем ZFS Solaris • Октябрь 2009 г.

    оно ж точно по-русски было написано.

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

     
     
  • 5.407, Аноним (269), 13:48, 01/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не понял юмора. Цитата из PDF на русском с сайта Оракла.
     
     
  • 6.408, пох. (?), 17:44, 01/12/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и ? Машиннопереведенная чушь.

    Вас удивляет что она оказалась на сайте оракла?

     
  • 2.85, Аноним (82), 14:25, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С линуксовыми такая ж фигня. Пока что-то разваливаться не начнёт, хрен поймаешь ошибку.
    И опять переустановка линукса, которая уже так же обязательна через некоторое время, как и переустановка венды.
     

  • 1.75, Аноним (82), 14:16, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Такое ощущение, что тут уже линуксоидов не осталось, только представители маркетинговых отделов корпорастов, бьющихся в истерике "защищая линуксократию"
     
  • 1.84, Аноним (86), 14:23, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ext4 gang reporting in
     
     
  • 2.362, Аноним (319), 03:12, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > ext4 gang reporting in

    Да, расскажите как вы определяете что данные вообще не побились :). Технологией страуса чтоли?

     

  • 1.91, bazanul (?), 14:34, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ext2 для ноутбуков, для остального есть ext4
     
  • 1.97, Аноним (96), 14:51, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    EXT* а дети пусть балуются чем хотят.
     
  • 1.119, Мурат (?), 16:09, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    если кто-то выключает sync, checksum, брезгует пользоваться хотя бы раз в неделю тем же scrub, в итоге получает то, чего заслужил.
     
     
  • 2.189, Tron is Whistling (?), 23:23, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ни первое, ни второе, ни третье - от описанной х*ты не помогут.
     

  • 1.124, Sw00p aka Jerom (?), 16:41, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    дедуп говорили они, спасибо поржал :)
     
     
  • 2.224, Аноним (-), 02:36, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > дедуп говорили они, спасибо поржал :)

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

    А то что вы на вашу ФС не видели - так у проприетарщиков багтрека на публику не вывешено. Это не значит что там все идеально было. Тот же NTFS одно время например наповал тер себя если диск более 2 терабайт. Там wrap случался по мере забития места - и в какой-то момент оно выносило партишн, MFT и проч - после чего это технически уже "не совсем NTFS" за отсутствием его самых критичных частей.

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

     
     
  • 3.282, Аноним (282), 18:26, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Пруф то будет? Или у тебя обычные 294е об ратушки?
    Перепутал проблему mbr диска больше 2Тб с старым багом, у небольшого процента людей, заполнения больше 90% диска?

     
     
  • 4.360, Аноним (319), 02:54, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я честно говоря не помню всех деталей - это было в районе XP 2003 чтоли, когда д... большой текст свёрнут, показать
     
     
  • 5.406, Аноним (406), 06:58, 30/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    То что не помнишь прямо совершенно тебе не мешает с диким апломбом нести ересь ... большой текст свёрнут, показать
     

  • 1.127, Аноним (127), 16:44, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В FreeBSD 14-RELEASE по дефолту vfs.zfs.bclone_enabled=0
    Так что, расходимся. А линуксоиды пускай страдают.
     
     
  • 2.147, 1 (??), 17:56, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут же пишут, что ашипка непонятно где, и может вылезти даже если bclone выключен.

    У меня на TrueNAS
    truenas% uname -a
    FreeBSD truenas.local 13.1-RELEASE-p9 FreeBSD 13.1-RELEASE-p9 n245429-296d095698e TRUENAS amd64
    truenas% zfs -V
    zfs-2.1.13-1
    zfs-kmod-v2023100900-zfs_dd2649a68

    с gentoo в виртуалочке, проблема не воспроизводится. Ну правда ZFS на ZFS - мало ли что даёт + или нуль в квадрате ...

     

  • 1.128, 1 (??), 17:02, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В качестве рекомендованного обходного пути блокирования ошибки предложено не устанавливать go в gentoo
     
     
  • 2.143, Аноним (143), 17:46, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лучший ответ!
     
  • 2.163, Аноним (153), 19:25, 23/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Жаль, что не питон.
     
  • 2.272, Аноним (269), 14:38, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Смеяться будем, когда гентушники локализуют проблему. У меня такое же было с ext4 на рамдиске. Пришлось накинуть немножко вольтов на процессор, что бы питание приблизилось к номиналу.)
     
     
  • 3.391, Аноним (390), 19:44, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Смеяться будем, когда гентушники локализуют проблему. У меня такое же было с
    > ext4 на рамдиске. Пришлось накинуть немножко вольтов на процессор, что бы
    > питание приблизилось к номиналу.)

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

    Особо пикантный бонус: файлуха с чексумами в таком случае орала бы на сбой чексум оптом. А вы узнали о факапе только по его факту. Вон те то багу починят - и все вернется на круги своя. А EXT4 и его фаны и дальше будут проверять целостность данных гаданием на кофейной гуще.

     
     
  • 4.404, Аноним (269), 12:20, 29/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А вот и очередной эксперт включил механическую психзащиту, не улавливая, к чему ... большой текст свёрнут, показать
     

  • 1.144, Аноним (144), 17:48, 23/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    ZFS обретает популярнось, и это хорошо. Работайте, братья!
     
  • 1.242, А.Н.Оним (?), 10:16, 24/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    В FreeBSD 13.2 с последними патчами проблема воспроизводится.
    Временный фикс:
    sysctl vfs.zfs.dmu_offset_next_sync=0
     
     
  • 2.251, нах. (?), 11:34, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну вот очень похоже что таки дело совсем не в bclone.

    > Временный фикс:
    > sysctl vfs.zfs.dmu_offset_next_sync=0

    bsd only фикс. Потому что это фича из еще неопубликованного релиза.
    Но, кажется, можно вместо этого просто не апгрейдить пул.

     
     
  • 3.253, А.Н.Оним (?), 12:04, 24/11/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 4.258, нах. (?), 12:58, 24/11/2023 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.252, 1 (??), 12:02, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    2 чая !

    Ну хоть пошла техническая инфа ...

     
     
  • 3.259, нах. (?), 12:59, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > 2 чая !
    > Ну хоть пошла техническая инфа ...

    где инфа-то? Шаманские песни пошли.


     
     
  • 4.268, 1 (??), 13:48, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Шаманские песни пошли.

    Ну есть немного ...

    Зато рекомендации -
    1. Не апгрейдить пул
    2. Если проапгрейдил - копируй данные на не проапгрейдженный пул
    3. Не можешь 1,2 - используй sysctl

     
     
  • 5.285, пох. (?), 19:24, 24/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Зато рекомендации -
    > 1. Не апгрейдить пул

    вот это - хорошая рекомендация, всегда ей следую! ;-)

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

    К счастью, до работающей raidz expansion остался примерно еще годик. Авось и починят что.

     
  • 2.302, А.Н.Оним (?), 04:11, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Проверил пул на проблемной системе на наличие файлов, полностью или частично (только начало размером recordsize) заполненных нулями - таковые не обнаружились.
    "Продолжайте вести наблюдение" (с)
     
     
  • 3.312, Аноним (312), 13:37, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сделали простой скрипт для поиска потенциально битых файлов на zfs:
    https://github.com/openzfs/zfs/issues/15526#issuecomment-1826248282
     
     
  • 4.350, нах. (?), 20:30, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    ну так себе идея считать потенциально битым любой файл с 4k нулей. У меню их есть. Да и скорость его работы "ниочинь"

    Это скрипт для разработчиков а не васянов пытающихся спасти свой ценный прон.

    Для потестить свою фс на в принципе наличие самого бага - используйте reproducer.sh, не забыв прочитать как именно его используют.

     

  • 1.311, Аноним (312), 13:35, 25/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Выпустили исправление OpenZFS
    https://github.com/openzfs/zfs/pull/15571
     
     
  • 2.343, пох. (?), 17:01, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Выпустили исправление OpenZFS
    > https://github.com/openzfs/zfs/pull/15571

    это нужно но не то исправление. Увы.

     
     
  • 3.353, пох. (?), 23:30, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Или таки то... похоже, reproducer.sh больше не работает после этого патча.

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

     

  • 1.331, Tron is Whistling (?), 12:04, 26/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Весёлая история. То есть оно ещё и с bclone вообще не связано, просто вся такая НАСКВОЗЬ(C) НАДЁЖНАЯ(TM) файловая система могла при неудачном тайминге незаметно выдавать читающему нули вместо блоков при чтении. В результате чего вся эта её СКВОЗНАЯ(TM) ЦЕЛОСТНОСТЬ(C) оказывалась бесполезна. Потому что нули записывал уже читающий, а не файловая система...

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

     
     
  • 2.332, Tron is Whistling (?), 12:07, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Особо забавно было, как тонны верующих хвалились везде непревзойдённой надёжностью этого буллшита, в то время, как оно прозрачно и незаметно пороло части из них данные просто by design.
     
     
  • 3.336, Аноним (336), 14:21, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот этот дизайн тоже не очень:

    "In general inodes and offsets start from 0 and work up -
    so almost all of the time they don't actually overflow.
    The problem with ext4 directory hash "offsets" is that they
    overflow all the time and immediately, so instead of "works
    unless you have a weird edge case" like all the other filesystems,
    it's "never works"."

     
     
  • 4.344, пох. (?), 17:02, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > it's "never works"."

    Кросивое!

     
  • 2.342, пох. (?), 17:00, 26/11/2023 [^] [^^] [^^^] [ответить]  
  • +/

    > Не спасёт она от повреждения данных системой во время чтения, до или
    > во время записи - ровно никак. А основной источник повреждения данных
    > - именно оно и есть.

    ну вообще-то нет. Такие баги которые портят данные и при этом висят необнаруженными - редкость. В ext4 скажем уже пару лет не было.


     

  • 1.354, пох. (?), 23:55, 26/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Ну и вкратце реальный источник ошибки - успехов местным васянам найти его "git blame" - как найдете, свистните. Тут в freebsd 12 очень нужно (к ней не подойдет 15571).

    При копировании файла большинство реализаций cp (а заодно tar и дофига кто еще) используют специфический метод для обнаружения в нем дыр и создания вместо нулей нераспределенных блоков которые копировать или сохранять незачем. Это НЕ чтение и сравнение с нулем, такое бы сработало как надо, но читать пару гигабайт ничего чтобы убедиться что там нули - немного глупо, и у большинства fs есть для этого отдельная фича в lseek.

    Вот в ее реализации - обмишулились чуток. Да, во времена иллюмоса еще. Или даже швятога sun - но это неточно. И если дергать SEEK_HOLE на файле половина которого еще висит где-то в кэшах и не долетела до диска - можно ненароком найти несуществующую. (так что таки привет hole_(re)birth - реинкарнировалась десять лет спустя, падла)

    Т.е, существующие данные потерять таким образом _нельзя_, повреждена будет только копия. Чтобы получить такую поврежденную копию - нужно скопировать файл ДВАЖДЫ - второй раз - сделав копию копии, причем достаточно быстро чтобы вторая копия еще не успела до конца дописаться - тогда третья оказывается несовпадающей.

    Рефлинки никак с этим не связаны. Если там и есть баг - он отдельный.

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

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

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

     
     
  • 2.363, Аноним (319), 03:20, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот в ее реализации - обмишулились чуток. Да, во времена иллюмоса еще. Или
    > даже швятога sun - но это неточно. И если дергать SEEK_HOLE на файле половина
    > которого еще висит где-то в кэшах и не долетела до диска - можно ненароком найти
    > несуществующую. (так что таки привет hole_(re)birth - реинкарнировалась десять
    > лет спустя, падла)

    Шикарно. Детектив, а не добавите эти детали с подробностями расследованоя в новость? Чисто в исторических целях, все же, шикарное расследование. Оно достойно быть в новости а не где-то в ж...е.

     
     
  • 3.369, нах. (?), 12:43, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    с этим обращайтесь к администрации сайта. Но она и так неплохо живет, незачем новости редактировать.

    Надо бежать быстрее удалять.

     
     
  • 4.380, Аноним (380), 04:34, 28/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > с этим обращайтесь к администрации сайта. Но она и так неплохо живет,
    > незачем новости редактировать.

    В принципе ты и сам можешь отредактировать, если яваскрипт отсюда выполнять не обломно, под новостью есть "исправить". Но да, без JS не работает.

    > Надо бежать быстрее удалять.

    Фороникс вон вывесил продолжение саги. А опеннет - прошляпил, хотя вон тот гражданин повторил мое достижение - и таки обставил фороникса на, наверное, сутки, устроив детективу досрочный спойлер.

     
     
  • 5.405, пох. (?), 17:07, 29/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > обломно, под новостью есть "исправить". Но да, без JS не работает.

    так оно ж премодерируется. Т.е. точно так же сиди и жди пока пчьолы прилетят.

     
  • 2.367, Tron is Whistling (?), 10:10, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, тут 146% можно обгитблеймится что-то найти.
    Вполне возможно, что связка нескольких багов.

    Но беда в том, что оно уже фигову тучу времени это счастье таскает, просто массово вылезло при правильном схождении звёзд. А у кого-то уже давно вылезло на редко используемых данных, но пока ещё не замечено, потому что вера в сквозную(c) целостность(tm) и редко используемые данные.

    Короче, лишний раз убеждаюсь в том, что трогать это не стоило :)

     
     
  • 3.370, нах. (?), 12:48, 27/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Но беда в том, что оно уже фигову тучу времени это счастье таскает

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

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

    > Короче, лишний раз убеждаюсь в том, что трогать это не стоило :)

    ну а что стоило? Не всем же подходит ntfs.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру