https://opennet.ru/openforum/vsluhforumID3/104348.html Кент Оверстрит (Kent Overstreet) объявил (https://lkml.org/lkml/2015/8/21/22) об эволюционировании блочного устройства для кэширования доступа к медленным жестким дискам на быстрых SSD-накопителях Bcache (http://bcache.evilpiepirate.org/) в полноценную файловую систему Bcachefs (http://evilpiepirate.org/git/linux-bcache.git/log/?h=bcache-dev). Благодаря использованию накопившихся за годы разработки Bcache решений, в Bcachefs удалось добиться сочетания высокой производительности с расширенными возможностями, такими как включение в раздел нескольких устройств, репликация, кэширование, прозрачное сжатие данных и верификация целостности по контрольным суммам.<br><br><br>В Bcachefs также реализовано большинство базовых возможностей POSIX ФС, в том числе xattrs и ACL. Из пока недоступных, но запланированных к реализации, возможностей отмечаются предварительное резервирование места (fallocate), квоты и снапшоты. Файловая система основана на использовании механизма Copy-on-Write (COW), при котором изменения не приводят к пе https://opennet.ru/openforum/vsluhforumID3/104348.html#96 Sat, 29 Aug 2015 03:21:17 GMT Ты серьёзно думаешь что производство HDD сохранится ещё на долго? 8-о<br>От хорошей ситуации они 8TB диски за $260.00 продают ага ... лет 5-10 и привет как дискетам.<br> https://opennet.ru/openforum/vsluhforumID3/104348.html#95 Wed, 26 Aug 2015 08:38:34 GMT &gt; В бздах сумели довести порт ZFS до промышленного уровня в 2008 году<br><br>В 2009-м.<br> https://opennet.ru/openforum/vsluhforumID3/104348.html#94 Tue, 25 Aug 2015 21:00:43 GMT &gt;&gt; Вот, например, в линуксе ближаший аналог UFS2 - XFS, <br>&gt; Скорее нечто между EXT2 и EXT3.<br><br>Нет у них fsck в фоне и снапшоты не работают, в отличие от XFS и UFS2.<br><br>&gt; В UFS даже до сих пор нет нормальных экстентов - это ж надо все переделывать. Всем лень, "на это нет ресурсов".<br><br>Зато есть дописывание блоков, что сказывается на компактности хранения, особенно для мелких файлов на больших томах.<br><br>&gt;&gt; "своя", а заимствованная. (Аналогично Btrfs, как попытка ответа Oracle на вызов <br>&gt;&gt; Sun "комбайна" ZFS.) Но всё это - привнесённое в ядро извне <br>&gt; Пардон, у оракля нынче и то и другое. Только ZFS им даром не уперлось развивать - оно их базы не потянет. В отличие от btrfs.<br><br>ZFS у Oracle уже своя и отцепилась от авторского кода по версиям и возможностям. Новые фичи системы хранения ZFS запатентованы и открываться не спешат. Oracle сертифицировало использование ZFS для файловых хранилищ и СУБД. Btrfs же пока что для СУБД не сертифицирована, статус файлового хранилища на ней не определён.<br><br>&gt;&gt; (Хотя ZFS и отча https://opennet.ru/openforum/vsluhforumID3/104348.html#93 Mon, 24 Aug 2015 23:13:27 GMT &gt; А как же HAMMER1/2 DragonflyBSD?<br>&gt; Читал его даташи<br><br>Не ври.<br> https://opennet.ru/openforum/vsluhforumID3/104348.html#92 Mon, 24 Aug 2015 23:12:24 GMT &gt; Зачем изобретать brtfs и эту недоделку? Зачем изобретать колесо в 21 веке? <br>&gt; Уже есть zfsonlinux, работает и все там есть.<br><br>zfs и "эта поделка" по говнокодости - одного порядка/поля "ягоды".<br>btrfs (при всей его неадекватности) - хоть код выглядит более-менее вменяемым и поддающимся дальнейшему развитию.<br> https://opennet.ru/openforum/vsluhforumID3/104348.html#91 Mon, 24 Aug 2015 21:08:27 GMT &gt;&gt; Эта эпопея с btrfs длится очень давно и до сих пор нестабольное.<br>&gt; При том - обычно на словах тех кто ей и близко не <br>&gt; пользуется :) <br><br>потому что те, кто пользую#$@$&&^%$%451245&#8230;<br> https://opennet.ru/openforum/vsluhforumID3/104348.html#90 Mon, 24 Aug 2015 20:54:07 GMT &gt;&gt; просто бездумно чужие слова пересказываете)? Вопрос с подвохом: В чем ненадежность?<br>&gt; В том, что на современных объемах данных, если например вы налетите на <br>&gt; мусор - есть совсем не нулевой шанс принять его за валидные <br>&gt; данные. Просто потому что блоков данных обрабатывается много и 4 байта <br>&gt; чексуммы в таком масштабе - как-то совсем и не дофига.<br><br>Подсказка про подвох не помогла. Подвох в том, что зависит от условий применения. Если считать crc на многогигабайтные файлы (вы почему-то только этот случай видите), то может быть шанс коллизий и непомерно большой становится (да и то вовсе не факт из-за второго подвоха - зависит от характеристик появления ошибок). Но фишка в том, что так никто (ну может почти никто) не делает, да и не собирается. Поэтому кричать про ненадежность глупо в этом случае.<br>А для посекторной защиты, например, на блоки по 512 байт или по 2к, или даже по 4к, в чем проблема? А вот если для этого использовать тот же sha-2, к примеру, то любой здравомыслящий лишь пальцем у виска пок https://opennet.ru/openforum/vsluhforumID3/104348.html#89 Mon, 24 Aug 2015 20:47:57 GMT &gt;&gt; И это вполне себе недостаток этого подхода.<br>&gt; Недостаток конкретно этого формата уже недостаток подхода?<br><br>недостаток подхода &#171;стриминг очень дешёвый, seek'и очень дорогие&#187;. под который и заточен формат.<br><br>натурально, вышенаписаное никак не означает, что других подходов не существует.<br> https://opennet.ru/openforum/vsluhforumID3/104348.html#88 Mon, 24 Aug 2015 20:09:52 GMT <br>&gt; И это вполне себе недостаток этого подхода.<br><br>Недостаток конкретно этого формата уже недостаток подхода?<br><br>&gt; А один фиг - для получения списка придется очень много прочитать с диска и все это распаковать.<br><br>Если использовать не очень подходящие инструменты, напрочь игнорируя полезные "новшества" типа DAR ...<br><br><br><br>