Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
On 10/05/2011 10:18 AM, Edward Ned Harvey wrote: >> 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. > > Undetected bit errors certainly can cause problems. Years ago when running on a head-per-track disk, we backed up after a batch run, and restored before the next run. At some point somehow a horse appeared in a personal trust file :-). After many hours of looking at dumps and stuff, I found the offending bit. This caused me to rant about Burroughs systems. While I don't think the time to create a file system is really a significant issue because it is essentially a one time shot. Certainly the ability to resize a filesystem online while the filesystem is mounted is an important feature. -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |