Btrfs merged for 2.6.29
It seems likely that the squashfs filesystem (a read-only filesystem used
on embedded systems and live CDs) will also go in; as Andrew Morton put it: "We've long needed a filesystem
named after a vegetable.
"
Posted Jan 9, 2009 23:13 UTC (Fri)
by flewellyn (subscriber, #5047)
[Link] (2 responses)
Posted Jan 9, 2009 23:52 UTC (Fri)
by horen (guest, #2514)
[Link] (1 responses)
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.
Posted Jan 12, 2009 19:19 UTC (Mon)
by Tara_Li (guest, #26706)
[Link]
Posted Jan 10, 2009 1:18 UTC (Sat)
by kjp (guest, #39639)
[Link] (10 responses)
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.
Posted Jan 10, 2009 1:32 UTC (Sat)
by dlang (guest, #313)
[Link]
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)
Posted Jan 10, 2009 2:11 UTC (Sat)
by qu1j0t3 (guest, #25786)
[Link]
Posted Jan 10, 2009 3:26 UTC (Sat)
by paravoid (subscriber, #32869)
[Link] (4 responses)
Oracle needs advanced filesystem features and stability.
If you think about it, it makes sense.
Posted Jan 10, 2009 7:19 UTC (Sat)
by drag (guest, #31333)
[Link] (3 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...
Posted Jan 10, 2009 11:48 UTC (Sat)
by Duncan (guest, #6647)
[Link] (2 responses)
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.
Posted Jan 12, 2009 9:23 UTC (Mon)
by hensema (guest, #980)
[Link] (1 responses)
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.
Posted Jan 12, 2009 10:08 UTC (Mon)
by dlang (guest, #313)
[Link]
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.
Posted Jan 10, 2009 12:32 UTC (Sat)
by epa (subscriber, #39769)
[Link]
Posted Jan 10, 2009 16:07 UTC (Sat)
by rmini (subscriber, #4991)
[Link]
Posted Jan 11, 2009 13:02 UTC (Sun)
by herodiade (guest, #52755)
[Link]
o There's more Oracle products than their famous database. Some of them are relying on the underlying filesystems performances.
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.
Posted Jan 10, 2009 10:19 UTC (Sat)
by petegn (guest, #847)
[Link] (6 responses)
Posted Jan 10, 2009 10:33 UTC (Sat)
by MisterIO (guest, #36192)
[Link] (5 responses)
Posted Jan 10, 2009 13:53 UTC (Sat)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Jan 10, 2009 16:38 UTC (Sat)
by elanthis (guest, #6227)
[Link] (2 responses)
btrfs?! ^___^ ext2/3 == !@#$ >:-( reiserfs?????
Posted Jan 10, 2009 17:08 UTC (Sat)
by Kit (guest, #55925)
[Link] (1 responses)
Posted Jan 10, 2009 20:35 UTC (Sat)
by man_ls (guest, #15091)
[Link]
Posted Jan 10, 2009 19:59 UTC (Sat)
by vblum (guest, #1151)
[Link]
Posted Jan 10, 2009 17:21 UTC (Sat)
by Felix_the_Mac (guest, #32242)
[Link] (1 responses)
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?
Posted Jan 11, 2009 12:08 UTC (Sun)
by csamuel (✭ supporter ✭, #2624)
[Link]
Btrfs merged for 2.6.29
tasty kernel."
Btrfs merged for 2.6.29
Btrfs merged for 2.6.29
nice, as that looks like a promising area to go.
Btrfs merged for 2.6.29
Btrfs merged for 2.6.29
the competition is ZFS
Btrfs merged for 2.6.29
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.
Btrfs merged for 2.6.29
Btrfs merged for 2.6.29
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.Btrfs merged for 2.6.29
Btrfs merged for 2.6.29
DBMSes hardly use the filesystem
Btrfs merged for 2.6.29
Btrfs merged for 2.6.29
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...
Btrfs merged for 2.6.29
Btrfs merged for 2.6.29
Btrfs merged for 2.6.29
Btrfs merged for 2.6.29
Btrfs merged for 2.6.29
Your comment made me parse elanthis' comment and you are definitely right. Thanks for the laugh!
LOL!!!!!!1111ONE
Btrfs merged for 2.6.29
BtrFs-dev?
That would seem sensible, especially if it allows more freedom in altering APIs etc.
BtrFs-dev?