Beta
×

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!

Btrfs Is Getting There, But Not Quite Ready For Production

timothy posted about a year and a half ago | from the delicious-on-popcrnfs dept.

Data Storage 268

An anonymous reader writes "Btrfs is the next-gen filesystem for Linux, likely to replace ext3 and ext4 in coming years. Btrfs offers many compelling new features and development proceeds apace, but many users still aren't sure whether it's 'ready enough' to entrust their data to. Anchor, a webhosting company, reports on trying it out, with mixed feelings. Their opinion: worth a look-in for most systems, but too risky for frontline production servers. The writeup includes a few nasty caveats that will bite you on serious deployments."

Sorry! There are no comments related to the filter you selected.

Read their website (5, Informative)

Anonymous Coward | about a year and a half ago | (#43555657)

It says "experimental." They appreciate you helping them test their file system out. I appreciate it too, so please do. But remember that you are testing an experimental filesystem. When it eats your data, make sure you report it and have backups.

Sorry Slashdot. (5, Funny)

Anonymous Coward | about a year and a half ago | (#43555895)

Ugh, I'm really sorry about this post, Slashdot. I really didn't think it was going to a "First post." What I really meant to post was

OMFG fr1st psot!!!! APK!! crazy host file conspiracy! /etc/mod_me_down

Re:Read their website (5, Informative)

pipatron (966506) | about a year and a half ago | (#43556029)

Every file system is/should be labled "experimental" in a way. The long answer from the btrfs FAQ is pretty good, and makes some sense:

Long answer: Nobody is going to magically stick a label on the btrfs code and say "yes, this is now stable and bug-free". Different people have different concepts of stability: a home user who wants to keep their ripped CDs on it will have a different requirement for stability than a large financial institution running their trading system on it. If you are concerned about stability in commercial production use, you should test btrfs on a testbed system under production workloads to see if it will do what you want of it. In any case, you should join the mailing list (and hang out in IRC) and read through problem reports and follow them to their conclusion to give yourself a good idea of the types of issues that come up, and the degree to which they can be dealt with. Whatever you do, we recommend keeping good, tested, off-system (and off-site) backups.

Re:Read their website (4, Informative)

Bengie (1121981) | about a year and a half ago | (#43556921)

My cousin said when he had to go "FS shopping" for his research data center, they had some requirements, most notably, being used by several enterprises that all store at least 1PB of data on the FS and have not had any critical issues in 5 years.

He said the only FS that fit-the-bill was ZFS. His team could not find an enterprise company that stored at least 1PB of data on ZFS and had a non-user caused critical problem within the past 5 years. That was many years ago and he has not had a single issue with his multi-PB storage that is being used by hundreds of departments.

ZFS is not perfect, but it sets a very high bar.

Re:Read their website (2)

Tarlus (1000874) | about a year and a half ago | (#43556071)

And make sure those backups aren't also on a btrfs volume.

Re:Read their website (0, Troll)

h4rr4r (612664) | about a year and a half ago | (#43556203)

I did not realize btrfs was also suitable for magnetic tape use.

Re:Read their website (1)

Tarlus (1000874) | about a year and a half ago | (#43556319)

Maybe if you wrote the image of a btrfs volume to a tape?

Re:Read their website (1)

e70838 (976799) | about a year and a half ago | (#43556715)

The Tape Archiver is filesystem agnostic ;-)

Re:Read their website (3, Insightful)

isopropanol (1936936) | about a year and a half ago | (#43556631)

Also, read the article. The authors were experimenting and came across some bugs in some pretty hairy edge cases (hundreds of simultaneous snapshots, large disk array suddenly becoming full, etc) that did not cause data loss. They eventually decided not to use BTRFS on one type of system but are using it on others.

To me, the article was a good thing... But I would have preferred if it was worded as here are some edge case bugs that need fixing before BTRFS is used in our scenario, rather than that these were show stoppers... Because these are not likely show stoppers to anyone who's not implementing the exact same scenario.

Also It sounds like they should jitter the start time of the backups...

Re:Read their website (1, Insightful)

Tough Love (215404) | about a year and a half ago | (#43556975)

Bugs are like roaches. If you see one, you can be sure there are many others hiding in the cracks. There is no room for any bugs at all in a filesystem to which you will trust your essential data.

Re:Read their website (2)

AvitarX (172628) | about a year and a half ago | (#43557131)

Being unfixable when full is a pretty big show stopper IMO.

Arrg !!! (-1)

Anonymous Coward | about a year and a half ago | (#43555669)

Fr1zt

Happy with XFS (3, Informative)

zidium (2550286) | about a year and a half ago | (#43555689)

I've been happily using the XFS file system since the early-to-mid-2000s and have never had a problem. It is rock solid and much faster than ext3/ext4 in my experience, tested a lot longer than Btrfs, and handles the millions and millions of small files on redditmirror.cc very effectively.

Re:Happy with XFS (3, Insightful)

h4rr4r (612664) | about a year and a half ago | (#43555727)

It also has none of the features that make Btrfs exciting and modern.

XFS is fine, so is Ext3/Ext4, but Linux need a modern file system.

Re:Happy with XFS (0, Offtopic)

Anonymous Coward | about a year and a half ago | (#43555835)

"...but Linux need a modern file system."

Because? I'm sorry, you must have a different set of requirements than the article described (data center, decent performance, minimal risk of data loss). If you need a modern file system for your personal computer at home and can live with data loss and downtime, please feel free to indulge - that's one of the many benefits of Open Source. Or perhaps you are confusing volume/RAID management with the file system?

Count another vote for happy with XFS on Linux after they worked out the bugs in the early 2000's. JFS (from IBM) and EXT4 are just as reliable nowadays.

Re:Happy with XFS (1, Redundant)

nametaken (610866) | about a year and a half ago | (#43555871)

This is why we can't have nice things.

Re:Happy with XFS (2)

h4rr4r (612664) | about a year and a half ago | (#43555901)

No, I am suggesting datacenter linux needs something like ZFS. Proper snapshotting, block level dedupe, and all that jazz.

Btrfs is not yet ready, but in the next decade it will take on this role.

Re:Happy with XFS (1)

iggymanz (596061) | about a year and a half ago | (#43555911)

XFS on linux doesn't have the "modern" features (which mature OS have had for decades), such as shared filesystem clustering

Re:Happy with XFS (2, Informative)

Anonymous Coward | about a year and a half ago | (#43556647)

there's CXFS which _is_ a clustered filesystem. Not as popular as GFS or OCFS2, but it's there, and uses the same block format as 'regular' XFS.

Not sure what you refer by "mature OS", but note that ZFS is _not_ a cluster filesystem by any strecth of the definition.

Re:Happy with XFS (2)

jedidiah (1196) | about a year and a half ago | (#43556891)

That would be the same "mature" operating systems that have generally needed to employ products from 3rd party vendors in order to have interesting filesystems.

Re:Happy with XFS (1)

Anonymous Coward | about a year and a half ago | (#43556795)

Or perhaps you are confusing volume/RAID management with the file system?

That would be like mixing chocolate and peanut butter. Seriously, there is no reason the "volume/RAID" abstraction and "file system" abstraction should not be merged. Separating the two was a solution to a problem that no longer exists.

Re:Happy with XFS (2)

Tough Love (215404) | about a year and a half ago | (#43557007)

there is no reason the "volume/RAID" abstraction and "file system" abstraction should not be merged. Separating the two was a solution to a problem that no longer exists

Oh, so true. Indeed, problems like modularity, maintainability and shared functionality stopped existing long ago as we all know.

Re:Happy with XFS (2)

Bengie (1121981) | about a year and a half ago | (#43556961)

It is impossible to compete with a FS+VolumeManager+RAID hybrid. There is just some stuff that impossible to do without coupling those layers and those impossible things are becoming requirements.

Re:Happy with XFS (3, Informative)

bored (40072) | about a year and a half ago | (#43555763)

Your happy with XFS because your machine has never lost power or crashed. If either of those things happened with the older versions of XFS it was nearly a 100% guarantee you would lose data. Now i'm told its more reliable.

So, if you told me you have been running it for the last year and it was reliable I would have given you more credit than claiming you have been running it for a decade and its been reliable. Because, its had some pretty serious issues that if you didn't hit them means your not a good test case.

I'm still skeptical, because AKAIK, XFS still doesn't have an order data mode.

Re:Happy with XFS (5, Informative)

MBGMorden (803437) | about a year and a half ago | (#43555951)

Your happy with XFS because your machine has never lost power or crashed. If either of those things happened with the older versions of XFS it was nearly a 100% guarantee you would lose data. Now i'm told its more reliable.

I don't know about being more reliable. I use XFS on my RAID array (mdadm) at home. I'm running the latest version of Linux Mint (Nadia), and if I ever lose poser and don't unmount that file system cleanly it looses all recent changes to the drive (and "recent" sometimes stretches to hours ago). The drive mounts fine and nothing appears corrupted (so I guess its not completely data loss), but any files changes (edits, additions, or deletions) to the file system are simply gone.

Its gotten to the point where if I've just put a lot of stuff on the drive I unmount it and then remount it just to make sure everything gets flushed to disk. If I ever get a chance to rebuild that array it most certainly will be using something different.

Re:Happy with XFS (4, Informative)

Booker (6173) | about a year and a half ago | (#43556015)

No, that's FUD and/or misunderstanding on your part.

"data=ordered" is ext3/4's name for "don't expose stale data on a crash," something which XFS has never done, with or without a mount option. ext3/4 also have "data=writeback" which means "DO expose stale data on a crash." XFS does not need feature parity for ill-advised options.

Any filesystem will lose buffered and unsynced file data on a crash (http://lwn.net/Articles/457667/). XFS has made filesystem integrity and data persistence job one since before ext3 existed. Like any filesystem, it has had bugs, but implying that it was unsafe for use until recently is incorrect.

I say this as someone who's been working on ext3, ext4 and xfs code for over a decade, combined.

Re:Happy with XFS (5, Insightful)

bored (40072) | about a year and a half ago | (#43556483)

No, that's FUD and/or misunderstanding on your part.

"data=ordered" is ext3/4's name for "don't expose stale data on a crash," something which XFS has never done,

Actually, I think your the one that doesn't understand how a journaling file system works. The problem with XFS has been that it only journals meta data, and the data portions associated with the metadata are not synchronized with the metadata updates (delayed allocation an all that). This means the metadata portions (filename, sizes, etc) will be correct based on the last journal update flushed to media, but the data referenced by that meta-data may not be.

A filesystem that is either ordering its meta data/data updates against a disk with proper barriers, or journing the data alongside the meta data doesn't have this problem. The filesystem _AND_ its data remain in a consistent state.

So, until your understand this basic idea, don't go claiming you know _ANYTHING_ about filesystems.

Re:Happy with XFS (0, Offtopic)

Anonymous Coward | about a year and a half ago | (#43556659)

Geez, bored, I wish you'd get your spelling straight:

your == something you own, as in "your car" or "your house"
you're == "you are"

Wrong:
"Your not great at spelling."

Right:
"You're not great at spelling."

I think that your comments contain good information, but you keep making this spelling mistake over and over, and it detracts from your message.

Ignorance stated confidently is still ignorance. (0)

Anonymous Coward | about a year and a half ago | (#43556379)

Please just STFU if you don't know what you are talking about.

Both CERN and Fermilab have been using XFS to manage **PETABYTES** of data for many years now. Fermilab switched from ReiserFS, which should give you some indication of the time frame we are talking about.

You don't understand the problem (2, Interesting)

Anonymous Coward | about a year and a half ago | (#43556425)

The problem with "XFS" eating data wasn't with XFS - it was with the Linux devmapper ignoring filesystem barrier requests. [nabble.com]

Gotta love this code:

Martin Steigerwald wrote:
> Hello!
>
> Are write barriers over device mapper supported or not?

Nope.

see dm_request(): /*
                  * There is no use in forwarding any barrier request since we can't
                  * guarantee it is (or can be) handled by the targets correctly.
                  */
                if (unlikely(bio_barrier(bio))) {
                                bio_endio(bio, -EOPNOTSUPP);
                                return 0;
                }

Who's the clown who thought THAT was acceptable? WHAT. THE. FUCK?!?!?!

And it wasn't just devmapper that had such a childish attitude towards file system barriers [lwn.net] :

Andrew Morton's response tells a lot about why this default is set the way it is:

Last time this came up lots of workloads slowed down by 30% so I dropped the patches in horror. I just don't think we can quietly go and slow everyone's machines down by this much...

There are no happy solutions here, and I'm inclined to let this dog remain asleep and continue to leave it up to distributors to decide what their default should be.

So barriers are disabled by default because they have a serious impact on performance. And, beyond that, the fact is that people get away with running their filesystems without using barriers. Reports of ext3 filesystem corruption are few and far between.

It turns out that the "getting away with it" factor is not just luck. Ted Ts'o explains what's going on: the journal on ext3/ext4 filesystems is normally contiguous on the physical media. The filesystem code tries to create it that way, and, since the journal is normally created at the same time as the filesystem itself, contiguous space is easy to come by. Keeping the journal together will be good for performance, but it also helps to prevent reordering. In normal usage, the commit record will land on the block just after the rest of the journal data, so there is no reason for the drive to reorder things. The commit record will naturally be written just after all of the other journal log data has made it to the media.

I love that italicized part. "OMG! Data integrity causes a performance hit! Screw data integerity! We won't be able to brag that we're faster than Solaris!"

See also http://www.redhat.com/archives/rhl-devel-list/2008-June/msg00560.html [redhat.com]

There's a lot more out there if you care to look.

Toss in other things like the way Linux handles NFSv2 group membership (More than 16? Let's just silently drop some!) and lots of fanbois wonder why I view Linux as little better than Windows. Hell, Microsoft may fuck things up six ways from Sunday, but they're not CHILDISH when it comes to things like data integrity.

Re:You don't understand the problem (1)

h4rr4r (612664) | about a year and a half ago | (#43556731)

Data integrity is fine, if you are not running XFS.

Why should everyone suffer a 30% performance hit, to make the couple oddballs running XFS happy?

Re:Happy with XFS (4, Interesting)

Kz (4332) | about a year and a half ago | (#43556909)

Your happy with XFS because your machine has never lost power or crashed. If either of those things happened with the older versions of XFS it was nearly a 100% guarantee you would lose data. Now i'm told its more reliable.

It _is_ quite reliable, even on the face of hardware failure.

Several years ago, I hit the 8TB limit of ext3 and had to migrate to a bigger filesystem. ext4 wasn't ready back then (and still today it's not easy to use on big volumes). Already had bad experiences with reiserfs (which was standard on SuSE), and the "you'll lose data"warnings on XFS docs made me nervous. It was obviously designed to work on very high-end hardware, which I couldn't afford.

so, I did extensive torture testing. hundreds of pull-the-plug situations, on the host, storage box and SAN switch, with tens of processes writing thousands of files on million-files directories. it was a bloodbath.

when the dust settled, ext3 was the best by far, managing to never lose more than 10 small files in the worst case, over 70% of the cases recovered cleanly. XFS was slightly worse, never more than 16 lost files and roughly 50% clean recoveries. ReiserFS was really bad, always losing more than 50-70 files and sometimes killing the volume. JFS didn't lose the volume, but lost files count never went below 130, sometimes several hundred.

needless to say, i switched to XFS, and haven't lost a single byte yet. and yes, there has been a few hardware failures that triggered scary rebuilding tasks, but completed cleanly.

Re:Happy with XFS (1)

Hatta (162192) | about a year and a half ago | (#43555937)

XFS doesn't checksum, support copy-on-write, etc.

Re:Happy with XFS (2)

jabuzz (182671) | about a year and a half ago | (#43556381)

On the other hand the code was first released as production nearly 20 years ago. Of all the current Linux file systems XFS has the best performance, the best scalability and the best stability.

Want to put 100TB of data on btrfs be my guest.

Re:Happy with XFS (1)

Urban Garlic (447282) | about a year and a half ago | (#43556523)

I've been using it for a long time, too, it's a perfectly respectable choice, and if I had to use it for ten more years, that would be OK.

However, particularly for back-up systems, I am ready for snapshots and block-level deduplication. I tried to deploy something like this with XFS over LVM a few years ago, but discovered that the write performance of LVM snapshots degrades rapidly when there are a lot of them, and it helps a lot if you can guess the size in advance, which is hard. There's also a hard limit of 255 snapshots, but in our environment, performance became unacceptable before we got anywhere near that.

You're right that XFS "ain't broke", but I for one am ready for more features.

replace ext3 and ext4? really? (0)

Anonymous Coward | about a year and a half ago | (#43555691)

Does submitter even work in IT?

Re:replace ext3 and ext4? really? (3, Informative)

h4rr4r (612664) | about a year and a half ago | (#43555747)

Lots of production servers user Ext filesystems. If btrfs is all it should be it will certainly replace these file systems one day soon as the safe choice.

Sure people use other filesystems on production Linux servers, but those are not the norm. The safe "Enterprise" (Not necessarily a good thing) choice is still Ext based filesystems.

Re:replace ext3 and ext4? really? (2)

jabuzz (182671) | about a year and a half ago | (#43556493)

Want more than 16TB on your server? Unless ext4 has very recently grown that support then using an ext based file system is not viable. Remember a RAID5 in 4D+P using 4TB disks will be super close to that 16TB limit. Better hope that you don't want to scale the file system up in the future.

Re:replace ext3 and ext4? really? (1)

h4rr4r (612664) | about a year and a half ago | (#43556629)

Friends don't let friends use RAID5.

As far as I know there are no 4TB SAS drives available yet.

This is another reason why people want btrfs soon. Right now it is not yet an issue, for most use cases. Since you can have many 16TB volumes.

Re:replace ext3 and ext4? really? (2, Interesting)

Anonymous Coward | about a year and a half ago | (#43556819)

FYI, ext4 can be larger than 16 TB but you need a newer version of the e2fsprogs than is included in a typical enterprise distribution. It's not the kernel filesystem drivers with the limitation, but the user-level utility for formatting a new filesystem.

The oracle in the woodpile (2)

larry bagina (561269) | about a year and a half ago | (#43555713)

I think we need to talk about the oracle in the woodpile - ie, Oracle. BTRFS is an Oracle project. What happens when it goes the way of MySQL? Will Monty Wideanus appear on a white steed to save us?

Re:The oracle in the woodpile (0)

Anonymous Coward | about a year and a half ago | (#43555797)

And if you're going to get into bed with Oracle, why not just use ZFS?

Re:The oracle in the woodpile (1)

h4rr4r (612664) | about a year and a half ago | (#43555829)

Because ZFS can never be distributed with Linux. It has to be bolted on after the fact, because SUN made a short sighted decision to try to keep Solaris alive.

Re:The oracle in the woodpile (5, Interesting)

larry bagina (561269) | about a year and a half ago | (#43555983)

Oracle now owns ZFS. They could relicense it if they wanted to. BTRFS was started before the Sun acquisition but it seems strange* to develop BTRFS as a GPL file system with ZFS-like features while ZFS is mature and reliable today.

* Yes, they're a large corporation and right hand doesn't know what left hand does... but isn't this more like the index finger not knowing what the middle finger is doing?

Re:The oracle in the woodpile (1)

h4rr4r (612664) | about a year and a half ago | (#43556093)

Oracle does not want to do that. I am sure btrfs exists only because the DB boys want a new good filesystem and the Solaris org chart heads will not let ZFS slip from their grasp.

ZFS is mature and reliable today on Solaris and BSD, the Linux port is far newer.

Re:The oracle in the woodpile (2)

bill_mcgonigle (4333) | about a year and a half ago | (#43556519)

It's Oracle. They'll re-license ZFS just as soon as it's no longer profitable for them not to.

Re:The oracle in the woodpile (1)

fsterman (519061) | about a year and a half ago | (#43556685)

Yes, they're a large corporation and right hand doesn't know what left hand does... but isn't this more like the index finger not knowing what the middle finger is doing?

I am quite sure that Larry Ellison knows *exactly* what his middle finger is doing.

“But Steve, there’s one thing I don’t understand,” he said. “If we don’t buy the company, how can we make any money?” It was a reminder of how different their desires were. Jobs put his hand on Ellison’s left shoulder, pulled him so close that their noses almost touched, and said, “Larry, this is why it’s really important that I’m your friend. You don’t need any more money.”
Ellison recalled that his own answer was almost a whine: “Well, I may not need the money, but why should some fund manager at Fidelity get the money? Why should someone else get it? Why shouldn’t it be us?”

Re:The oracle in the woodpile (0)

Anonymous Coward | about a year and a half ago | (#43556125)

You could use FreeBSD.

Re:The oracle in the woodpile (1)

h4rr4r (612664) | about a year and a half ago | (#43556235)

No, I cannot.

I have a many servers that run commercial software only supported on RHEL.

Re:The oracle in the woodpile (0)

Anonymous Coward | about a year and a half ago | (#43555875)

People from Red Hat, FusionIO, Suse and others are also working on BTRFS. So don't spread FUD, btrfs is not an oracle project anymore.

ZFS (5, Informative)

0100010001010011 (652467) | about a year and a half ago | (#43555751)

Meanwhile ZFS announced that it was ready for production [theregister.co.uk] last month.

http://zfsonlinux.org/ [zfsonlinux.org]

Re:ZFS (4, Insightful)

h4rr4r (612664) | about a year and a half ago | (#43555809)

It will be ready for production when it can be distributed with the kernel.

Do you really want to depend on an out of tree FS?

Re:ZFS (3, Interesting)

Bill_the_Engineer (772575) | about a year and a half ago | (#43555883)

Incompatible license prevents ZFS inclusion with the kernel. This is why Btrfs exists and explains Oracle's involvement with both.

Re:ZFS (4, Insightful)

h4rr4r (612664) | about a year and a half ago | (#43555915)

Correct sir.
My point still stands though. Even though the limitation keeping it from being seriously considered for production is caused by a legal issue not a technical one.

Re:ZFS (0)

Oceanplexian (807998) | about a year and a half ago | (#43556005)

My point still stands though. Even though the limitation keeping it from being seriously considered for production is caused by a legal issue not a technical one.

FreeBSD is not GPL, does that mean it's not production ready, or running GPL code on a BSD box is not production ready?
Mixing licenses does not somehow make things "not production ready".

Re:ZFS (3, Interesting)

Chris Mattern (191822) | about a year and a half ago | (#43556091)

Mixing licenses does not somehow make things "not production ready".

No, using a file system that doesn't ship with the kernel makes things "not production ready." Licensing is the reason why it doesn't ship with the kernel, but it's not shipping with the kernel that keeps it out of critical production use.

Re:ZFS (2)

h4rr4r (612664) | about a year and a half ago | (#43556119)

This.

The reason they can't ship together and be updated via normal RHEL/SUSE/Debian updates is licensing, but the technical problem keeping it from being seriously considered for production is that they can't be updated and shipped together.

Re:ZFS (0)

Anonymous Coward | about a year and a half ago | (#43557003)

Oh look, somebody's not using chef or puppet to manage his system configurations. How quaint.

Re:ZFS (2)

Oceanplexian (807998) | about a year and a half ago | (#43555935)

It will be ready for production when it can be distributed with the kernel.

ZFS is not included in the Linux kernel because it is not GPL compatible.
Licensing has nothing to do with how production-ready a product is. ZFS is significantly [rudd-o.com] more mature than btrfs.

Re:ZFS (2)

h4rr4r (612664) | about a year and a half ago | (#43556019)

Yes, but the statement is still true.

It means you will not get updates via normal channels, or normal channel updates might break it. That simply is not something most datacenters want to deal with. ZFS is more mature on Solaris and BSD, on Linux today it might be ahead of btrfs, but neither is production ready in the sense that datacenters mean it.

Re:ZFS (1)

Guspaz (556486) | about a year and a half ago | (#43556365)

No, the statement is false. There are no licensing issues to including the zfsonlinux kernel module with distros. The precedent on kernel module licensing has been long set by things like nVidia drivers, and zfs uses a free software license that enables distribution. Some distros like Gentoo already do include zfsonlinux, and I imagine more will in the future. On these distros, you WILL get updates via normal channels.

If you define "distributed with the kernel" to say "this distribution includes both the kernel and zfsonlinux", then yes, zfsonlinux can and IS already distributed with the kernel.

Re:ZFS (1)

h4rr4r (612664) | about a year and a half ago | (#43556555)

Are any of these Enterprise distros?
I don't know of any of those that distribute any of the kernel modules are speaking of.

Gentoo is linux for ricers.

Re:ZFS (1)

Guspaz (556486) | about a year and a half ago | (#43557081)

Gentoo today, who knows what else tomorrow. I'm not a fan of Gentoo, but the fact ZFS is being included in any distros show that claims that licensing prevents distro inclusion are FUD. You can probably make a bunch of legitimate arguments about being out of tree, or kernel taint when you load it, or who knows what else, but ability to distribute isn't one of the problems.

Re:ZFS (1)

ultranova (717540) | about a year and a half ago | (#43556969)

It means you will not get updates via normal channels, or normal channel updates might break it. That simply is not something most datacenters want to deal with.

But it's something datacenters will have to deal with anyway. After all, there's no guarantee that any update won't break something, so they'll need an internal update server that only gets vetted and tested updates - and at that point it's not much of a bother to include out-of-tree patches, assuming of course that they give a significant advantage.

Re:ZFS (1)

Chris Mattern (191822) | about a year and a half ago | (#43556123)

The reason *why* ZFS doesn't ship with the kernel is mostly irrelevant. The fact remains--in order to use ZFS in Linux, you have to roll your own custom system. This is not a good thing for production.

Re:ZFS (1)

Guspaz (556486) | about a year and a half ago | (#43556323)

People keep saying stuff like this, but it's just FUD. zfsonlinux exists as a kernel module, this isn't zfs-fuse anymore. Installing it on a common distro like Debian that doesn't include it via the package management system requires two commands (add repo, install package). Some distributions like Gentoo already include zfsonlinux as part of the distro, and this will undoubtedly increase as time goes on.

There are no more legal or technical problems with zfsonlinux than something like the nVidia drivers. Less, in fact, since zfsonlinux *is* distributed under a free software license.

Re:ZFS (1)

h4rr4r (612664) | about a year and a half ago | (#43556525)

That first command is your problem.
Not in the normal repos not getting installed.

No one installs the closed nVidia drivers on production machines.

Re:ZFS (1)

Guspaz (556486) | about a year and a half ago | (#43557029)

It's in the normal Gentoo repos. I recall another distro it was in, but I don't remember the name (started with an S?) As it continues to mature, I find it likely that we'll see it included in more distros.

Re:ZFS (1)

Cid Highwind (9258) | about a year and a half ago | (#43556923)

You missed two steps, the full process is:

1: Add non-standard repo
2: Kiss distro maintainer support goodbye.
3: Install package
4: Kiss kernel developer support goodbye (kernel tainted: disabling lock debugging)

Re:ZFS (2, Insightful)

Anonymous Coward | about a year and a half ago | (#43555999)

It will be ready for production when it can be distributed with the kernel.

Do you really want to depend on an out of tree FS?

That's why the fileserver runs FreeBSD. Has other benefits, too.

hype hype hype (-1)

Anonymous Coward | about a year and a half ago | (#43555761)

hype hype hype

BRTFS delivers nothing.

Re:hype hype hype (1)

amiga3D (567632) | about a year and a half ago | (#43555823)

Isn't that a common trait with experimental systems?

A Few Nasty Caveats? (0)

Anonymous Coward | about a year and a half ago | (#43555879)

A few nasty caveats? When we are talking about a file system, there can be no nasty caveats. If the file system isn't bullet proof, it is unusable!

Re:A Few Nasty Caveats? (2)

Cito (1725214) | about a year and a half ago | (#43556095)

yea Btrfs has one major bug

if you fill the hard drive up you lose access to the system, you can't log in or even get access to the filesystem and the system locks up

with ext things may act a bit erratic but you could log in and delete/move things off to make room and be ok. but Btrfs you can't if it fills up you lose

unless you take the hard drive out move it to another box and mount it then delete crap that way, but that's a pain in arse.

Why? (0)

JDG1980 (2438906) | about a year and a half ago | (#43555899)

Aside from ideological reasons, why would anyone choose btrfs over ZFS? The latter seems to be superior from both a theoretical and practical standpoint, and has more real-world stability testing. This is especially true if you're not specifically wedded to Linux and are willing to use FreeBSD or a derivative for your file hosting server(s).

Re:Why? (5, Insightful)

h4rr4r (612664) | about a year and a half ago | (#43555975)

ZFS is outside the kernel tree. That is not an ideological issue, but a practical one. It means updates will not come from the normal channels, it means kernel updates form normal channels could break it and it is not getting the attention from the kernel devs an fs should get.

ZFS on linux has probably less testing than Btrfs at this point. It has near no real world testing. Just because the Solaris ZFS is great, and the BSD one is coming along means nothing for the stability and correctness of the Linux port.

If you want to use a different OS than this entire discussion is worthless. You might as well suggest switching everything to OSX and using HFS+.

It's completely ideological. (0)

Anonymous Coward | about a year and a half ago | (#43556959)

ZFS us vastly superior to Btrfs [rudd-o.com] --yes, even on Linux. It's all about licensing crap. This is yet another example of open source foolishly generating waste heat on projects for dubious reasons.

Re:It's completely ideological. (1)

0123456 (636235) | about a year and a half ago | (#43557107)

'Licensing crap' is legal, not ideological.

Re:Why? (0)

Anonymous Coward | about a year and a half ago | (#43557135)

Why are you not testing updates from ANY source before applying them in production? If stability is that critical, it should be trivially easy for you to image a system with the latest packages you want to move production servers to (regardless of source) and test them thoroughly - just like you should be doing with ANY updates hitting your production systems.

If you're unable to do this level of automation, you should probably go learn how. It's 2013 - configuring & deploying production systems should be almost completely push-button in any "enterprise" concerned with production stability.

Yawn, yet another filesystem... (0)

bored (40072) | about a year and a half ago | (#43555963)

That will probably get 95% done before the next cool kid on the block takes over.

Filesystems on linux never seem to be 100% done. By that I mean, they are bulletproof and reasonably fast.

Just think, if instead of having dozens of primary fileystems (ext[2,3,4], reiserfs, ocfs, ocfs2, xfs, jfs. gfs2, zfs) over the last 15 years, someone had actually spent the time and designed/researched a general purpose filesystem, implemented and slogged through all the issues on one of them. Linux might have a good filesystem. The ext2/3 combination appeared to be on that path, but instead of fixing the fsync problems, and a couple other issues, it was basically abandoned in favor of ext4 which while maintaining the ability to mount ext3, and is named the same could have just been called "we took some bad ideas from XFS for performance reasons and now we have the same data integrity problems".

Re:Yawn, yet another filesystem... (5, Insightful)

h4rr4r (612664) | about a year and a half ago | (#43556169)

Ext3 is still chugging along and doing what you want. A filesystem that sacrifices everything for stability.

Not everyone has the same wants and needs. Lots of competing filesystems is a good thing, it leads to a market of ideas. Your lets pick one and force everyone to suffer with our choice just leads to stagnation and even worse results.

Re:Yawn, yet another filesystem... (2)

bored (40072) | about a year and a half ago | (#43556967)

Ext3 is still chugging along and doing what you want. A filesystem that sacrifices everything for stability.

EXT3, is actually fairly good, and the performance isn't bad _EXCEPT_ for one issue. fsync(), which causes a massive IO barrier against all the other operations in the filesystem. fsync() should only be assuring the named file is consistent, and yet it basically stalls the entire FS to assure that one file. Its a problem with lack of proper IO tagging and actually is a fundamental problem with the block layer in linux. A recent LSML posting about SYNCHRONIZE CACHE hints at the problem too (complete device flush when only a small portion of the IO needs to be flushed).

Re:Yawn, yet another filesystem... (1)

0123456 (636235) | about a year and a half ago | (#43557065)

99% of software doesn't need to call fsync() on a sanely designed filesystem. The most likely problem is software which calls fsync() regularly to work around ext4 retardeness then being run on ext3, or apps which use libraries like sqlite that call fsync() multiple times when updating the database.

Certainly when I manually sync on my CentOS machine it takes several seconds to complete the writes to disk, so clearly the software I run there isn't calling fsync() much.

Re:Yawn, yet another filesystem... (1)

Anonymous Coward | about a year and a half ago | (#43556245)

Is part of the open source karma. "Shiny and New" is much more important than "stable, bug-free and usable"

Re:Yawn, yet another filesystem... (0)

Anonymous Coward | about a year and a half ago | (#43556265)

Just think, if instead of having dozens of primary fileystems (ext[2,3,4], reiserfs, ocfs, ocfs2, xfs, jfs. gfs2, zfs) over the last 15 years, someone had actually spent the time and designed/researched a general purpose filesystem, implemented and slogged through all the issues on one of them. Linux might have a good filesystem.

xkcd.com/927/ [xkcd.com]

Re:Yawn, yet another filesystem... (1)

interval1066 (668936) | about a year and a half ago | (#43556721)

Linux DOES have a good file system. As xkcd says; it has 15 of 'em. This is one of the highlights of Linux, you can use any fs available. The bad side is simply many of them are old, a few are too new, and most don't have ALL the features enterprise's need. This is a good thing though. When Apple or Microsoft delcare a critical system infrastructure feature complete, and its not for you, what is your recourse? At least with Linux if something new is really needed it can be added. The possibility is there.

Re:Yawn, yet another filesystem... (1)

jabuzz (182671) | about a year and a half ago | (#43556437)

The primary reason for the existence of ext4 is Lustre. By far the best option for a general purpose none clustered Linux file system is XFS by some considerable distance. The crying shame is that RedHat did not make a grab for CXFS out the ruins of SGI but persisted with GFS2 and then purchased Glustre.

Re:Yawn, yet another filesystem... (1)

h4rr4r (612664) | about a year and a half ago | (#43556679)

They fix that write barrier issue yet?

Don't tell me it is a Linux bug, that is a cop out. Either it will lose my data or it will not, I don't care why.

Sigh (0)

Anonymous Coward | about a year and a half ago | (#43556907)

The age-old "unite and consolidate" argument rears its pointless head once again. And once again, the answer is that the people who work on open source software do so because they benefit from it -- whether for experience, for money, or for plain old personal satisfaction -- not because you benefit from it.

Open source software is not charity work. It may be free, and you may benefit from it, but it wasn't designed FOR you.

I'm going to break this to you as politely as I can. No matter what you say or do, the people who work on these projects will continue to devote their time and effort to the things which they find valuable, not the things which you find valuable. There is one thing, however, that can change that: you can pay them.

Re:Sigh (1)

bored (40072) | about a year and a half ago | (#43557197)

Well, if linux is a toy (your basic argument) then why are all the subsystem maintainers paid by large companies a salary same as the developers at Microsoft, or any other OS company?

My point doesn't preclude people showing up and writing the next great filesystem. Its simply a question of why everyone thinks its a good idea for a guy PAID to maintain a filesystem to drop it and go write another one. If you worked for _BIG_ company and were paid to maintain their application, and you decided one day that maintaining their application was a PITA cause it was old crufty and not sexy anymore and instead refused to fix problems in it, rather spending the next 4 years writing a replacement (complete with another set of bugs) how long do you think your job would last?

Of course, this stuff happens in a lot of software projects, new developer shows up, and writes buggy new system cause they think they are smarter than the last guy. It frankly speaks of immaturity and an "artist" mentality rather than an engineering process. Sure, software isn't all engineering but linux is an OS, its a fundamental part of a computing platform and one that is expected to provide some basic level of service to applications (you know the things actually doing the work). When it fails at that, because its a patchwork of art, then you have to question why.

take good note of distros that treat it as stable" (1)

iggymanz (596061) | about a year and a half ago | (#43556007)

Those distros such as SuSE Linux Enterprise Server, that claim it was production ready and have it in the install, should be shunned. Don't entrust your data to them

Full limit (1)

amginenigma (1495491) | about a year and a half ago | (#43556209)

So what is this 'Full' limit? In the ZFS world it's accepted to keep the pool (volume) under 80% usage to prevent issues. Is this something that should be applied as a 'best practice' to btrfs?

Re:Full limit (1)

fsterman (519061) | about a year and a half ago | (#43556785)

The last I checked (which was a very long time ago) Linux/ext required a logical swap partition for paging. Why not just preallocate some space in BTFS and be done with it?

Still use reiserfs (0)

Anonymous Coward | about a year and a half ago | (#43556429)

I still use reiserfs of my mdadm raid-5 (Installed right after Katrina ate my old sever)
And i have reisrfs on an older mdadm raid-5 from around 2000.

both have been rock solid running 24x7 and in reality that is the ultimate test.

(Though I would like to see a new BeFS driver created for fun.)

Re:Still use reiserfs (1)

rilles (1153657) | about a year and a half ago | (#43556655)

My unraid system still sticks with reiserfs. Been using it for years with no obvious issues seen, the unraid application author still seems to prefer it over any other FS.

Best Tech Thread Evar!! (1)

interval1066 (668936) | about a year and a half ago | (#43556653)

Actually I'm being serious. This is why I come to /.

I still prefer XFS (1)

Damouze (766305) | about a year and a half ago | (#43556883)

I still prefer XFS ;-).

My experiance, for what it worth... (2)

sshir (623215) | about a year and a half ago | (#43557067)

Installed Xubuntu 12.10 last October(ish) on USB2 stick (jetflash 32G) with Btrfs (only /boot had EXT2 partition, no swap)

Reason: 24/7 machine. It's a notebook - always spinning harddrive is a drag: spins up cooling fun; so I went solid state for primary OS drive.Needed filesystem that spreads wear and does checksums - hence Btrfs.

Usage - downloading stuff (to the stick itself, not the harddrive) plus some NASing. Data volume: wrapped around those 32gigs few times already.

Observations so far: no problems at all.

Other details: Had to play with I/O scheduler (I think settled on CFQ. Interestingly, NOOP sucked). Had to install hdidle (I think) otherwise couldn't force sda to go to sleep (bug (?)).

bad joke... (1)

Anonymous Coward | about a year and a half ago | (#43557161)

I've just lost ( an our ago ) the entire FS tree in archlinux installation ( I forgot to prepare meself with the btrfsprogs ) - I thought I was safe to use btrfs - I wasn't even able to boot ubuntu-live (13.04) because [the screwed] btrfs partitions made the kernel (btrfs module from the Ubuntu live) crash at boot :-)

- destroy offeding partition
- restart from scratch but NEVER-EVER use btrfs again!

I have my lesson - don't touch anythings you do NOT know very well.
Therefore, it is a pleasure for me to re-install archlinux ( using ext4 this time!!! ) again :-)

Long live archlinux :-)
hahahaha

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?