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.
Posted Jan 10, 2009 7:19 UTC (Sat) by drag (subscriber, #31333)
[Link]
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]
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]
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 (✭ supporter ✭, #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.