×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A Short History of Btrfs

Soulskill posted more than 4 years ago | from the new-and-shiny dept.

Data Storage 241

diegocgteleline.es writes "Valerie Aurora, a Linux file system developer and ex-ZFS designer, has posted an article with great insight on how Btrfs, the file system that will replace Ext4, was created and how it works. Quoting: 'When it comes to file systems, it's hard to tell truth from rumor from vile slander: the code is so complex, the personalities are so exaggerated, and the users are so angry when they lose their data. You can't even settle things with a battle of the benchmarks: file system workloads vary so wildly that you can make a plausible argument for why any benchmark is either totally irrelevant or crucially important. ... we'll take a behind-the-scenes look at the design and development of Btrfs on many levels — technical, political, personal — and trace it from its origins at a workshop to its current position as Linus's root file system.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

241 comments

oh wee sun's sloppy seconds. (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#28907281)

So, let's get this right. the BEST that Linux can get is a murderer [wikipedia.org] and a SUN REJECT? lol quality.

Excuse me, I think I'll stick to a REAL OS [opensolaris.com] that features a REAL FS [wikipedia.org] backed by a REAL company! [oracle.com]

mod parent up (-1, Troll)

Anonymous Coward | more than 4 years ago | (#28907413)

Parent is truthful. Eat it linuxtards!

Re:oh wee sun's sloppy seconds. (2, Funny)

Anonymous Coward | more than 4 years ago | (#28907437)

Will you also be enjoying your media in REAL PLAYER [real.com]?

Re:oh wee sun's sloppy seconds. (2, Insightful)

mysidia (191772) | more than 4 years ago | (#28907609)

That argument isn't actually based on the technical merits, and thus doesn't make any sense..

Just because a Real OS [microsoft.com] features a Real FS [wikipedia.org] backed up by a real company [microsoft.com], doesn't necessarily mean the FS or OS are any good on technical merits compared to a REAL project [linux.org] licensed under a REAL free software [gnu.org] license [gnu.org] backed up by a REAL community and supported by a REAL foundation [linuxfoundation.org].

Re:oh wee sun's sloppy seconds. (1)

ioshhdflwuegfh (1067182) | more than 4 years ago | (#28908055)

That argument isn't actually based on the technical merits, and thus doesn't make any sense..

So what's your point? that ext4 is better than ZFS on technical merits!?

Re:oh wee sun's sloppy seconds. (-1, Offtopic)

Runaway1956 (1322357) | more than 4 years ago | (#28908107)

Let us all get this straight. AC would reject any and all medical knowledge that resulted from experimentation by the Nazi's during the second world war. Going a step further, he might wish to have any medical knowledge gained by the allies during WW2 purged from human knowledge. After all, such knowledge is "tainted", because it was motivated by violence.

If it can't be patented and commercialized it can't be much good.

Don't anyone inform AC that there is no patent on his arse, or his reproductive organs. He'll be removing them as "junk".

First shill! (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#28907295)

OHAI! I used Micrososft Windows Live(tm) Visual Team System Express Enterprise Vista Ultimate Edition (R) to get this first post!11!one

Re:First shill! (0)

Anonymous Coward | more than 4 years ago | (#28908125)

Deliberate? I wonder...

Looks promising (5, Informative)

PhunkySchtuff (208108) | more than 4 years ago | (#28907305)

This looks like a promising filesystem - as ZFS on linux is, at present, doomed to die an ugly death, btrfs looks to address a lot of the shortcomings of other filesystems and bring a clean, modern fs to linux. It goes beyond ZFS in some areas too, such as being able to efficiently shrink a filesystem, and keeps a lot of the cool things that ZFS made popular, such as Copy-On-Write.

It looks like Btrfs also addresses some decisions that were made with the direction that ZFS would be going in, or how it would handle certain problems that now with hindsight behind the developers, they possibly would have done things differently.

Apple are really struggling with ZFS, with it being announced as a feature in early betas of both Leopard (10.5) and Snow Leopard (10.6), as well as being there in a very limited form in Tiger (10.4) - maybe development on Btrfs will leapfrog ZFS for consumer-grade hardware and Apple can finally look at deprecating HFS.

Re:Looks promising (2, Informative)

dirtyhippie (259852) | more than 4 years ago | (#28907617)

... but btrfs is GPL. Therefore Apple can't use it, unless perhaps they are able to work out licensing from Oracle.

Re:Looks promising (0)

Anonymous Coward | more than 4 years ago | (#28907661)

... but btrfs is GPL. Therefore Apple can't use it

sorry, i don't get it.

Apple already uses gpl software. did you meant "won't use" instead of "can't use"?

Re:Looks promising (2, Informative)

aj50 (789101) | more than 4 years ago | (#28907853)

I think that since it's a part of the kernel, it would count as a derivative work which would mean the whole kernel would have to be GPL'd as well.

This is similar to the reason that ZFS can't just be ported to linux, the code is under CDDL which is incompatible with GPL.

Re:Looks promising (5, Informative)

PhunkySchtuff (208108) | more than 4 years ago | (#28907703)

Apple has, and does, use GPL'd code and complies with the terms of the license.

Take, for example, WebKit, which is a fork of KHTML. It's now released as LGPL:
http://webkit.org/coding/lgpl-license.html [webkit.org]

This code powers the browser that Apple ship with Mac OS X, Safari - which is arguably one of the most important pieces of code in the whole OS.

As a result of it's quality, speed and standards adherence, it's now used by companies like Nokia and Adobe...

Re:Looks promising (1, Informative)

Anonymous Coward | more than 4 years ago | (#28907733)

A browser is probably easier separated from the rest of the OS than a filesystem. (Well, i'm not talking about M$IE).

Re:Looks promising (1)

BitZtream (692029) | more than 4 years ago | (#28907951)

IE is easy as shit to seperate from the OS. Delete iexplore.exe.

The rendering engine on the other hand, isn't. It is used by MANY apps, this applies to Windows, OS X, and lots of other OSes.

Re:Looks promising (0)

Anonymous Coward | more than 4 years ago | (#28908029)

I see what you did there.

Re:Looks promising (3, Informative)

TheRaven64 (641858) | more than 4 years ago | (#28908077)

The GPL and LGPL are very different. The LGPL does not affect any code beyond that originally covered by the license. You can link LGPL'd WebKit against proprietary-licensed Safari with no problems.

Apple also ship GPL'd software like bash, but they don't link it against any of their own code.

Linking GPL'd code into the kernel would require the rest of the kernel to be released under a license that places no restrictions that are not found in the GPL. That's not a problem for Apple's code; they own the copyright and they can release it under any license they choose. It would be a massive problem for third-party components. DTrace, for example, is heavily integrated into OS X's Instruments developer app and is CDDL (GPL-incompatible). Various drivers are under whatever license the manufacturers want, and are mostly GPL-incompatible. A GPL'd component would need to be very compelling to make Apple rewrite DTrace, most of their drivers, and a lot of other components. Btrfs is not this compelling. Even if Btrfs were sufficiently good, it would take less effort for them to just completely rewrite it than to rewrite all of the GPL-incompatible components.

Re:Looks promising (1)

ppc_digger (961188) | more than 4 years ago | (#28908135)

Correct me if I'm wrong, but I thought runtime linking wasn't covered by the GPL. Otherwise, you wouldn't be able to use bash in OpenSolaris, as its libc is CDDLd.

Re:Looks promising (1)

Shoe Puppet (1557239) | more than 4 years ago | (#28908269)

But in this case bash links against libc, not the other way. AFAIR, GPL programs can themselves still link against anything else irrespective of the library's license.

Re:Looks promising (1)

TheRaven64 (641858) | more than 4 years ago | (#28908275)

Correct me if I'm wrong, but I thought runtime linking wasn't covered by the GPL.

Okay, you are wrong.

Otherwise, you wouldn't be able to use bash in OpenSolaris, as its libc is CDDLd.

The GPL contains a special exemption for linking against system libraries. This would not apply to linking in the kernel.

Re:Looks promising (1, Insightful)

Anonymous Coward | more than 4 years ago | (#28907713)

What, really? Who the fuck writes a file system implementation in GPL!? That's as bad as Sun!

Re:Looks promising (1)

Runaway1956 (1322357) | more than 4 years ago | (#28908137)

Someone has little understanding of the GPL. Apple need not open source it's kernel in order to use a kernel module. Things might be simpler if MacOS were GPL'd, but the use of GPL'd code within the OS is quite possible. As someone else already points out, Microsoft makes use of GPL'd code.

Re:Looks promising (1)

TheRaven64 (641858) | more than 4 years ago | (#28907725)

Apple are really struggling with ZFS, with it being announced as a feature in early betas of both Leopard (10.5) and Snow Leopard (10.6), as well as being there in a very limited form in Tiger (10.4)

It's also available on 10.5/6 [macosforge.org] with some limitations. It's not marketed because it's not quite feature-complete, but it works in OS X and on FreeBSD. There's almost no chance of Apple adopting btrfs in the OS X kernel though, because the GPL is incompatible with the license of a number of other components.

LVM (0)

Anonymous Coward | more than 4 years ago | (#28908179)

This looks like a promising filesystem - as ZFS on linux is, at present, doomed to die an ugly death, btrfs looks to address a lot of the shortcomings of other filesystems and bring a clean, modern fs to linux.

If I have to put up with the LVM I'm not interested. It was a great idea back in the early '90s, but we really have to move on. Personally I like ZFS' idea of pools.

It goes beyond ZFS in some areas too, such as being able to efficiently shrink a filesystem, and keeps a lot of the cool things that ZFS made popular, such as Copy-On-Write.

The lack of pool shrinking is an acknowledged and documented feature request (as is going from a single- to dual-parity configuration on the fly). They're working on it, but if it was really desired by a lot of large customers, it would have been a higher priority (Sun is often "coin operated" on things like this). They've also publicly talked about de-dupe functionality.

Apple are really struggling with ZFS ...

Given Apple's secrecy, how do you know what's happening with ZFS in Apple? ZFS is very portable, shown by the fact that the developer who got ZFS onto FreeBSD (Pawel Jakub Dawidek) had basic things working in only ten days:

http://blogs.sun.com/eschrock/entry/zfs_on_freebsd

Given that it went into OpenSolaris on 2005-11-16 and commited into FreeBSD on 2007-04-06 (15 months later) by a single developer (?), I would hazard to guess that it's not a technical issue that's preventing Apple from having it.

total gay (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#28907311)

i've never lost a file on NTFS, but i have on linux file systems

Re:total gay (0, Offtopic)

Calydor (739835) | more than 4 years ago | (#28907337)

Well good for you. I've had an entire HD decide that moving files to another drive, while deleting other files, meant that I wanted the entire filesystem hosed.

Re:total gay (0)

Anonymous Coward | more than 4 years ago | (#28907361)

Since you didn't specify what filesystem you were using I'll just assume it was NTFS.

Re:total gay (1)

pdusen (1146399) | more than 4 years ago | (#28907637)

I've lost files on lots of different systems, including NTFS and ext3 and the kitchen sink. It's rarely the fault of the filesystem itself.

Re:total gay (2, Insightful)

Runaway1956 (1322357) | more than 4 years ago | (#28908191)

I wish the parent hadn't been modded down. He makes a point that should be addressed.

I've lost data on every file system that I've ever used, including NTFS, and the highly touted ReiserFS. Nothing guarantees the security of your data. The nearest you can come to data security, is to backup, backup, and backup again. Those people and organizations that keep regular backups seldom lose data. However, even those people can lose data in the event of a physical disaster (fire, flood, theft, being hit by a humongous meteorite) which is why off-site backups are important.

That said - IMHO, a journaling file system is an important first step to data security. NTFS and Ext3 are about equal, in my experience. Turning off caching features is an important second step. A power outage before data is written to disk, and/or while data is being written results in corruption in all current file systems. The important thing is, if data is mission critical, you want it written IMMEDIATELY, not floating around in RAM.

And, finally, you NEED redundant backups. Anyone who fails to make backups WILL LOSE data, eventually.

Linus', not Linus's. (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#28907327)

It's not that hard!

Re:Linus', not Linus's. (1, Offtopic)

WillKemp (1338605) | more than 4 years ago | (#28907421)

It's not that hard!

No, it's not - but you're wrong. :"Linus's" is correct. The 's' after the apostrophe only gets dropped in plurals.

Re:Linus', not Linus's. (1)

Paul Jakma (2677) | more than 4 years ago | (#28907467)

It's fine to drop the 2nd s, at least in British english. Though, there doesn't seem to be any hard and fast rule..

Re:Linus', not Linus's. (2, Interesting)

WillKemp (1338605) | more than 4 years ago | (#28907535)

There doesn't seem to be any hard and fast rules about anything in British english! ;-)

In Fowler's Modern English Usage, which is generally considered to be the bible of english usage by UK journalists and writers, there's an article called "Possessive Puzzles". In that, he says it was "formerly customary" to drop the last 's', but not any more.

If it was formerly customary in Fowler's day, i reckon it must be well and truly archaic now.

Re:Linus', not Linus's. (1)

compro01 (777531) | more than 4 years ago | (#28907495)

Both are correct, depending on who you ask. It's a British English vs. American English thing. Up here in Canada, just the apostrophe seems to be the preferred form.

Re:Linus', not Linus's. (1)

satoshi1 (794000) | more than 4 years ago | (#28907531)

I was taught in my American schools (grade school, even) that you drop the second S on names that end in S. "Linus'"is how I was taught.

Re:Linus', not Linus's. (1)

WillKemp (1338605) | more than 4 years ago | (#28907549)

That's interesting. I think in Britain the preferred form of anything is to put an apostrophe anywhere it can possibly be put and drop any syllables that can possibly be dropped.

It seems the version with the final 's' is more modern than the version without it. Considering their efforts to update the language, it's perhaps not entirely surprising that the Americans prefer the more modern form.

Re:Linus', not Linus's. (1, Funny)

Anonymous Coward | more than 4 years ago | (#28907635)

gor blimey guvnor you aint arf stereotypin us brits'.

Re:Linus', not Linus's. (0)

Anonymous Coward | more than 4 years ago | (#28907655)

Gut feelings are no good at all when it comes to language. USians wouldn't have much trouble talking to Edgar Allen Poe, but Brits would have a very hard time hanging with John Keats.

Re:Linus', not Linus's. (-1, Offtopic)

Runaway1956 (1322357) | more than 4 years ago | (#28908225)

The Revelation of Saint Slasher Dotter, chapter 12, verse 19, says, "Verily, in the deepest dungeons, there is a place reserved for grammar nazis. There shall be weeping and gnashing of teeth, as the grus gnaw upon the bones of the grammar nazis for all time. Lo, there shall be no death, no resets or restarts for the grammar nazis, nor will there be relief for them in the lakes of fire. Beware, grammar nazi, or you shall feed the gru!"

So, (2, Insightful)

Josh04 (1596071) | more than 4 years ago | (#28907347)

Is this ever going to replace ext4? The ext series of file systems are 'good enough' for most people, so unless it has some epic benchmarks I can't imagine a huge rush to reformat. Maybe that's what drives file system programmers insane. The knowledge that for the most part, it's going nowhere. FAT12 is still in use, for Christ's sake.

Re:So, (5, Interesting)

PhunkySchtuff (208108) | more than 4 years ago | (#28907391)

Aside from Copy on Write, one other feature that this filesystem has that I would consider essential in a modern filesystem is full checksumming. As drives get larger and larger, the chance of a random undetected error on write increases and having full checksums on every block of data that gets written to the drive means that when something is written, I know it's written. It also means that when I read something back from the disk, I know that it was the data that was put there and didn't get silently corrupted by the [sata controller | dodgy cable | cosmic rays] on the way to the disk and back.

Re:So, (1)

am 2k (217885) | more than 4 years ago | (#28907669)

Doesn't help against RAM issues though, because those will just get into the checksum as well.

Re:So, (2, Insightful)

aj50 (789101) | more than 4 years ago | (#28907695)

I had this exact problem very recently.

If my data was important, I should have been using ECC RAM.

Re:So, (2, Interesting)

borizz (1023175) | more than 4 years ago | (#28907909)

Odds are the checksum then won't match anymore and you'll be notified. It's better than silent corruption.

Re:So, (1)

BrentH (1154987) | more than 4 years ago | (#28907719)

What I'd like to know if btrfs does continuous checking of these checksums, preferably when there's not a lot of activity. Checksums are an excellent idea, but unless you check your files every now and again (automagically), you still don't know anything.

Re:So, (4, Informative)

PhunkySchtuff (208108) | more than 4 years ago | (#28907795)

What you do know is that when you read a block of data back from the disk, that block is what was supposed to be written to the disk.

If a file that is never read is corrupted somehow, then you will only discover that corruption when you read the file.

Having checksums is very good if you have a RAID-1 mirror. With full block checksums, you can read each half of the mirror and if there is an error, you know which one is correct, and which one isn't. At present, if a RAID-1 mirror has a soft error like this, due to corruption, you don't know which half of the mirror is actually correct.

With ZFS, for instance, you can create a 2-disk RAID-1 mirror and then use dd to write zeroes to one half of the mirror, at the raw device level (ie, bypassing the filesystem layer) and when you go to read that data back from the mirror, ZFS knows that it's invalid and instead uses the other side of the mirror. It then has an option to resilver the mirror and write the valid data back to the broken half, if you so want.

Re:So, (1)

swilver (617741) | more than 4 years ago | (#28907887)

Surface scans with SMART already catch these problems (blocks going bad).

There's no need to check for single bit errors in files / blocks themselves as that's never gonna happen when the block was either fully error corrected by the drive or simply not returned at all due to a checksum failure (in which case it's a bad block).

If a checksum DOES fail in such a setup (with the filesystem doing the check), it is actually more likely that it was damaged in memory (which could be fixed by simply reading it again). Damage in memory is sinister though as you never know when a (cached) block gets damaged, which could be never or right after the checksumming process declares it "correct".

If you are really worried about these issues, I'd first invest in an ECC capable motherboard and ECC memory.

Re:So, (0)

Anonymous Coward | more than 4 years ago | (#28907995)

incorrect. just last week i helped a customer who suffered exactly
this fate. her drive miswrote the data and did not return a ure on
reread. it just returned bad data. needless to day, it took a long
time to find the true problem. (i have a similar drive which at least
had the decency of returned ure after the block had been flushed
from the cache, but writes appeared to be successful.)

Re:So, (1)

asaul (98023) | more than 4 years ago | (#28908005)

Read the ZFS White Paper. Just because the disk checks its blocks, doesn't prevent other sources corrupting, overwritting or generally tampering with data. For example, say your el cheapo fibre card corrupts one bit in every 2 billion writes - on disk its fine, SMART never sees it, it never complains. When ZFS reads the corrupted blocks it will see a checksum error, and repair if necessary.

It also doesn't cover the case of deliberate/administrative corruption such as accidentally overwriting the wrong disk etc. With a normal mirrored device you could read off either side, it simply returns the data and the data would be blockwise correct. With ZFS again you would see failures and if possible it could correct. In fact this is how the early demonstrations of ZFS would work - simply using dd to clobber one half of the mirror and watching it fix itself.

And for ZFS I would absoultely recommend ECC memory. For the exact case that I had a blown capacitor cause random memory errors on a motherboard I had, and any new or modified file would throw up checksum errors when re-read. Without ZFS I probably would not have known until I got some weird panics from corrupted metadata or something.

Re:So, (1)

swilver (617741) | more than 4 years ago | (#28907837)

If the checksumming is done by the CPU, on non-ECC memory, you might as well not use it as the data is most likely going to get corrupted at the source (your memory) not in transfer.

The biggest source of bit errors at the moment is non-ECC memory as far as I can tell. Most busses are already protected in some form due to their high-speed nature. Hard drives themselves use many forms of error correction routinely to even read any sane data at all.

On my own system I noticed a problem when copying large amounts of data (which was checksummed in some other fashion) that I'd get about 1 bit error for every 100 GB of data copied. This came up fairly often, and is the reason I now always use mv/cp tools that can do a verify. After I replaced the memory with ECC variants however these tools haven't reported an error since.

Re:So, (1)

borizz (1023175) | more than 4 years ago | (#28907919)

At least with a checksumming FS you'll be notified of the error, even if it happens in RAM. That way you atleast know something is not right.

Re:So, (1)

ioshhdflwuegfh (1067182) | more than 4 years ago | (#28908087)

Aside from Copy on Write, one other feature that this filesystem has that I would consider essential in a modern filesystem is full checksumming. As drives get larger and larger, the chance of a random undetected error on write increases and having full checksums on every block of data that gets written to the drive means that when something is written, I know it's written. It also means that when I read something back from the disk, I know that it was the data that was put there and didn't get silently corrupted by the [sata controller | dodgy cable | cosmic rays] on the way to the disk and back.

You mean like ZFS does it?

Re:So, (1)

PhunkySchtuff (208108) | more than 4 years ago | (#28908117)

Yes, exactly. I'll happily use ZFS wherever it's supported to do so. Btrfs is looking like a promising alternative and looks to be happening on Linux long before ZFS will be.

Re:So, (4, Insightful)

borizz (1023175) | more than 4 years ago | (#28907425)

Snapshots are nice too. Makes stuff like Time Machine and derivatives much more elegant. ZFS has built in RAID support (which, I assume, works on the block level, instead of on the disk level), maybe Btrfs will get this too.

Re:So, (4, Informative)

joib (70841) | more than 4 years ago | (#28907547)


ZFS has built in RAID support (which, I assume, works on the block level, instead of on the disk level), maybe Btrfs will get this too.

Yes, btrfs currently has built-in support for raid 0/1/10, 5 and 6 are under development.

triple-parity RAID (0)

Anonymous Coward | more than 4 years ago | (#28908237)


ZFS has built in RAID support (which, I assume, works on the block level, instead of on the disk level), maybe Btrfs will get this too.

Yes, btrfs currently has built-in support for raid 0/1/10, 5 and 6 are under development.

On a related note, ZFS recently had triple-parity ("RAID-7" ?) added:

http://blogs.sun.com/ahl/entry/triple_parity_raid_z

Re:So, (0)

Anonymous Coward | more than 4 years ago | (#28907975)

ZFS has built in RAID support...maybe Btrfs will get this too.

I would hope not. Software RAID does not belong in the filesystem. Putting it there is a layering violation. Linus would unlikely accept such a ham-fisted implementation.

Re:So, (0)

Anonymous Coward | more than 4 years ago | (#28907427)

Our storage consumption is exponential, so even if you just format *new* drives with Btrfs, it will become a significant player very soon.

Re:So, (1)

Josh04 (1596071) | more than 4 years ago | (#28907507)

It's not about getting devices formatted with it, it's about getting platforms to support it. Will there be a Windows driver for btrfs? Can I put it on an external hard disk and actually be able to use it?

Re:So, (0)

Anonymous Coward | more than 4 years ago | (#28907589)

If that's so, then why did you say "I can't imagine a huge rush to reformat" instead of "I can't imagine many platforms supporting it"?

Re:So, (1)

xororand (860319) | more than 4 years ago | (#28907761)

Waiting for native Windows filesystems is mostly hopeless, backed up by this incomplete list [wikipedia.org]. As far as I know, the Windows IFS development kit is not free, neither as in speech nor as in beer.
A pragmatic solution would be to use virtualization instead of badly rewriting filesystems again and aigan. You'd need a small virtual machine:

  • The VM should contain a minimal Linux setup that shouldn't need than 64 MB disk space, using cramfs or squashfs, like LiveCDs do
  • 64 MB of RAM ought to be more than enough as well.

  • The hostp passes the raw drive/partition that you want to mount through to the VM
  • The filesystem is mounted inside the VM, supporting even LVM2, dm-crypt / LUKS, ... whatever you want.
  • The mounted filesystem gets exported back to Windows via CIFS (SMB successor)

I'm sure one could make this process very easy to use, with a neat GUI to set it up. The VM could run in the background, so that the user only sees its rough status in the GUI.
Maybe there's hope for a fast native solution, as Microsoft just recently released Linux guest drivers for their own virtualization solution under the terms of the GPL2.

Re:So, (2, Informative)

AzureDiamond (1314257) | more than 4 years ago | (#28907901)

As far as I know, the Windows IFS development kit is not free, neither as in speech nor as in beer.

You can download the Windows Driver Kit for free, and that includes the Installable Filesystem Kit headers and libraries and the source code to FASTFAT.SYS, the Windows FAT driver and CDFS.SYS, the ISO9660/Joliet filesystem.

http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx [microsoft.com]

That being said writing a performance filesystem for Windows is much less easy than for Linux.

Re:So, (1)

joib (70841) | more than 4 years ago | (#28907831)

Would would a windows driver be a requirement? I, and presumably many others, currently use ext3 regardless of the existence of a windows driver (such a thing supposedly exists, but I have never needed it). For windows access there is samba, after all (via a virtual machine if it needs to be done on the same piece of HW).

For external drives the situation is indeed slighly different. I typically use either ext3 or ntfs depending on whether I want to access them from windows or not.

Re:So, (1)

zsau (266209) | more than 4 years ago | (#28907611)

People buy new computers often enough. For Btrfs to replace ext4 (I'm still using ext3 and didn't even realise an ext4 had been released!), I think all it will take is for major distributions to change the default file system for new installs. Obviously the number of people who replace existing file systems different ones will be comparatively low.

Re:So, (0)

Anonymous Coward | more than 4 years ago | (#28908311)

Just the name is enough for me. "Butterfly system" goes so well with my "Pink ponies!" theme ^_^

So, what is the status of btrfs? (4, Interesting)

MMC Monster (602931) | more than 4 years ago | (#28907513)

Is it Beta? The fact that Linus runs it as his root fs doesn't tell me much. Now, if you told me that's what he uses for ~/, I would be more impressed.

The important question to me is, how long 'til it gets in the major distributions?

Re:So, what is the status of btrfs? (4, Informative)

joib (70841) | more than 4 years ago | (#28907539)

The important question to me is, how long 'til it gets in the major distributions?

The article predicts a couple of years until it's safe enough as default in new distros.

Re:So, what is the status of btrfs? (5, Interesting)

TheRaven64 (641858) | more than 4 years ago | (#28907775)

Meanwhile, FreeBSD and OpenSolaris are shipping with a version of ZFS that is usable now...

Re:So, what is the status of btrfs? (1, Interesting)

joib (70841) | more than 4 years ago | (#28907801)

Yeah, but those operating systems suck in other ways, so no thanks. I'll get by with ext3/4 and xfs until btrfs is production ready. YMMV.

Re:So, what is the status of btrfs? (1, Flamebait)

TheRaven64 (641858) | more than 4 years ago | (#28907883)

Yeah, but those operating systems suck in other ways

Yes, in a great many of other ways, that somehow can't be put into words...

Re:So, what is the status of btrfs? (5, Informative)

joib (70841) | more than 4 years ago | (#28907979)

Just because a replied to your snarky message with another equally snarky one, doesn't mean I'm not able to put it into words. For instance, a few reasons why I prefer Linux over *BSD or Solaris:

- better package management

- better hw support

- better ISV support

- the uncertain future of Solaris (after all, Sun got bought because they were bleeding red ink left and right, will the Solaris devs escape the inevitable layoffs and Oracle continue pumping money into Solaris development just to try to keep up with Linux?)

- Lack of tier-1 commercial support for *BSD.

- Much larger community

- Better availability of qualified Linux sysadmins

Re:So, what is the status of btrfs? (1)

ioshhdflwuegfh (1067182) | more than 4 years ago | (#28908139)

[...]why I prefer Linux over *BSD or Solaris:
[...]
- better hw support
[...]

To you then file system is not something that supports hardware!?

Re:So, what is the status of btrfs? (4, Informative)

asaul (98023) | more than 4 years ago | (#28908147)

For hardware support it really depends what segment of the market you are arguing about. If you are talking white box, low end mostly self supported stuff then no doubt, Linux wins hands down. But as a sysadmin I find Linux to be the of the most painful platform to work on compared to Solaris or AIX - predominantly because of the lack of standardised, stable and properly supported management interfaces.

Fibre channel support is a joke. Sure, for the most part you can dynamically bring stuff in and out, and udev goes a short way to bringing some consistancy. The problem is when something goes wrong you are left with pretty much just rebooting - messages tell you nothing - is the device there or not? Usable details are buried away in /proc and /sys and typically are only useful for developers. Solaris and AIX had cfgadm/cfgmgr and lsdev and friends to tell you what state things are in or what has happened. There are useful and informative error messages (typically). So far on RHEL 3/4/5 all I ever see is odd octal dumps from drivers when errors occur, and wierd hangs and IO errors when devices get broken. It gets worse as you change fibre drivers and versions. Options which exist in one disappear in others. Vendor drivers add customisations which cause other issues.

The lack of stablity in terms of being able to do things between versions gets me as well. On AIX/Solaris you write a script for Solaris 8, and it just works going forwards to other versions. Solaris 10 changes things a bit, but for the most part you can still poke around the same places or the same way to get info back. In short they tend not to break things that work.

Linux goes the other way - a change is made, and thats that, it seems to be up to you to either track or figure it out. You find yourself having to customise things for many many variations of platform - not just major versions, but minor versions as well. Changes to config file locations, the ways those files are defined etc.

Don't get me wrong, I got into UNIX on Linux and I wont dispute its strength in drivers or community, but that community is not "Enterprise" focused. Its why I use it for my PVR and not my file server. The rapid changes in Linux are why the DVB-T cards I got became supported so quickly after the hardware changed. I get the differences, but its not one size fits all.

Re:So, what is the status of btrfs? (1)

jonaskoelker (922170) | more than 4 years ago | (#28907825)

The article predicts a couple of years until it's safe enough as default in new distros.

It's phrased as an upper bound, "Btrfs will be the default file system on Linux within two years."

Note that it's the prediction of a single person, Valerie Aurora-formerly-Henson, who doesn't try to explain any rationale behind the prediction.

She even says "Check back in two years and see if I got any of these predictions right!" ... So take it with an appropriate amount of salt*, whatever that means to you.

(* please consult your doctor before consuming large amounts of salt if you have high blood pressure or a pre-existing heart condition.)

Re:So, what is the status of btrfs? (0)

Anonymous Coward | more than 4 years ago | (#28907553)

As the article notes, there has been a disk-format change pushed for the 2.6.31 kernel release. I'm not sure if Chris has announced that format to be final. If it is, I think you could consider btrfs in beta from the 2.6.31 release onwards. In its current form, I'd say it's still alpha-code.

As for major distributions, Debian is shipping btrfs-tools in Squeeze (lenny+1). Not that you can use it, since squeeze is still shipping a 2.6.26 kernel. Don't know about other distributions.

Beta, indeed. (1)

Slartibartfast (3395) | more than 4 years ago | (#28907727)

I asked when it would be usable for "people who backed up their data" about a year ago -- which is about how long I've been using it -- and the answer was, "No firm date." If you load up a 2.6.31 kernel, the commits have reached the point where not only shouldn't you see significant on-disk format changes, but that the bulk of non-RAID tweaking to occur is probably performance related. (RAID is coming, but it's only just started.) Grub still doesn't know about btrfs, and that's semi-back-burnered functionality, so in order to get it to boot, you need a /boot partition on something Grub does know about.

Linus runs btrfs, on a spare laptop? (1)

jonaskoelker (922170) | more than 4 years ago | (#28907745)

The fact that Linus runs it as his root fs doesn't tell me much. Now, if you told me that's what he uses for ~/, I would be more impressed.

It gets even worse. FTFA:

Linus Torvalds is using it as his root file system on one of his laptops.

Maybe one of his spares?

I'm speculating, but note that the article doesn't say "his main laptop", which it could, and which would be a better "seal of approval", so it probably would if it was true...

Re:So, what is the status of btrfs? (1)

Enleth (947766) | more than 4 years ago | (#28908041)

"Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies."

  - Linus Torvalds

BTRS vs NILFS (0)

Anonymous Coward | more than 4 years ago | (#28907613)

How do they compare?

LWN -- it should be noted... (1)

Slartibartfast (3395) | more than 4 years ago | (#28907707)

That this is a "service" provided by LWN so that non-subscribers can read premium content; this story would be free for all come Thursday, but apparently "diegocgteleline.es" didn't feel compelled to mention that, that LWN's weekly page is premium content, and that premium content subscribers help LWN stay afloat -- when it's almost gone under a couple times.

Re:LWN -- it should be noted... (1)

joib (70841) | more than 4 years ago | (#28907807)

It's already free; it's from last week's LWN weekly news.

Looks quite robust (1)

Enleth (947766) | more than 4 years ago | (#28907709)

With the COW-enabled b-tree storing everything including metadata and packing it in the same block as the data it describes, the atructure looks quite similar to reiserfs (v3) in terms of error tolerance and recovery. Should this get a tool like the reiserfsck --rebuild-tree, I'm switching - this single feature (well, and some quite sensible performance) is keeping reiserfs on my systems. Saved me a lot of grief several times, when an ext filesystem would be a totally lost cause (or lots of $$$ for a data recovery company), without any built-in utilities, and really no way to write them, that search the entire disk for anything that looks like filesystem metadata and try to make sense of it, even with all superblock structure completely missing and the rest spotted with garbage.

Re:Looks quite robust (1)

physburn (1095481) | more than 4 years ago | (#28907817)

Similar to reiserfs in terms of tolerance. Oh great, thats safe, just don't marry it. :-), Look up reiserfs on slashdot, if you don't get that. Seriously though thanks for all the hard work from Linus developers.

---

Linux [feeddistiller.com] Feed @ Feed Distiller [feeddistiller.com]

Re:Looks quite robust (0)

Anonymous Coward | more than 4 years ago | (#28908223)

...the atructure looks quite similar to...

I feel like that word should mean some combination of "atrocity" and "structure".

Oh great (5, Funny)

teslatug (543527) | more than 4 years ago | (#28907773)

As if fsck wasn't bad enough to use in business talks, now I have to get prepared for btrfsck

Re:Oh great (1, Funny)

Anonymous Coward | more than 4 years ago | (#28907859)

I suddenly feel the urge to create a new fs called buttfs.

Re:Oh great (0)

Anonymous Coward | more than 4 years ago | (#28908209)

so that would be "butter fuck"?

Choice of filesystems... (1)

Bert64 (520050) | more than 4 years ago | (#28907827)

You can't even settle things with a battle of the benchmarks: file system workloads vary so wildly that you can make a plausible argument for why any benchmark is either totally irrelevant or crucially important.

As pointed out, filesystem workloads vary massively, which is why it's good to have a choice of different filesystems which can be chosen based on individual requirements. Only offering a single filesystem like many other OS's do is extremely inefficient. One size does not fit all.

Porn stars (-1, Offtopic)

BitZtream (692029) | more than 4 years ago | (#28907931)

File systems written by porn stars are bound to fail. If this isn't a porn star, a name change is in order.

Yet another "modern" FS without undelete... (1)

redirect 'slash' nil (1078939) | more than 4 years ago | (#28908171)

Allow me, if I may, to open the can of worms here.

Why is it that in 2009 we can't get a filesystem that allows easy undeletion? It all happened to us one time or another: You typed that 'rm' command you shouldn't have, and now your work of the past few hours is gone. If only there was a simple way to undelete those few recent removed files...
We all know that the data is not zeroed on deletion, so why can't we have a File System that (preferably after fs umount) can scan the blocks and retrieve any file whose data blocks have not been overwritten yet, even if it takes a lengthy whole disk surface scan.
Hell, in 1989, I could do just what I described above very easily on the Amiga (granted, it was floppy based, but still...), and I never lost a single file apart from disk errors. I can even do that fairly easily with external tools on NTFS. So Why are all the UNIX filesystems I know (and btrfs is apparently not going to be an exception [mail-archive.com]) such a pain in the butt for undeletion?

Re:Yet another "modern" FS without undelete... (1)

asaul (98023) | more than 4 years ago | (#28908249)

Simple - use ZFS + snapshots. There are tools out there allready that to periodic and rolling snapshots - bad delete, go into the snapshot and copy it back, that easy.

The real trick with undeletion is making sure you dont overwrite the data before you are really sure it doesnt need to undeleted....

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...