|
|
Subscribe / Log in / New account

Btrfs merged for 2.6.29

Btrfs merged for 2.6.29

Posted Jan 10, 2009 3:26 UTC (Sat) by paravoid (subscriber, #32869)
In reply to: Btrfs merged for 2.6.29 by kjp
Parent article: Btrfs merged for 2.6.29

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.


to post comments

Btrfs merged for 2.6.29

Posted Jan 10, 2009 7:19 UTC (Sat) by drag (guest, #31333) [Link] (3 responses)

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

Posted Jan 10, 2009 11:48 UTC (Sat) by Duncan (guest, #6647) [Link] (2 responses)

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

Posted Jan 12, 2009 9:23 UTC (Mon) by hensema (guest, #980) [Link] (1 responses)

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

Posted Jan 12, 2009 10:08 UTC (Mon) by dlang (guest, #313) [Link]

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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds