valleysmail-l...@yahoo.de posted on Fri, 17 Jan 2014 18:33:35 +0000 as excerpted:
> I'd like to know if there are drawbacks in using btrfs with non-ECC RAM > instead of using ext4 with non-ECC RAM. I know that some features of > btrfs may rely on ECC RAM Crossed signals somewhere, as that's entirely incorrect. Btrfs does have date integrity checksumming as one of its features -- one which I'm using here BTW with raid1 mode so there's two copies of everything, on different devices, in case one goes bad -- but BTRFS IN NO WAY REQUIRES ECC RAM. ECC RAM is a hardware solution to a conceptually similar data integrity problem in memory to the problem btrfs addresses as filesystem software for non-volatile storage, but the two shouldn't be confused for each other or conflated at all -- they're entirely separate in practice, and one is hardware while the other is software. > [...] but is the chance of data corruption or even a > damaged filesystem higher than when i use ext4 instead of btrfs? The chances of data corruption or a damaged filesystem are certainly not higher on btrfs for that reason, because as I said, ECC memory is entirely unrelated to btrfs data checksumming and integrity measures. However, btrfs /is/ a rather less mature filesystem than ext4 ATM, and is in fact just now beginning to stabilize. As such, there are still bugs being actively fixed, and as the warning in mkfs.btrfs says when you create a filesystem, it's still critical to keep non-btrfs backups of anything you value, AND actually test that you can recover from them, because at this point, you just might hit one of those still existing corner-case bugs and may very well need to do just that, recover from backup! If that's concerning to you, then it's likely that btrfs isn't a good choice as your filesystem at this point. Perhaps in a year or so, as 2014 really does look to be the year that btrfs finally begins to really stabilize, but not right now. > I want to know this because i would like to use the snapshot feature of > btrfs and ext4 does not support that. I will not use btrfs for fixing > silent data corruption nor for using RAID like features or encryption. > ZFS however checks files in the background (even if i don't want) and if > it thinks there is an error it will fix it and i cannot disable this > feature. > So errors in RAM may corrupt my files or even more. While it's possible to disable the checksumming in btrfs, and in fact that and COW (copy-on-write) are recommended to be disabled for specific use-cases (large "internal-write" files such as VM images, large databases, and large pre-allocated files then filled in as the file gets written, such as many bittorrent clients create) it's definitely *NOT* recommended in general. And in fact, disabling COW would disable efficient snapshots usage as well, so it's probably not what you want. If you're after snapshotting ability without checksumming, I'd suggest looking into something like LVM, which has snapshotting as one of its major features, but without checksumming/data-integrity. LVM is a relatively mature technology that a number of distros use by default, and you can use the ext4 that you're already familiar with and that is reasonably mature as well, on top of LVM. However, I really think you need to do a bit more research, because it appears you are rather confused about filesystem checksumming and data integrity at the filesystem level, and are in fact conflating it with the entirely separate hardware ECC data integrity at memory level. The two are entirely distinct, and data-integrity at the filesystem level certainly isn't the bugbear you make it out to be, but rather, a vital part of how some filesystems work, particularly as storage sizes reach farther and farther into the multi-terabyte range. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
