3 ms·

> So why pick btrfs with it's dataloss stories or ZFS with it's complex management? As you mentioned, the bitrot. Also, my understanding is that a COW filesys

> So why pick btrfs with it's dataloss stories or ZFS with it's complex management? As you mentioned, the bitrot. Also, my understanding is that a COW filesystem can be more reliable than a traditional journaling filesystem in a system crash since nothing is overwritten. Plus there is compression and all of the features provided by a COW filesystem.

zaarn 8y ago
Bitrot is rare. Over the average lifetime of most consumer desktops, the loss of any personal documents is very unlikely unless it makes up a majority of the disk. And if it does, it's most likely that it affects negligible parts of the file (ie, corruption in a frame of video). The risk of bitrot becomes interesting when you talk about long timeframes like a decade. Considering the capacity and price of a 2TB disk, compression isn't the immediate need of the consumer either, unless they have a NAS, where Syno and QNAP already provide integrated solutions with btrfs and ext4 both. The modern ext4 journaling is also very battle tested, it's a very simple and resilient physical journal, data loss in ext4 happens largely when the disk is already failing or has been cheap enough to lie about the state of data being written or not. For the average consumer that sums up to "it doesn't matter enough". Something like bcachefs could change the game by being btrfs+ZFS but without the dataloss risk.
- jl6 8y ago
  Concurring on the rarity of bit rot. I have kept and verified checksums for years, over many terabytes of data, and have never observed bit rot. Of course I’ve been using btrfs RAID1, so perhaps bit rot has been silently corrected.
- eeperson 8y ago
  > Bitrot is rare. Over the average lifetime of most consumer desktops, the loss of any personal documents is very unlikely unless it makes up a majority of the disk. And if it does, it's most likely that it affects negligible parts of the file (ie, corruption in a frame of video). > The risk of bitrot becomes interesting when you talk about long timeframes like a decade. I think you are making a lot of assumptions here about frequency of bitrot, especially in the face of failing hardware. Also, consumer desktops are not the only use. There are bunch usages where the risk of bitrot is much more concerning. Or were you intending your original post to be only about consumer usage? >Considering the capacity and price of a 2TB disk, compression isn't the immediate need of the consumer either, unless they have a NAS, where Syno and QNAP already provide integrated solutions with btrfs and ext4 both. This kind of feels like you are saying that it isn't needed because it is already being used when it is needed. Am I misunderstanding? Consumers may want compression for smaller hard drives they already own in order to get more out of them. Also, compression can speed up disk IO in some workloads. > The modern ext4 journaling is also very battle tested, it's a very simple and resilient physical journal, data loss in ext4 happens largely when the disk is already failing or has been cheap enough to lie about the state of data being written or not. The issue with ext4 resilience isn't about quality of the implementation. It is a fundamental limitation of no COW filesystems. Since things are overwritten, if the system crashes mid write you can end up with partial data. COW filesystems always give you the old data or the new data. This can be worked around but that requires that all of your applications do this workaround. > For the average consumer that sums up to "it doesn't matter enough". Something like bcachefs could change the game by being btrfs+ZFS but without the dataloss risk. What makes you think bcachefs is going to be any better? A lot of functionality still has to be implemented. What makes you think that the implementation of this functionality will be any less error prone? You also haven't addressed the large pile of new features provided by BTRFS/ZFS. Snapshotting alone can make it worth the price of admission for consumers. With snapshotting, you can set up a system where rollbacks after any upgrade can occur seamlessly.
  - zaarn 8y ago
    >The issue with ext4 resilience isn't about quality of the implementation. It is a fundamental limitation of no COW filesystems. Since things are overwritten, if the system crashes mid write you can end up with partial data. COW filesystems always give you the old data or the new data. This can be worked around but that requires that all of your applications do this workaround. You do know how journalling works, yes? Unless the drive lies about the state of data being written, in which case not even COW will save you, a journal is just as good as COW. Exceptions being coding errors but those can occur on COW with the same devastating result. Maybe you don't know as much about filesystems as you want to appear to?
    - eeperson 8y ago
      > You do know how journalling works, yes? Unless the drive lies about the state of data being written, in which case not even COW will save you, a journal is just as good as COW. Exceptions being coding errors but those can occur on COW with the same devastating result. Yes, I'm aware of how journaling works. The problem with your description is that it requires both data and metadata journaling. This is rarely the case because data journaling requires that you write all of your data to the disk twice (which also requires additional seeks as well). So, nearly all in-place filesystems default to only metadata journaling for performance reasons (this is the case for ext4). This means that, in practice, if you get a system crash mid file write, you will end up with a partially updated file. On a COW filesystem you are always guaranteed the old file or the new file. > Maybe you don't know as much about filesystems as you want to appear to? That is possible, although I'm not sure how much I want to appear to know :P. More seriously, this is extremely condescending. Why is this necessary? If you think I'm wrong, just tell me I'm wrong. There is a pretty decent chance I'm wrong about most things. So, condescension shouldn't be required.

zaarn 8y ago

Bitrot is rare. Over the average lifetime of most consumer desktops, the loss of any personal documents is very unlikely unless it makes up a majority of the disk. And if it does, it's most likely that it affects negligible parts of the file (ie, corruption in a frame of video). The risk of bitrot becomes interesting when you talk about long timeframes like a decade. Considering the capacity and price of a 2TB disk, compression isn't the immediate need of the consumer either, unless they have a NAS, where Syno and QNAP already provide integrated solutions with btrfs and ext4 both. The modern ext4 journaling is also very battle tested, it's a very simple and resilient physical journal, data loss in ext4 happens largely when the disk is already failing or has been cheap enough to lie about the state of data being written or not. For the average consumer that sums up to "it doesn't matter enough". Something like bcachefs could change the game by being btrfs+ZFS but without the dataloss risk.

jl6 8y ago
Concurring on the rarity of bit rot. I have kept and verified checksums for years, over many terabytes of data, and have never observed bit rot. Of course I’ve been using btrfs RAID1, so perhaps bit rot has been silently corrected.
eeperson 8y ago
> Bitrot is rare. Over the average lifetime of most consumer desktops, the loss of any personal documents is very unlikely unless it makes up a majority of the disk. And if it does, it's most likely that it affects negligible parts of the file (ie, corruption in a frame of video). > The risk of bitrot becomes interesting when you talk about long timeframes like a decade. I think you are making a lot of assumptions here about frequency of bitrot, especially in the face of failing hardware. Also, consumer desktops are not the only use. There are bunch usages where the risk of bitrot is much more concerning. Or were you intending your original post to be only about consumer usage? >Considering the capacity and price of a 2TB disk, compression isn't the immediate need of the consumer either, unless they have a NAS, where Syno and QNAP already provide integrated solutions with btrfs and ext4 both. This kind of feels like you are saying that it isn't needed because it is already being used when it is needed. Am I misunderstanding? Consumers may want compression for smaller hard drives they already own in order to get more out of them. Also, compression can speed up disk IO in some workloads. > The modern ext4 journaling is also very battle tested, it's a very simple and resilient physical journal, data loss in ext4 happens largely when the disk is already failing or has been cheap enough to lie about the state of data being written or not. The issue with ext4 resilience isn't about quality of the implementation. It is a fundamental limitation of no COW filesystems. Since things are overwritten, if the system crashes mid write you can end up with partial data. COW filesystems always give you the old data or the new data. This can be worked around but that requires that all of your applications do this workaround. > For the average consumer that sums up to "it doesn't matter enough". Something like bcachefs could change the game by being btrfs+ZFS but without the dataloss risk. What makes you think bcachefs is going to be any better? A lot of functionality still has to be implemented. What makes you think that the implementation of this functionality will be any less error prone? You also haven't addressed the large pile of new features provided by BTRFS/ZFS. Snapshotting alone can make it worth the price of admission for consumers. With snapshotting, you can set up a system where rollbacks after any upgrade can occur seamlessly.
- zaarn 8y ago
  >The issue with ext4 resilience isn't about quality of the implementation. It is a fundamental limitation of no COW filesystems. Since things are overwritten, if the system crashes mid write you can end up with partial data. COW filesystems always give you the old data or the new data. This can be worked around but that requires that all of your applications do this workaround. You do know how journalling works, yes? Unless the drive lies about the state of data being written, in which case not even COW will save you, a journal is just as good as COW. Exceptions being coding errors but those can occur on COW with the same devastating result. Maybe you don't know as much about filesystems as you want to appear to?
  - eeperson 8y ago
    > You do know how journalling works, yes? Unless the drive lies about the state of data being written, in which case not even COW will save you, a journal is just as good as COW. Exceptions being coding errors but those can occur on COW with the same devastating result. Yes, I'm aware of how journaling works. The problem with your description is that it requires both data and metadata journaling. This is rarely the case because data journaling requires that you write all of your data to the disk twice (which also requires additional seeks as well). So, nearly all in-place filesystems default to only metadata journaling for performance reasons (this is the case for ext4). This means that, in practice, if you get a system crash mid file write, you will end up with a partially updated file. On a COW filesystem you are always guaranteed the old file or the new file. > Maybe you don't know as much about filesystems as you want to appear to? That is possible, although I'm not sure how much I want to appear to know :P. More seriously, this is extremely condescending. Why is this necessary? If you think I'm wrong, just tell me I'm wrong. There is a pretty decent chance I'm wrong about most things. So, condescension shouldn't be required.