[Btrfs-users] btrfs questions..

[Chris Mason]

On Thursday 28 February 2008, Voni Hakau wrote:
> Hi Chris,
>
> On Mon, Feb 25, 2008 at 7:05 AM, Chris Mason <chris.mason at oracle.com> wrote:
> > On Sat, Feb 23, 2008 at 01:43:36PM +0200, Voni Hakau wrote:
> > > 1. Like the btrfs name implies (b-trees fs..) I guess that it works
> > > basically like WAFL (and ZFS), is that right ?
> >
> > All three use copy on write based writeback, but beyond that there are
> > many differences.
>
> Can you please point out a one (or two) major differences ? Only if
> it's no hussle..
> I have read the WAFL papers, so I know my way around the b-trees COW
> ideas, but before I delve into btrfs code I would be happy to know its
> theoretical headlines
> and main difference from WAFL..

Again, I do not know WAFL in detail, but my understanding is that wafl 
snapshotting works via a bitmap mechanism.  The reference counted system used 
by btrfs is much more scalable, and entirely different.

The mechanics of the btrfs btree are very different from both WAFL and ZFS 
(which are very different from each other).  Btrfs stores everything as 
key/value pairs in a setup inspired by reiserfs.

>
> > > 4. What about Solid State disks ? Assuming that SSD is the future, will
> > > btrfs be able to lead even in front of new SSD
> > > requirements/limitations/advantages ?
> >
> > SSD is an important design target, and btrfs already has code (via mount
> > -o ssd) that tunes for SSD.  There is quite a lot of tuning left to go
> > in this area, but we already perform well.
>
> That's nice. are these tuning an inherent advantage of btrfs or something
> that other mainstream filesystems (ext3, ext4) will be able to adopt as
> well ?

Yes and no.  Some of them are unique to the ability to do copy on write, while 
others are just allocation tweaks.  At least for the initial allocation of 
data blocks, ext34 can do quite a lot of tuning for ssd.

>
> I have a nother question please. Ppl say the the current filesystems
> (ext3, maybe even
> ext4) are not scalable. I guess they say that because fsck is already
> too slow,  and
> disks are always getting bigger... Is that the only scalability
> problem of the current fs's ?

It is the biggest problem that can't simply be fixed by making pointers in the 
disk format larger.  It is relatively easy to address bigger storage, but 
handling errors on larger storage requires deeper changes.

>
> With respect to the scalability probs of the current fs's, is btrfs
> inherently better ?
> I guess it naturally eliminates the fsck problem, because of the COW /
> "everything is
> a snapshot" ideas. But are there more inherent advantages that will
> lead to better
> scaling ?

Btrfs has a number of features designed for repair, especially the back 
pointers for all objects and extents. fsck can never really be eliminated 
because bad things happen to good data.  But, my goal is to design in enough 
redundancy and checks to handle these errors gracefully, without taking the 
whole FS offline.

-chris