Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss- > bounces+blu=nedharvey.com at blu.org] On Behalf Of Jerry Feldman > > Btrs is supposedly a better > file system than ext4, but, it is still somewhat immature on Linux. I > think that if one of the major distros decides to use it as a default, > it may eclipse ext4. But, as Tom says, you need to look at your usage > patterns. The main advantage, and disadvantage of btrfs versus ext4, is the ability to do snapshots. While this is a really useful feature, reducing your dependency on backups and making it easier to get good backups, copy-on-write inherently leads to fragmentation. I don't recall if the defrag feature is implemented yet on btrfs. I know it's not implemented on ZFS. Also, btrfs and ZFS do filesystem checksumming. In ext4, whenever a disk gives you an undetected bit error, it goes undetected and uncorrected, leading to silent bit rot. If you're replicating or backing up data at the time, or basing calculations on the wrong data, then everything derived from the bad data is also bad and undetected. If you think that's not a problem, it's only because you've always used ext4 or something without checksumming up till now, and you haven't seen the logs on a system that does filesystem checksumming. On the typical ZFS fileserver that I currently support, I would say it corrects one checksum error every approx 12-18 months. It's like playing a lottery to lose everything... Sure it's not likely to happen, and even if it does happen, you probably won't hit the "jackpot" (all useful data destroyed silently and undetected.) But it's a lottery that you don't want to play. In the case of btrfs versus ext4, the immaturity is a real consideration. While the FS is stable, there are a lot of important features not yet implemented - like quotas for example. And as a result of lack of quotas - each snapshot is read/write, cannot be made read-only. They are currently working on implementing quotas, and the ability to send a snapshot from one system to another (replicate/backup a filesystem incrementally). Of all features, this is probably the one most valuable feature I use from ZFS. So I'm very eager for btrfs to be able to do the same. We formerly used an rsync nightly backup, where rsync would run 10 hours every night scanning the filesystem for changes to send. Now the incremental snapshot sends... Average 7-12 minutes. Because of the snapshots, it already knows all the blocks on disk that have changed, and it doesn't need to search for them. There's another difference - ext4 takes a long time to format a large device, while mkfs.btrfs is essentially instant. And ext4 can expand the filesystem on the fly (resize2fs) but cannot shrink while the filesystem is mounted. Btrfs is able to both expand and shrink while mounted.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |