LWN: Comments on "Btrfs merged for 2.6.29"

Btrfs merged for 2.6.29

Tara_Li — Mon, 12 Jan 2009 19:19:06 +0000

I wonder if the LZMA patches for squashfs made it in too - it would be
nice, as that looks like a promising area to go.

Btrfs merged for 2.6.29

dlang — Mon, 12 Jan 2009 10:08:13 +0000

the fact that the linux raid code isn't suitable for most raid hardware is true, but I disagree with the rest of your points.

most 'hardware' raid cards don't support raid level migration, in fact most don't even support raid resizing (wihc MD does support)

MD does support swapping disks (it doesn't do it automagicly, but you can remove and replace drives in a MD array just fine)

I would be surprised to see linux running on a raid card.

but I would not be surprised to see linux running on a external raid box. the type of thing that allows you to connect a bunch of SATA drives to it and exports the results as a single drive via SCSI or FC.

for this to work well the target mode will need to get into the kernel and get well tested first.

Btrfs merged for 2.6.29

hensema — Mon, 12 Jan 2009 09:23:59 +0000

The Linux md code probably isn't going to be use by any raid vendor anytime soon. It just lacks features needed in serious raid systems, such as online raid level migration and (good?) support for hot swappable disks.

Also, support for battery backed write-through cache may or may not be needed at the md/raid level, I don't know.

Anyway, the linux md disk format may or may not be suitable to raid vendors to use on disks. The linux md code may or may not be suitable to be used in hardware raid implementations.

I think it's highly unlikely linux md code will find its way into hardware raid implementations.

Btrfs merged for 2.6.29

herodiade — Sun, 11 Jan 2009 13:02:00 +0000

Oracle do have plenty of good reasons for this, just to name a few:

o There's more Oracle products than their famous database. Some of them are relying on the underlying filesystems performances.
o Oracle do sells and support Linux already. So they already have to officially support filesystems, and to have experts able to improve/fix filesystems. They may find economically relevant, in the long run, to have one filesystem they know perfectly which covers all moderns use cases for their customers, and which is well designed for robustness (ie. to work around modern storages deficiencies).
o I don't about you, but, as a sysadmin, until now I would hardly choose to deploy "Oracle Linux" because I had serious doubts about their expertise there (compared to, say, Red Hat). The huge momentum around btrfs shows me that Oracle is serious about Linux things. If anything, this is an efficient promotional decision (and two fulltime developers is not a high price for this, I believe).
o Databases do not sells as single, isolated, products. They are to be used in larger datacenter setups, where you may find app servers, backup servers, web servers, etc. using the database. Databases are linked to the whole ecosystem. And when your ecosystem is built around Microsoft products, their own database product (SQL Server) has an edge. If, compelled by shinny ZFS features, your built an ecosystem around Sun/Solaris, you may also consider using their own database product (MySQL), and so on.

This is not an imperatively coupled choice indeed, but your internal expertise (sysadmins, developers, tools) will grow toward your infrastructure (including operating system) choices. Those choices will already bring you commercial contacts, and loyalty incentives (discounts...). You will already have paid support...

So yes, Oracle has interest in making Linux (which is - their own distribution anyway - also an official Oracle product), an attractive, compelling option, even if this does not benefits their main database product so much ; if anything to counter Microsoft and Sun in DC.

BtrFs-dev?

csamuel — Sun, 11 Jan 2009 12:08:50 +0000

I've not seen anything in the git repository to indicate this.

LOL!!!!!!1111ONE

man_ls — Sat, 10 Jan 2009 20:35:41 +0000

Your comment made me parse elanthis' comment and you are definitely right. Thanks for the laugh!

Btrfs merged for 2.6.29

vblum — Sat, 10 Jan 2009 19:59:57 +0000

I liked the capital That in the middle of it all. What a beautiful fork in the stream (if you take it as the continuation from before, it makes sense, if you take it as the beginning of a new sentence, it does also ... That pete!)

BtrFs-dev?

Felix_the_Mac — Sat, 10 Jan 2009 17:21:35 +0000

Glad to see this go in sooner rather than later (as long as nobody uses it as an excuse 'We can't change/fix that now since it's already been merged' - I am sure that will not happen).

Is it being merged as Btrfs-dev?
That would seem sensible, especially if it allows more freedom in altering APIs etc.

Btrfs merged for 2.6.29

Kit — Sat, 10 Jan 2009 17:08:04 +0000

I'm not so sure, that actually made more sense to me...

Btrfs merged for 2.6.29

elanthis — Sat, 10 Jan 2009 16:38:54 +0000

It could be worse. Imagine that if instead of using no punctuation he instead used almost all punctuation:

btrfs?! ^___^ ext2/3 == !@#$ >:-( reiserfs?????

Btrfs merged for 2.6.29

rmini — Sat, 10 Jan 2009 16:07:01 +0000

Oracle sells a lot more software than just their RDBMS these days, and they don't store everything in the RDBMS. So the benefit they'd derive from a fast and reliable filesystem on a platform that isn't controlled by a competitor is pretty clear in those cases.

Btrfs merged for 2.6.29

nix — Sat, 10 Jan 2009 13:53:03 +0000

Stream of incoherence.

DBMSes hardly use the filesystem

epa — Sat, 10 Jan 2009 12:32:07 +0000

RDBMSes like Oracle implement their own... well, their own pretty much everything. With modern OSes there is little performance advantage to putting your database on a raw partition, so you create a huge file, but that's about as far as filesystem use goes. The DBMS will typically have its own page cache and even its own internal process scheduling. A Unix filesystem isn't designed for indexing lots of fixed-size 'rows'.

Btrfs merged for 2.6.29

Duncan — Sat, 10 Jan 2009 11:48:16 +0000

So they took the special-FS-for-our-database approach before and have decided to abandon it for mainstream incorporation. The exact reasons I don't know...

One likely reason is that they've seen the "many eyes and many platforms" effect in action.

Consider any of the hardware RAID vendors out there, for instance, and the fact that such authorities as O'Reilly's RAID book consider the kernel's md/RAID a better choice in many cases, because of the degree to which it has been debugged and optimized due to the vast number of folks using it in all /sorts/ of strange corner-cases on all manner of hardware -- it has had FAR FAR more testing on FAR FAR more exotic hardware in FAR FAR more strange and exotic use cases than any proprietary hardware RAID vendor could ever even dream about.

There's simply no replacing that. It thus stands to reason that if they want the absolute best, most stable foundation they could possibly come up with for data storage and access, there's simply no possible substitute for mainline Linux code. It'll be ported to all manner of different hardware platforms and instituted in all sorts of different corner-cases besides the single-use Oracle DB, thus exposing all sorts of exotic bugs, now, while still under development, that would otherwise not appear until years later, after the API and on-hardware format would have long since hardened, making it difficult or impossible to fix as effectively as they'll be able to do now, while it's still under development. It's that sort of QA they're now going to get for free, that it's simply impossible to buy, no matter how many millions of dollars they throw at testing.

If btrfs ever gets anything even close to as popular as it looks like it could, given that currently it's /the/ solution given as the successor to ext2/3/4, with all sorts of people running it as their general purpose fs at virtually all levels, well, you give me a plausible scenario under which Oracle could possibly get a better, more well tested on every conceivable computing device under the sun, storage foundation. Sure, it'll take a few years to get there, but there's simply no plausibly better alternative. All the while, they get loads of community goodwill for sponsoring the thing, while actually putting way less into development than if they were trying to keep it proprietary. They're not Sun, and this isn't zfs (tho zfs is open, just, apparently deliberately, not Linux/GPL license compatible).

Meanwhile, while we're on the subject, anybody (presumably kernel folks) have any idea to what degree the hardware RAID folks may now be embedding Linux kernel md/RAID for their hardware RAID? One would think that'd be the way to go there, as well, for much the same reason. I know some of the NAS hardware is Linux based and can run OpenWRT, for instance, but I have no idea how widespread it is, or whether hardware RAID cards, etc, have anything like a similar level of embedded Linux penetration.

Btrfs merged for 2.6.29

MisterIO — Sat, 10 Jan 2009 10:33:54 +0000

Stream of consciousness?

Btrfs merged for 2.6.29

petegn — Sat, 10 Jan 2009 10:19:48 +0000

At last another filesystem now maybe another nail in the coffin of that dreaded Ext stuff nothing has ever caused so much hassle as darn Ext 2 and 3 aint much better just a pity That reiserfs has not gotten on futher but still it beats the crap outta ext* stuff

Btrfs merged for 2.6.29

drag — Sat, 10 Jan 2009 07:19:57 +0000

Well OCFSv1 was Oracle/RAC-specific file system... however OCFSv2 is general purpose cluster-aware FS like Redhat's GFS is.

So they took the special-FS-for-our-database approach before and have decided to abandon it for mainstream incorporation. The exact reasons I don't know...

Btrfs merged for 2.6.29

paravoid — Sat, 10 Jan 2009 03:26:50 +0000

For a company as big as Oracle, it makes sense to devote people to research and work on filesystems on Linux. Currently there is just one AFAIK and perhaps not even full-time working on btrfs.

Oracle needs advanced filesystem features and stability.
Even if that particular work inspires a third-party to write a new filesystem that's better than their own, they will still be gaining.

If you think about it, it makes sense.

the competition is ZFS

qu1j0t3 — Sat, 10 Jan 2009 02:11:05 +0000

'nuff said

Btrfs merged for 2.6.29

dlang — Sat, 10 Jan 2009 01:32:11 +0000

I predict that it will be a long time (probably several years) before Oracle recommends btrfs be used for production databases.

it's still under heavy development (many features not yet implemented)

it's just getting to where it can get a lot of testers (not that many people download and install out-of-tree code)

even after the developers and community see it as stable, oracle will still need to stress test it and as a company gain confidence in it.

An official recommendation from Oracle won't happen until they are absolutly sure that it isn't going to eat data, it won't matter how much faster it is in the meantime (other then Oracle possibly allocating developer time to work on it)

Btrfs merged for 2.6.29

kjp — Sat, 10 Jan 2009 01:18:07 +0000

I'm wondering what oracles strategy is with this. Is this going to be their recommended storage layer for their databases? If so... how much specialized api will eventually go in?

What I don't get is oracle is already almost an os.. it can use raw partitions and completely controls its file format so it can use any check summing and journaling features it wants.

I am cautiously optimistic about something being more user friendly w.r.t. raid management for home users. I would say business users can just drop some nas's in pretty easily these days though.

Btrfs merged for 2.6.29

horen — Fri, 09 Jan 2009 23:52:27 +0000

Harvey Harrison said: "I always preferred my squash with butter, it appears 2.6.30 will be a very tasty kernel."

Best eaten after an hour of playing squash.

Btrfs merged for 2.6.29

flewellyn — Fri, 09 Jan 2009 23:13:21 +0000

Further down the thread, Harvey Harrison said: "I always preferred my squash with butter, it appears 2.6.30 will be a very
tasty kernel."