История изменений
Исправление intelfx, (текущая версия) :
Наоборот, при первой же проблеме она «падает» не давая дальше работать до починки. Идея в раннем предотвращении bit rot - чтоб в корявые данные не попадали в бекапы итп. Как только проблема с железкой - сразу стоп машина. Отсюда репутация нестабильной фс.
Ну или по крайней мере так это рассказывали в devel списке федоры те, кто продвигает этот проект.
Как оно на деле, скоро узнаем
На деле тут есть две разные ситуации, и ты их смешиваешь.
С одной стороны, за счёт CoW-архитектуры btrfs умеет вычислять и хранить чексуммы всех хранимых данных (и метаданных), с помощью чего достигается устойчивость к bit rot (определённому типу повреждений данных, который возникает из-за проблем с железом на физическом уровне).
Если при этом используется RAID или дублирование, то btrfs может исправлять повреждения — если нет, то лишь обнаруживать. Btrfs по умолчанию дублирует метаданные (mkfs.btrfs -m dup) — но лишь на HDD. Считается, что SSD слишком умные и высока вероятность того, что данные, записанные в одно время, попадут примерно в одно место флеша, вне зависимости от LBA, и никакой реальной защиты от реальных проблем с железом это не принесёт.
С другой стороны, ввиду той же самой CoW-архитектуры btrfs гораздо менее устойчива к другому типу повреждений данных — а именно, потерянным записям (которые возникают за счёт багов в софте или в прошивках).
За счёт того, что в btrfs метаданные не имеют фиксированного местоположения, а организованы в B-дерево, потеря или повреждение даже одного узла в середине дерева — это очень плохо и скорее всего приведёт к полной или почти полной нечитаемости ФС, в то время как в традиционных ФС с фиксированным расположением метаданных потеря нескольких килобайт испортит только те файлы, которые на эти несколько килобайт непосредственно легли.
И первое, и второе — это две стороны одной монетки.
Исправление intelfx, :
Наоборот, при первой же проблеме она «падает» не давая дальше работать до починки. Идея в раннем предотвращении bit rot - чтоб в корявые данные не попадали в бекапы итп. Как только проблема с железкой - сразу стоп машина. Отсюда репутация нестабильной фс.
Ну или по крайней мере так это рассказывали в devel списке федоры те, кто продвигает этот проект.
Как оно на деле, скоро узнаем
На деле тут есть две разные ситуации, и ты их смешиваешь.
С одной стороны, за счёт CoW-архитектуры btrfs умеет вычислять и хранить чексуммы всех хранимых данных (и метаданных), с помощью чего достигается устойчивость к bit rot (определённому типу повреждений данных, который возникает из-за проблем с железом на физическом уровне).
Если при этом используется RAID или дублирование, то btrfs может исправлять повреждения — если нет, то лишь обнаруживать. Btrfs по умолчанию дублирует метаданные (mkfs.btrfs -m dup) — но лишь на HDD. Считается, что SSD слишком умные и высока вероятность того, что данные, записанные в одно время, попадут примерно в одно место флеша, вне зависимости от LBA, и никакой реальной защиты от реальных проблем с железом это не принесёт.
С другой стороны, ввиду CoW-архитектуры btrfs гораздо менее устойчива к другому типу повреждений данных — а именно, потерянным записям (которые возникают за счёт багов в софте или в прошивках).
За счёт того, что в btrfs метаданные не имеют фиксированного местоположения, а организованы в B-дерево, потеря или повреждение даже одного узла в середине дерева — это очень плохо и скорее всего приведёт к полной или почти полной нечитаемости ФС, в то время как в традиционных ФС с фиксированным расположением метаданных потеря нескольких килобайт испортит только те файлы, которые на эти несколько килобайт непосредственно легли.
И первое, и второе — это две стороны одной монетки.
Исправление intelfx, :
Наоборот, при первой же проблеме она «падает» не давая дальше работать до починки. Идея в раннем предотвращении bit rot - чтоб в корявые данные не попадали в бекапы итп. Как только проблема с железкой - сразу стоп машина. Отсюда репутация нестабильной фс.
Ну или по крайней мере так это рассказывали в devel списке федоры те, кто продвигает этот проект.
Как оно на деле, скоро узнаем
На деле тут есть две разных ситуации, и ты их смешиваешь.
С одной стороны, за счёт CoW-архитектуры btrfs умеет вычислять и хранить чексуммы всех хранимых данных (и метаданных), с помощью чего достигается устойчивость к bit rot (определённому типу повреждений данных, который возникает из-за проблем с железом на физическом уровне).
Если при этом используется RAID или дублирование, то btrfs может исправлять повреждения — если нет, то лишь обнаруживать. Btrfs по умолчанию дублирует метаданные (mkfs.btrfs -m dup) — но лишь на HDD. Считается, что SSD слишком умные и высока вероятность того, что данные, записанные в одно время, попадут примерно в одно место флеша, вне зависимости от LBA, и никакой реальной защиты от реальных проблем с железом это не принесёт.
С другой стороны, ввиду CoW-архитектуры btrfs гораздо менее устойчива к другому типу повреждений данных — а именно, потерянным записям (которые возникают за счёт багов в софте или в прошивках).
За счёт того, что в btrfs метаданные не имеют фиксированного местоположения, а организованы в B-дерево, потеря или повреждение даже одного узла в середине дерева — это очень плохо и скорее всего приведёт к полной или почти полной нечитаемости ФС, в то время как в традиционных ФС с фиксированным расположением метаданных потеря нескольких килобайт испортит только те файлы, которые на эти несколько килобайт непосредственно легли.
И первое, и второе — это две стороны одной монетки.
Исправление intelfx, :
Наоборот, при первой же проблеме она «падает» не давая дальше работать до починки. Идея в раннем предотвращении bit rot - чтоб в корявые данные не попадали в бекапы итп. Как только проблема с железкой - сразу стоп машина. Отсюда репутация нестабильной фс.
Ну или по крайней мере так это рассказывали в devel списке федоры те, кто продвигает этот проект.
Как оно на деле, скоро узнаем
На деле тут есть две разных ситуации, и ты их смешиваешь.
С одной стороны, за счёт CoW-архитектуры btrfs умеет вычислять и хранить чексуммы данных и метаданных, с помощью чего достигается устойчивость к bit rot (определённому типу повреждений данных, который возникает из-за проблем с железом на физическом уровне).
Если при этом используется RAID или дублирование, то btrfs может исправлять повреждения — если нет, то лишь обнаруживать. Btrfs по умолчанию дублирует метаданные (mkfs.btrfs -m dup) — но лишь на HDD. Считается, что SSD слишком умные и высока вероятность того, что данные, записанные в одно время, попадут примерно в одно место флеша, вне зависимости от LBA, и никакой реальной защиты от реальных проблем с железом это не принесёт.
С другой стороны, ввиду CoW-архитектуры btrfs гораздо менее устойчива к другому типу повреждений данных — а именно, потерянным записям (которые возникают за счёт багов в софте или в прошивках).
За счёт того, что в btrfs метаданные не имеют фиксированного местоположения, а организованы в B-дерево, потеря или повреждение даже одного узла в середине дерева — это очень плохо и скорее всего приведёт к полной или почти полной нечитаемости ФС, в то время как в традиционных ФС с фиксированным расположением метаданных потеря нескольких килобайт испортит только те файлы, которые на эти несколько килобайт непосредственно легли.
И первое, и второе — это две стороны одной монетки.
Исправление intelfx, :
Наоборот, при первой же проблеме она «падает» не давая дальше работать до починки. Идея в раннем предотвращении bit rot - чтоб в корявые данные не попадали в бекапы итп. Как только проблема с железкой - сразу стоп машина. Отсюда репутация нестабильной фс.
Ну или по крайней мере так это рассказывали в devel списке федоры те, кто продвигает этот проект.
Как оно на деле, скоро узнаем
На деле тут есть две разных ситуации, и ты их смешиваешь.
С одной стороны, за счёт CoW-архитектуры btrfs умеет вычислять и хранить чексуммы данных и метаданных, с помощью чего достигается устойчивость к bit rot (определённому типу повреждений данных).
Если при этом используется RAID или дублирование, то btrfs может исправлять повреждения — если нет, то лишь обнаруживать. Btrfs по умолчанию дублирует метаданные (mkfs.btrfs -m dup) — но лишь на HDD. Считается, что SSD слишком умные и высока вероятность того, что данные, записанные в одно время, попадут примерно в одно место флеша, вне зависимости от LBA, и никакой реальной защиты от реальных проблем это не принесёт.
С другой стороны, ввиду CoW-архитектуры btrfs гораздо менее устойчива к другому типу повреждений данных — а именно, потерянным записям (которые возникают за счёт багов в софте или в прошивках).
За счёт того, что в btrfs метаданные не имеют фиксированного местоположения, а организованы в B-дерево, потеря или повреждение даже одного узла в середине дерева — это очень плохо и скорее всего приведёт к полной или почти полной нечитаемости ФС, в то время как в традиционных ФС с фиксированным расположением метаданных потеря нескольких килобайт испортит только те файлы, которые на эти несколько килобайт непосредственно легли.
И первое, и второе — это две стороны одной монетки.
Исходная версия intelfx, :
Наоборот, при первой же проблеме она «падает» не давая дальше работать до починки. Идея в раннем предотвращении bit rot - чтоб в корявые данные не попадали в бекапы итп. Как только проблема с железкой - сразу стоп машина. Отсюда репутация нестабильной фс.
Ну или по крайней мере так это рассказывали в devel списке федоры те, кто продвигает этот проект.
На деле тут есть две разных ситуации, и ты их смешиваешь.
С одной стороны, за счёт CoW-архитектуры btrfs умеет вычислять и хранить чексуммы данных и метаданных, с помощью чего достигается устойчивость к bit rot (определённому типу повреждений данных).
Если при этом используется RAID или дублирование, то btrfs может исправлять повреждения — если нет, то лишь обнаруживать. Btrfs по умолчанию дублирует метаданные (mkfs.btrfs -m dup) — но лишь на HDD. Считается, что SSD слишком умные и высока вероятность того, что данные, записанные в одно время, попадут примерно в одно место флеша, вне зависимости от LBA, и никакой реальной защиты от реальных проблем это не принесёт.
С другой стороны, ввиду CoW-архитектуры btrfs гораздо менее устойчива к другому типу повреждений данных — а именно, потерянным записям (которые возникают за счёт багов в софте или в прошивках). За счёт того, что в btrfs метаданные не имеют фиксированного местоположения, а организованы в B-дерево, потеря или повреждение даже одного узла в середине дерева — это очень плохо и скорее всего приведёт к полной или почти полной нечитаемости ФС, в то время как в традиционных ФС с фиксированным расположением метаданных потеря нескольких килобайт испортит только те файлы, которые на эти несколько килобайт непосредственно легли.
И первое, и второе — это две стороны одной монетки.