Linked by Thom Holwerda on Fri 27th Jul 2007 22:32 UTC, submitted by liquidat
General Development Oracle's TechCast crew interviewed [.mp3] Chris Mason on Btrfs. A kind-of transcript is available here. Btrfs is a new filesystem for Linux developed by Oracle. It features: "extent based file storage (264 max file size); space efficient packing of small files; space efficient indexed directories; dynamic inode allocation; writable snapshots; subvolumes (separate internal filesystem roots); object level mirroring and striping; checksums on data and metadata (multiple algorithms available); strong integration with device mapper for multiple device support; online filesystem check; very fast offline filesystem check; efficient incremental backup and FS mirroring."
Thread beginning with comment 258836
To read all comments associated with this story, please click here.
Heh yeah...
by Timmmm on Fri 27th Jul 2007 22:48 UTC
Timmmm
Member since:
2006-07-25

Because what linux needs is another filesystem!

Reply Score: -1

RE: Heh yeah...
by sbergman27 on Fri 27th Jul 2007 23:11 in reply to "Heh yeah..."
sbergman27 Member since:
2005-07-24

I find that the goals and feature list of btrfs, unlike Reiser4, look really exciting and *useful*. Chris also seems like a really great team player, unlike Hans.

Traditionally, I'm a big advocate of evolutionary improvement, ext3, and ext4. But btrfs really makes me smile.

Edited 2007-07-27 23:13

Reply Parent Score: 5

RE: Heh yeah...
by butters on Sat 28th Jul 2007 01:33 in reply to "Heh yeah..."
butters Member since:
2005-07-08

Because what linux needs is another filesystem!

Yes, Linux needs a new generation of filesystems and an overhauled volume manager more than anything. Storage is clearly the critical path going forward, from the datacenter to the multimedia client. Storage virtualization is weak compared to processing and memory, manageability is not where it should be, and data integrity is the only design consideration that trumps reliability and performance.

The only thing that troubles me is the trend toward hard integration between the filesystem and the volume manager. I think that Linux needs a storage summit where players like Oracle, EMC, and IBM can hash out a common storage layer that exposes a structured logical storage model to client filesystems. This is necessary for virtualization as well as maintainability and quality.

More comments once I read up on this particular filesystem...

Reply Parent Score: 3

RE[2]: Heh yeah...
by SEJeff on Sat 28th Jul 2007 03:00 in reply to "RE: Heh yeah..."
SEJeff Member since:
2005-11-05

What is wrong with Linux's volume manager? It was modelled pretty much verbatim after HP-UX's volume manager (even the same command line flags). Linux takes the best things from every version of Unix and combines them into one. Linux.

What is wrong with it? Daniel Phillips wrote the LVMv1 implementation and agreed it sucked. LVMv2 and Device Mapper actually aren't that bad.

Reply Parent Score: 1

RE[2]: Heh yeah...
by sbergman27 on Sat 28th Jul 2007 03:09 in reply to "RE: Heh yeah..."
sbergman27 Member since:
2005-07-24

What do you think needs to be overhauled in LVM2? My big gripe is not so much LVM2 as the lack of good userland tools that bring the administration of LVM2, Ext3, RAID, and disk partitions together. There is no reason that, with only the existing layers as they are right now, that ZFS should be able to show us up so badly in manageability. Single, simple, commands should be able to accomplish things that now require many invocations of disparate tools.

If I decide to split up an LVM2 lv, I should be able to just say: split this lv into 2 lv's of these sizes and have everything just happen. I should not have to unmount the filesystem, fsck -f it, resize it with resize2fs, shrink the lv with lvresize, create a new lv with the freed up space, format it, and mount it, all the while hoping that "120G" means exactly the same thing to resize2fs as it does to lvresize. And that is a simple operation that does not involve RAID, physical volumes, and disk partitions, where things get *really* complicated and prone to error.

All the infrastructure is there to do it. But the userland tools always seem just out of reach.

Edited 2007-07-28 03:12

Reply Parent Score: 5