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!

OpenSUSE 13.2 To Use Btrfs By Default

Soulskill posted about 7 months ago | from the changing-horses dept.

Data Storage 91

An anonymous reader writes "OpenSUSE has shared features coming to their 13.2 release in November. The big feature is using Btrfs by default instead of EXT4. OpenSUSE is committed to Btrfs and, surprisingly, they are the first major Linux distribution to use it by default. But then again, they were also big ReiserFS fans. Other planned OpenSUSE 13.2 features are Wayland 1.4, KDE Frameworks 5, and a new Qt5 front-end to YaST."

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

Beta testers (5, Insightful)

Anonymous Coward | about 7 months ago | (#46528273)

Finally someone who beta tests btrfs for me!

Re:Beta testers (-1)

Anonymous Coward | about 7 months ago | (#46528441)

Finally someone who beta tests btrfs for me!

Yay, they're using btrfs by default. Because we all know, no Linux user would EVER think to change the default by clicking a little drop-down menu on any other distro! And no OpenSUSE user who doesn't want to beta test this would EVER think to change the default to ext4 or whatever.

Nope. You know how those Linux users are. They go out of their way to get a copy of Linux and learn how to install it. Then they wipe the default Windows off their computer. Then they install Linux. I mean, how passive is THAT?! These are definitely not people who would ever consider reading and changing any default setting. Nosirree.

So yes, let us assume a big flood of brtfs beta testers just because it is now a default on one distro. I mean, who could find a flaw in THAT logic?

Re:Beta testers (-1)

Anonymous Coward | about 7 months ago | (#46528687)

Whaaaaaaa! *cry cry* I can't find fault with what you said. But it sounds MEAN. YOU BIG MEANEY HEAD! So I will just mod it down. Yeah. I sure showed YOU!

Re:Beta testers (0)

Anonymous Coward | about 7 months ago | (#46528813)

Actually, you were probably modded down because your comments were stupid.
Some users will very likely change their FS away from the default, but many probably will not. The latter would make up the bulk of the group the OP was referring to.

That said, they might not be very good beta testers if the reason they have installed BTRFS is because it is the default, rather than actively choosing it.

Re:Beta testers (0)

Anonymous Coward | about 7 months ago | (#46529419)

I did that with Ubuntu once, didn't work.

So I said...meh, back to EXT4, I don't want to fix it, and I've not tried since.

Re:Beta testers (1)

ls671 (1122017) | about 7 months ago | (#46531609)

I still click on ext3 on new installs....

Re:Beta testers (1)

speculatrix (678524) | about 7 months ago | (#46541923)

pah, ext3 is too new fangled. ext2 was good enough for my grandpa, is good enough for me, and is good enough for my kids. on a serious note, when ext3 was still new, I used to format /boot as ext2 and not ext3 so that all the various rescue disks would be able to fix it.

Re:Beta testers (2)

AvitarX (172628) | about 7 months ago | (#46529931)

More likely scenario,

Most OpenSUSE users use it because they generally like, and trust, the choices of OpenSUSE. This trust may be misplaced, we'll know soon, but in the learning, we'll have a MUCH better understanding of how ready btrfs is to move past the beta testing zone (or if OpenSUSE bosses are right, proven to be past there).

Defaults matter, reputations of Linux distros can shatter on them, because we're not passive users, and thought they aren't all drop in replacements, as non-passive users, they're close enough.

Re:Beta testers (1)

ls671 (1122017) | about 7 months ago | (#46531615)

To be objective; did btrfs got more stable lately? Did suse tweak it?

Re:Beta testers (1)

AvitarX (172628) | about 7 months ago | (#46532541)

I'm pretty sure that it's constantly getting more stable, and if OpenSUSE is using it, they probably did vet it.

I'm pretty sure the only point of distros like OpenSUSE or Fedora are to get wide testing on new technologies (this is good, and running them is a great way to give back to the community).

I would guess that in a year btrfs is going to be the default in general, but it takes someone to make the leap of faith to start that rolling. If no main stream distro adopts ever, it will by tautology never be the default.

Props to OpenSUSE!, good luck to their users, or more realistically, not bad luck.

Re:Beta testers (3, Interesting)

complete loony (663508) | about 7 months ago | (#46529383)

I've lost data with btrfs, but I did have a failing drive that I didn't notice was going bad. I didn't have a redundant copy of meta-data and couldn't seem to change that.

All of those things have changed since then. You can set up a cron job to scrub your data instead of being blind to sectors going bad. And you have much better control over the redundancy of your data.

Re:Beta testers (2)

relisher (2955441) | about 7 months ago | (#46530811)

BTRFS inode limitations once cause my system to go completely bonkers. I lost a huge amount of data due to a "limitation of space" when in reality it was an inode limit.

Re:Beta testers (0)

Anonymous Coward | about 7 months ago | (#46532999)

BTRFS microwaved my cat and caused my wife to leave me for my lawyer !

Re:Beta testers (1)

PincushionMan (1312913) | about 7 months ago | (#46535665)

I'd leave you for my lawyer too, if you let BTRFS microwave me!

Lost data recently (1)

sl3xd (111641) | about 7 months ago | (#46534763)

I've lost data recently with btrfs, in the past two weeks. Redundant metadata & data didn't help me. Neither did the snapshots.

Thankfully, I had a backup of the data.

So my review of btrfs: Not ready. Slow. May eat your data.

Re:Beta testers (3, Interesting)

caseih (160668) | about 7 months ago | (#46529397)

Been beta testing BtrFS for about 3 years now. Haven't had any problems. This is home desktop use. All my laptops run it, and I'm starting to use snapshotting more and more. Snapshotting a single VM disk image file is very handy.

Re:Beta testers (0)

Anonymous Coward | about 7 months ago | (#46530617)

Just out of interest, how does BTRFS cope with sudden power loss and fragmentation in recent kernels?

I tried it, converting my Ext4 partitions to BTRFS during the 3.0 days. A X.org/NVidia hang forced me to pull a MagicSysRq+REISUB, and then my /home went all corrupted. The BTRFS kept on complaining about a wrong journal, and after flushing that as per the wiki suggests, missing superblocks. It was nightmare for me.

Is the filesystem more resilient nowadays? Does it still somehow erroneously report 200% filesystem usage in df (as in the 3.0 days)?

How is the desktop performance as well? Back then I was all hyped up for the compression support, thinking it'll really help my slow HDD but adequately powerful Core2Duo setup. The result was horrible fragmentation due to the copy-on-write design, and horrendous I/O performance as compared to Ext4. But I guess that was earlier days. How is BTRFS now?

Re:Beta testers (4, Interesting)

Menkhaf (627996) | about 7 months ago | (#46531701)

I experimented a bit with btrfs some months ago as part of my parttime job at my university. The departments file server had disk failures after a power glitch, so I decided to rebuild it and add in a UPS. I'm running Debian jessie on the system, which is just a small 2U SuperMicro rack case with 12 3 TB SATA drives and 16 GB ECC RAM. ZFSonLinux needs a fairly recent kernel, otherwise I'd probably have gone with stable.

I was initially pretty impressed with btrfs, but before the UPS arrived there was another power glitch (which is fairly unusual in these parts of the world; northern Europe) and it completely trashed btrfs. I was unable to mount, scrub or do anything productive to the FS. Absolutely no luck doing anything.

After that I've switched to ZFS. I'm really happy with ZFS, even though ZFS on Linux still has some bugs. For some reason zfs threads sometimes crash when doing zfs send | zfs receive, something I've noticed a few times. Performance is pretty good. For reference I'm using raidz3. My offline, off-site backup is done on a clone of the server (OS only) and uses zfs send and receive to transfer the ZFS snapshots which are done nightly.

Re:Beta testers (1)

torsmo (1301691) | about 7 months ago | (#46535303)

I use btrfs for /home, and I'm currently in a place (high mountains) where sudden power outages are not uncommon. Besides power loss, there's a problem with fluctuations in voltage as well (this place doesn't have a UPS or even a stabilizer). So on a few occasions, the btrfs partition has refused to mount after encountering the above scenario ("parent transid verify failed on ..."). But to be fair, that borked the root fs mounted on ext4 as well. I think I followed some instructions suggested on a stackoverflow thread, and was able to get full functionality back without any loss of data. I would say it has reasonably good fault tolerance. It is a bit slow compared to other more mature fs's, but still very satisfactory. Oh, and the kernel version is 3.12

Re:Beta testers (5, Interesting)

buchner.johannes (1139593) | about 7 months ago | (#46529617)

You can create a file system on a file on your disk (similar to a swap file).
Contrary to popular believe this is not slower than a partition, because if the file is mostly continuous, it can be mapped to disk directly by the kernel. Here I create a file system using a sparse file:
$ truncate +20G mylocal.fs
$ mkfs.btrfs mylocal.fs
$ mkdir -p mylocal; sudo mount mylocal.fs mylocal/

You can use such file systems, for example, to bundle directories with many files, which are deleted/created many times. This causes fragmentation in the file system. Contrary to another popular believe, yes, this is a problem on Linux file systems, and it slows down reads. None of the file system currently has a defragger implemented. Btrfs is actually developing one, but I think it is not in the release yet. The recommended solution is rewriting files (shake [vleu.net] ).

Sub file system containers can be easily resized, and with sparse files only use up the space filled with data. I use them for the linux kernel build directory (you shouldn't build in /usr/src), for portage (many files, changing frequently), and scientific data directories, to limit the fragmentation, and keep speed high. I use reiserfs for this -- find a managing script here: https://github.com/JohannesBuc... [github.com]

Re:Beta testers (1)

felipou (2748041) | about 7 months ago | (#46531619)

Damn, man, your comment surely should have a higher than five rating.

You should definitely make a blog post about this!

Re:Beta testers (1)

vikingpower (768921) | about 7 months ago | (#46532069)

Absolutely agree. This guy could earn good money as a Linux guru.

Re:Beta testers (1)

Anonymous Coward | about 7 months ago | (#46538363)

"autodefrag" seems to habe been in since 3.0:
https://btrfs.wiki.kernel.org/index.php/Mount_options

Re:Beta testers (0)

Anonymous Coward | about 7 months ago | (#46560945)

So BTRFS is just like all other FS then, they have a defrag in development.

Oh I would not sparse create your file system with 'touch', it might seem faster, but you are not guaranted the blocks will exist when the inner file system needs to write to that block, file systems do not cope with this kind of error as they expect their block device to have the number of blocks available. Instead use the slower use of "dd bs=1k count=20G if=/dev/zero of=mylocal.fs" to ensure you allocated ever block on the outer file system.

Keep working on that Linux guru badge though.

Re:Beta testers (-1, Troll)

Flammon (4726) | about 7 months ago | (#46530265)

fuck beta

Re:Beta testers (1)

evilviper (135110) | about 7 months ago | (#46531893)

OpenSUSE users beta test EVERYTHING for everyone. I thought Fedora was bad, but OpenSUSE puts them to shame...

Re:Beta testers (1)

speculatrix (678524) | about 7 months ago | (#46541941)

I've used opensuse for many years, I guess because when I wanted to adopt the linux desktop, a colleague used it so I did too.

I usually lag behind new releases by months, unless I'm setting up a new computer and so I don't have anything to lose

our experience at work of BTRFS having poor and inconsistent performance have put me off ever using it personally except as experimental. OTOH, we found ZFS to be very good.

Re:Beta testers (1)

Eunuchswear (210685) | about 7 months ago | (#46532101)

Pah. My phone uses btrfs.

Re:Beta testers (1)

g1zmo (315166) | about 7 months ago | (#46544793)

FWIW, Netgear's ReadyNAS [readynas.com] lines have been using btrfs for about a year now.

Ambitious, I'll give them that. (0)

Anonymous Coward | about 7 months ago | (#46528277)

I'd give you good odds that the November release date is optimistic though. I also hope you weren't expecting to run btrfs on RAID.

OpenSUSE 13.2 To Crash and Burn By Default (-1)

Anonymous Coward | about 7 months ago | (#46528297)

God speed.

Re:OpenSUSE 13.2 To Crash and Burn By Default (-1, Offtopic)

Barsteward (969998) | about 7 months ago | (#46531721)

no such thing as "god"

But then again, they were also big ReiserFS fans. (3, Funny)

fustakrakich (1673220) | about 7 months ago | (#46528399)

I don't get it. Is Chris Mason about to murder his wife/girlfriend?

Re:But then again, they were also big ReiserFS fan (2)

RITjobbie (211397) | about 7 months ago | (#46530281)

He _did_ used to work at Namesys for Hans. Joking aside, his wife is pretty cool. She teaches IT/networking at my alma mater, RIT. I've met a few other (now former) Namesys employees in the past, probably some of the brightest minds I've ever known.

Re:But then again, they were also big ReiserFS fan (0)

bussdriver (620565) | about 7 months ago | (#46531493)

Why can't Reiser continue? Just because he is in prison? WTF not? It's not like he has anything else to do now. Just because he can't be allowed near future wives and society says he must be punished does not mean he can't contribute to society.

Re:But then again, they were also big ReiserFS fan (0)

wonkey_monkey (2592601) | about 7 months ago | (#46531831)

Why can't Reiser continue? Just because he is in prison?

Yes, exactly because he's in prison, where they don't allow you your own personal computer hardware or general access to the internet.

Shocking, I know. They'll be locking him in at night next!

Re:But then again, they were also big ReiserFS fan (1)

tlhIngan (30335) | about 7 months ago | (#46534327)

Why can't Reiser continue? Just because he is in prison?

Yes, exactly because he's in prison, where they don't allow you your own personal computer hardware or general access to the internet.

Shocking, I know. They'll be locking him in at night next!

You don't need a PC to code. Seriously, you don't. If he's allowed visitors and they can leave him printed materials, that's all that's needed to code.

Hell, he can sit and think through a lot of the flaws of the filesystem by doing it all mentally or on paper the passing criticism or design updates to his visitors.

You don't have to start coding anything by having an idea, starting up an editor and beginning from int main(). You can start development by documenting the idea, the design, implementation and then work out if the design has flaws. And all of it can be done without a computer.

Immunity from Prosecution! (-1, Flamebait)

turgid (580780) | about 7 months ago | (#46528437)

In addition to all those wonderful cutting-edge features, Microsoft promises not to sue you for patent infringement on all that Imaginary Property from Windows (the pinnacle of human technological achievement) that was stolen for use in Linux.

What more could you ask for?

tm abbrevs mk it hrd 2 rd. (0)

Anonymous Coward | about 7 months ago | (#46528465)

so how long did openSUSE use EXT4 prv. with KDE 4 and prev Qt5 frontends with YaST b4 2 btrfs? wht r adv. to use btrfs vs. EXT4? hoping OpenSUSE ships w/ dictionary 4 abbrev.s!

Re:tm abbrevs mk it hrd 2 rd. (0)

Anonymous Coward | about 7 months ago | (#46528557)

openSUSE = Linux distribution
EXT4 = most current open journaling filesystem in widespread use on Linux systems
btrfs = journaling filesystem with more bells and whistles than ext4
reiserfs = journaling filesystem from before ext4 was released, had many of the same problems btrfs is having right now
Wayland 1.4 = X Windows System replacement, an urgently needed update to a display system written to requirements over two decades old
KDE Frameworks 5 = Windows 7 for Linux
Qt5 = Windows theme
frontend to YaST = graphical utility to a command line version of Windows' add/remove programs dialog

Re:tm abbrevs mk it hrd 2 rd. (-1)

Anonymous Coward | about 7 months ago | (#46528661)

thx 2 anon. cwrd 4 abbrv. --> english transl.!

Re:tm abbrevs mk it hrd 2 rd. (2)

Wolfrider (856) | about 7 months ago | (#46530547)

--A fairly accurate summation. I would only amend it thusly:

EXT4 = most current open journaling filesystem in widespread use on Linux systems; Successor to ext3 and generally faster

btrfs = journaling filesystem with more bells and whistles than ext4; Functionally designed to compete with (and mostly equivalent to) ZFS, and may have more features for home/average non-Enterprise users

frontend to YaST = graphical utility to command line versions of various Linux setup/configuration tools

Re:tm abbrevs mk it hrd 2 rd. (1)

WuphonsReach (684551) | about 7 months ago | (#46531047)

Successor to ext3 and generally faster

Create a (non-sparse) 1GB or larger file on ext3. Then time how long it takes to delete it. For large file handling, ext4's use of extents rather then allocating individual blocks is far superior to ext3. (It's not an edge case either these days, not with MKV & MP4 files measured in 100s of megabytes. Or disks measured in terabytes.)

Plus you get the faster fsck times at boot. And a bunch of other useful features (shrink/growing the file system, faster handling of directories with lots of files inside, etc.)

All in all, ext4 is pretty darned good for its purpose of storing files. And while I'm looking forward to BTRFS, it's just not ready yet, and ext4 serves me well enough.

Re:tm abbrevs mk it hrd 2 rd. (1)

Eunuchswear (210685) | about 7 months ago | (#46532123)

[ext4 vs ext3] a bunch of other useful features (shrink/growing the file system, faster handling of directories with lots of files inside, etc.)

Uh, ext3 has online grow (but not shrink). Does ext4 do online shrink?

And ext3 hahes big directories for faster access too.

Not that there are no advantages, but you seem to be claiming ones that don't exist.

Re:tm abbrevs mk it hrd 2 rd. (2)

Barsteward (969998) | about 7 months ago | (#46531729)

so you'd agree with his definition of KDE Frameworks and QT5?

If you live on the bleeding edge (1)

Anonymous Coward | about 7 months ago | (#46528469)

Be prepared to bleed.

Re:If you live on the bleeding edge (1)

rubycodez (864176) | about 7 months ago | (#46530847)

Hans, is that you?

An inspiring decision (2)

MoonlessNights (3526789) | about 7 months ago | (#46528725)

It surprising but nice to see someone stepping outside of the "just do what we have done before" box but I suppose there is precedent for SUSE (given the mention of ReiserFS).

Personally, I have been using BTRFS on a few of my systems for a little over a year and it is quite nice. Later versions have some really intriguing snapshot delta capabilities but my main win, with a slightly older version, is the big benefit of reduced disk I/O via transparent compression.

The way that it manages storage pools looks good, as well, although I haven't tried playing with it yet (the systems using it have lopsided disk geometries so it wouldn't be appropriate).

Re:An inspiring decision (0)

Anonymous Coward | about 7 months ago | (#46528925)

Red Hat can't get the stability and/or performance out of it - they are going with XFS.

I would be inclined to agree.

Re:An inspiring decision (1)

fnj (64210) | about 7 months ago | (#46529367)

Red Hat can't get the stability and/or performance out of it - they are going with XFS.

Quite possibly Red Hat intends to GA RHEL7 before November and it doesn't give them as much time for testing as OpenSuse has. Other than the simple fact that RHEL and Suse are enterprise, and OpenSuse is not.

I sure as hell won't be using Btrfs for any data I care about in the foreseeable future (not through 2015 at least). I consider Zfs On Linux [zfsonlinux.org] to be much more reliable and well-tested as well as far superior.

Re:An inspiring decision (0)

Anonymous Coward | about 7 months ago | (#46529461)

Red Hat can't get the stability and/or performance out of it - they are going with XFS.

Quite possibly Red Hat intends to GA RHEL7 before November and it doesn't give them as much time for testing as OpenSuse has. Other than the simple fact that RHEL and Suse are enterprise, and OpenSuse is not.

I sure as hell won't be using Btrfs for any data I care about in the foreseeable future (not through 2015 at least). I consider Zfs On Linux [zfsonlinux.org] to be much more reliable and well-tested as well as far superior.

Putting BTRFS as a default file system is just idiotic (even moreso coming from a distribution such as Suse). Right now I'd say the best file systems on linux are XFS followed by EXT 4 in terms of reliability and performance. BTRFS is new and shiny, but it's a 2 legged horse. Not something that speaks well for reliability. I'd have expected such a move from Fedora not from Suse.

Re:An inspiring decision (1)

grumbel (592662) | about 7 months ago | (#46529857)

Does XFS still shred your files on system crashes or power loss? FAQ claims they fixed that in 2.6.22, yet with 2.6.27 it was still shredding files like crazy for me. This was however years ago, has anything changed still then?

Re:An inspiring decision (1)

rubycodez (864176) | about 7 months ago | (#46530861)

no

but recently there was little bug where xfs_growfs would sometimes panic kernel (filesystem recoverable)

it's been fixed

Re:An inspiring decision (0)

Anonymous Coward | about 7 months ago | (#46539653)

Define "shred data".

Do you mean that your app doesn't flush data out from the cache to disk?

Re:An inspiring decision (1)

grumbel (592662) | about 7 months ago | (#46541363)

"Shred" as in files getting cut to 0 bytes. With XFS there was a 50/50 chance that your desktop wouldn't boot after a powerloss as half the config files where suddenly empty.

Re:An inspiring decision (0)

Anonymous Coward | about 7 months ago | (#46547805)

This happens when retarded developers don't sync metadata an file contents. If something is really writing to grub, kernel, initrd, fstab, etc so that your machine won't start then you have other problems.

If your home directory is messed up then blame desktop devs.

Been using XFS for >15 years on IRIX and Linux - no issues.

Re:An inspiring decision (1)

Dcnjoe60 (682885) | about 7 months ago | (#46529275)

How is the btrfs speed compared to ext4 in your experience? Most tests I see has it slower with the explanation that it actually does more than ext4. Many of us still have magnetic drives instead of SSDs so, speed could be an issue. On the otherhand, reduced disk I/O should be a speed improvement. So, how does it perform?

Re:An inspiring decision (1)

DuckDodgers (541817) | about 7 months ago | (#46537755)

I can't speak to its reliability because I only used it a little bit. But in terms of features, from what I understand it the two killer features that slow btrfs down by make it so attractive (assuming it doesn't corrupt your files) are snapshots and live volume resizing. Those two things do what you might from the name - snapshots let you tag a certain point in time in the filesystem, and in the future you can revert your filesystem to look exactly as it did at that point in time. That is of course incredibly handy in the case of failed upgrades or accidental file deletions. Live volume resizing lets you grow and shrink partitions and I believe even add an additional storage device to an existing btrfs volume while the system is still mounted.

I think the slowdown versus ext4 is measurable but not killer, 5-10%. I'm more concerned with the stability.

Re:An inspiring decision (1)

MoonlessNights (3526789) | about 7 months ago | (#46546549)

Yes, the ability to add/remove storage devices is done on the live file system.

I haven't played with it myself but I know that there was talk of using this for OS installation (beyond the more obvious live disk replacement possibility):
-boot from live DVD
-start installation is just "add new device to pool" (returns immediately), followed by "remove DVD device from pool"
-the "remove" doesn't return until it has finished migrating (and possibly balancing, if you added several devices as the target)
-once "remove" finishes, it ejects the DVD and tells you that installation has completed

It is neat since it means that your installation is "complete" at the moment you tell it to "start". You can start using the system immediately without waiting for the installation to actually write anything and no reboot is required.

Re:An inspiring decision (1)

DuckDodgers (541817) | about 7 months ago | (#46571297)

Very cool, thanks for letting me know about that.

Re: An inspiring decision (-1)

Anonymous Coward | about 7 months ago | (#46531381)

It surprising but nice to see someone stepping outside of the "just do what we have done before" box but I suppose there is precedent for SUSE (given the mention of ReiserFS).

Personally, I have been using BTRFS on a few of my systems for a little over a year and it is quite nice. Later versions have some really intriguing snapshot delta capabilities but my main win, with a slightly older version, is the big benefit of reduced disk I/O via transparent compression.

The way that it manages storage pools looks good, as well, although I haven't tried playing with it yet (the systems using it have lopsided disk geometries so it wouldn't be appropriate).

Surprising... to see us deploying a ZFS clone some ten years later? How is copying the leader "outside the box" in any way for Linux?

The real applaudable thing here happened years ago when someone decided to ape ZFS. THAT guy deserves the pat on the back, not the lazy Linux vendors sitting around waiting for change to happen for them.

When other systems stop clearing trails for Linux, where will it go then? I've noticed man page quality has gone down the shitter, and common utilities don't honor unix conventions like return codes.. *cough*yum*cough* Linux is utterly uninspiring.

Someone is going to pull a server "Android" on it sooner or later, and while you can still call it "Linux" if that makes you feel better, it's not going to be this community orchestra crap we've got now where you feel the need to congratulate them for trying.

Dangerous (0)

Anonymous Coward | about 7 months ago | (#46529199)

Being a huge ZFS fan, I would love to see some competition with the opensource btrfs, but having had it corrupt data pretty quickly after playing with it... This is a dangerous move for OpenSUSE. When you talking filesystems, you should only ever DEFAULT to one that is tried and true.

Re:Dangerous (-1)

Anonymous Coward | about 7 months ago | (#46529537)

btrfs is nowhere near ready for prime time, and I keep reading reports about corruption here and there.

This is where Linux just plain falls short. Even Microsoft has Storage Spaces and ReFS which used in combination can detect and repair bit rot.

Linux is vulnerable to silent data corruption and bit rot. Linux also has no viable deduplication or snapshotting mechanisms.

There is hope... there is OpenZFS for Linux... except it hasn't been touched since August 23 of last year. If this gets going and becomes a part of the Linux kernel, it will bring the OS into this decade.

Re:Dangerous (-1)

Anonymous Coward | about 7 months ago | (#46530867)

OpenZFS for linux has been getting regular commits to its github repo, the last one being about a week ago. It's just the ZFS on Linux web page that hasn't been updated.

Sadly, ZFS won't get into Linux kernel unless its CDDL license changes, which is highly unlikely for many compelling reasons. This subject has been addressed many times and is also explained in the OpenZFS and ZFS on Linux FAQ sections.

That being said, the OS you speak of is well into this decade, ZFS or no ZFS, file systems included.

Re:Dangerous (0)

Anonymous Coward | about 7 months ago | (#46577069)

ZFS may not ship with the kernel but that doesn't mean you can't use it.

Re:Dangerous (0)

Guspaz (556486) | about 7 months ago | (#46530901)

The American sequestration didn't help ZFSonLinux, since the primary developer is Lawrence Livermore National Laboratory (a research lab funded by the US government). But the pace of development has been pretty constant:

https://github.com/zfsonlinux/... [github.com]

Just because the last stable build was released in 2013 doesn't mean there hasn't been work done.

Too Slow (1)

AaronW (33736) | about 7 months ago | (#46529743)

I tried setting up btrfs about a year ago on one of my servers running imap (which is continually backed up). I gave up in disgust since btrfs was insanely slow just untarring all of the files (Cyrus Imap stores each email as a separate file). This was on a relatively fast Intel SSD drive. As more and more files were added, the speed continued to drop.

The other problem I have is that I could not find an adequate answer with respect to free space. When files are deleted it sounds like they really aren't deleted. This being the case, what happens when the drive fills up?

I have since gone back to using XFS and EXT4 for my files. I have never had any issues with XFS (even when some nasty RAID issues occurred) and have been running it for years and love the tools available for it (xfs_fsr, xfsdump, etc.).

Because they have picked file system winners be (-1)

Anonymous Coward | about 7 months ago | (#46529751)

When is Reiser getting out of prison for murder, anyway?

Have they fixed the need to manually rebalance? (4, Informative)

csirac (574795) | about 7 months ago | (#46530551)

I've been using btrfs on all my machines/laptops for more than 2 years now. I've never had corruption or lost data (btrfs has actually coped rather well with failing/dying disks in my experience), unlike ext4. COW, subvolumes and snapshots are nifty.

But too many times I've had the dreaded "no space left of device" [kernel.org] (despite 100GBs remaining) when you run out of metadata blocks. The fix is to run btrfs balance start /volume/path - I now have a weekly cron job on my non-SSD machines - but it's hugely inconvenient having your machine go down because you're expected to babysit the filesystem.

Recent months of Docker usage has made me encounter this condition twice this year already.

I'll continue using btrfs because I've experienced silent corruption with ext4 before which I believe btrfs would have protected me against, and I like snapshots and ability to test my firmware images cheaply with cp --reflink pristine.img test.img.

Re:Have they fixed the need to manually rebalance? (1)

broken_chaos (1188549) | about 7 months ago | (#46531351)

You can run into the same sort of error, if I understand correctly, from other filesystems running out of inodes. Typically the solution there is to know what kind of workload (roughly) you'll be doing with the filesystem, and set the inode-to-block ratio appropriately. I imagine btrfs should have something similar for metadata allocation?

Re:Have they fixed the need to manually rebalance? (0)

Anonymous Coward | about 7 months ago | (#46531867)

I used to get this quite a bit 10 years ago on ext2. The eventual solution was for mkfs to have better estimates :) This comes with time and experience.

Re:Have they fixed the need to manually rebalance? (2)

Swistak (899225) | about 7 months ago | (#46531649)

This is actually a horrible flaw in my opinion. I've also installed btrfs on one of my laptop drives and it was a horrible mistake. If you run out of space it's possible in some edge cases that you won't be able to free your space!
You'd expect `rm huge_file` to work, but no it won't. Some pages recomend echo "">huge_file but that not always help either if the reason the disk got full is metadata
I honestly cannot understand how anyone can create filesystem that A) lies about free disk space B) Does not allow you to free up space when it's full.

RTFM (openSUSE standard answer to everything) (0)

Anonymous Coward | about 7 months ago | (#46570143)

The manuals in openSUSE are one of the main reasons I adore this distro. They explain how to look after your btrfs filesystem quite nicely.

Also a main part of openSUSE that makes btrfs quite usable for less hands-on sysadmins and "ordinary" desktop/laptop users, is it's integration with Snapper. With btrfs, the main culprit in consuming space that I've encountered (on single-device filesystems which you can't "balance"), is actually old snapshots. Snapper takes periodic and strategic snapshots, but it also prunes old snapshots. You can tune how it cleans up old snapshots if the defaults are keeping too many around.

sudo btrfs filesystem show

The first thing to do when your disc space is low on a btrfs system is not du / |sort and then rm huge_file, but instead to snapper list and snapper delete. Without Snapper, btrfs is a lot more manual (a lot like rpm without zypper/yum). I believe this usability is why openSUSE can adopt btrfs as its default, as much as btrfs' stability itself.

Re:Have they fixed the need to manually rebalance? (1)

trynis (208765) | about 7 months ago | (#46531749)

I've been using btrfs on all my machines/laptops for more than 2 years now. I've never had corruption or lost data

How do you know?

Re:Have they fixed the need to manually rebalance? (1)

ssam (2723487) | about 7 months ago | (#46531809)

Because BTRFS actually checks for corruption unlike older file-systems.

Re:Have they fixed the need to manually rebalance? (-1)

Anonymous Coward | about 7 months ago | (#46532275)

So you are using BTRFS to check if BTRFS works correctly?

Re:Have they fixed the need to manually rebalance? (1)

csirac (574795) | about 7 months ago | (#46541569)

ZFS, and BTRFS are designed to cope with bitrot. Perhaps you believe the implementation renders the design ineffective, all I know is that ext4 doesn't even try.

Re:Have they fixed the need to manually rebalance? (0)

Anonymous Coward | about 7 months ago | (#46541903)

ZFS, and BTRFS are designed to cope with bitrot. Perhaps you believe the implementation renders the design ineffective, all I know is that ext4 doesn't even try.

Sorry, I thought ssam's reply was from you and this seemed a little bit strange. Like:

- BTRFS is so mature already, I never lost my data with it
- How do you know?
- BTRFS told me.

The data integrity features of the new file systems are nice only if you can assume them to be bug free.

Re:Have they fixed the need to manually rebalance? (1)

csirac (574795) | about 7 months ago | (#46550331)

BTRFS is so mature already, I never lost my data with it

Dude, nobody said BTRFS is mature. Did you read the part where I've had to manually rebalance several volumes on multiple occasions? I'm sorry that you interpreted this statement as a ringing endorsement of a mature filesystem - but it's not the case that users should have to do this kind of babysitting in a mature technology.

I *have* had BTRFS fill my logs with checksum failures on a couple of dying disks, and I was able to recover everything intact (the bulk of this data had shasums thanks to some deduplication I had been doing months earlier).ext4 on the other hand (by its very design, unless you count recent kernels where metadata may be checksummed) happily allows the disk (or whatever) to take a shit all over your data without so much as the slightest hint that something might be wrong until you go to open a file years later and discover it's zero bytes long, truncated, or full of garbage.

The data integrity features of the new file systems are nice only if you can assume them to be bug free.

No shit. But if your idea of data integrity is to start with something that doesn't even try, there just isn't any hope of that is there?

Filesystem is not SUSE's problem (-1)

Anonymous Coward | about 7 months ago | (#46530931)

I recently tried out 13.1, looking for a nice KDE distro. The desktop was beautiful, everything pretty much worked. The problem was I wanted to install ffmpeg to convert come audio files - nope no ffpmeg available anywhere, not even in enterprise SUSE. It was listed as broken everywhere.

SUSE needs to stop geeking on shit that doesnt matter and spend time on getting some packages into the tree that people actually use.

Make sense (1)

ssam (2723487) | about 7 months ago | (#46531823)

I have been using BTRFS for a while now with no problems. Even been through a couple of unclean shut downs, and unplugging mounted drives.

I suspect that some of people reporting corruption have bad hardware. If they run ext4 the corruption happens, but they never notice. When they switch to BTRFS it spots the corruption quickly because of checksumming, and makes noise about it. Not to say that BTRFS is bug free, but neither is any other file system.

Upgrade woes (0)

Anonymous Coward | about 7 months ago | (#46533647)

I hope the upgrader still works if btrfs is the root volume.

Ugprading from openSuSE 12.1 to 13.1 and SLES 11.2 to 11.3 would not work when booting from a valid install media if / was a btrfs volume. The btrfs disks were found, but the mount points were not. I don't know if this is a bug from the heavy use of subvolumes by openSuSE and SLES or from problems internal to the installer.

For those who haven't tried a VM install, the installer for openSuSE and SLES recommend and by default when installing with btrfs for / will suggest making /var, /usr into btrfs subvolumes. This is a feature much like a cross between an LVM volume and a souped up quota controlled directory. You can snapshot the subvolume separately from the root of the disk, manage their size but also mount the subvolume as the root of the disk. I suspect this later feature - no special root - might not be being handled so gracefully.

SLES also has some serious issues with booting btrfs volumes composed of multiple disks. With LVM, you can slap in an extra disk and expanded a volume group then all contained filesystems across to include the new disk. Your sysem will continue to boot just fine. btrfs can just expand the filesystem to include the new disk. Except that when you boot Linux kernel to a btrfs root or other critical must-mount volume composed of multiple disks a special scan has to be done before the disks can mount. Since the SLES and openSuSE mkinitrd don't handle this case it causes the system to panic and drop to an initrd backed shell.

There is a workaround for multi-volume boot failures by hacking in a special boot script. Once can do this since the SuSE mkinitrd process is heavily over-engineered. (This is a good thing.) Certainly beats trying to manually do the Linux kernel mount process by hand each time you boot up.

Standards? Standards anyone? (-1, Offtopic)

Lord Apathy (584315) | about 7 months ago | (#46533943)

This is a example of some of the mind bogglingly stupid things that linux people do.

What I find funny now is years ago people on this board, myself included, where bashing microsoft for taking known standards and extending them. It was called embrace and extend. Linux at the time was the banner for standards and doing things right.

Now we have a major distro changing from the standard filesystem, ext3/ext4, to what is technically a experimental file system and using as the default install. This is crap that give linux a bad name. Linux will never take the desktop with bone headed decisions such as this.

There is a reason to sick to the ext3/4 filesystem as the standard filesystem. Because it is the standard. Almost every filesystem tool in the linux world expects to be working with ext3/ext4. Sure you have special versions for vanity filesystems such as reiser and this one, but most tools expect ext3/ext4. There is nothing wrong with running a specialized filesystem specialized applications such as databases but not as your main default system. And certainly not a damn beta filesystem.

Of course we are not new to bone head decisions are we when it comes to standards. Like the gnome people deciding that the middle mouse button is no longer important. Something that has been standard in xwindows and unix since it crawled out of the data ooze that spawned it.

Re:Standards? Standards anyone? (1)

Rafael Jaimes III (3430609) | about 7 months ago | (#46536911)

But you do know openSUSE 13.2 is "pretty far away"? It won't be released until November 2014.

Re:Standards? Standards anyone? (0)

Anonymous Coward | about 7 months ago | (#46577099)

July 2014

Re:Standards? Standards anyone? (1)

Lord Apathy (584315) | about 7 months ago | (#46537451)

There is a reason to sick to the ext3/4 filesystem as the standard filesystem. Because it is the standard. Almost every filesystem tool in the linux world expects to be working with ext3/ext4. Sure you have special versions for vanity filesystems such as reiser and this one, but most tools expect ext3/ext4. There is nothing wrong with running a specialized filesystem specialized applications such as databases but not as your main default system. And certainly not a damn beta filesystem.

Not off topic but completely on topic. People are doing stupid things with a experimental filesystem and I'm call it what it is. Stupid.

Re:Standards? Standards anyone? (1)

DuckDodgers (541817) | about 7 months ago | (#46538035)

The ZFS filesystem from Solaris Unix has some features that ext4 does not, especially filesystem snapshots. That gives you the ability to take a filesystem snapshot at a certain date, and if the system has a filesystem problem in the future that is not from a hardware failure, you can instantly revert your filesystem to the snapshot. Here's a common use case: you take a snapshot, then apply a software upgrade to your system. If the upgrade goes well, you snapshot again. If the upgrade fails, you revert to the original snapshot and the system acts as if the failed upgrade never happened.

This is one of the reasons so many big companies use Solaris Unix. Unfortunately, the software license of ZFS prevents it from being incorporated into the Linux kernel by default. You have to download and install it separately.

Adding that feature to ext4 without completely rewriting it is impossible. That's why btrfs was created, to give many of the good features of ZFS to Linux. The thing is, btrfs needs to be battle-tested before businesses will use it on mission critical servers. You have to start somewhere. Maybe OpenSUSE 13.2 is too soon, maybe it needs another few years as alpha software. But maybe all of the people on this forum complaining about file corruption ran into bugs that have already been patched.

Re:Standards? Standards anyone? (1)

Lord Apathy (584315) | about 7 months ago | (#46538299)

The ZFS filesystem from Solaris Unix has some features that ext4 does not, especially filesystem snapshots.

I don't really conceder ZFS to be an experimental fliesystem. I would regard it as a mature and tested file system and I would not have the same issues with someone using it as a specialized file system like I mentioned. But at the same time I wouldn't regard it as a standard file system the same way ext3/ext4 is.

The snapshot feature you mentioned, I admit, would be very handy, but you can achieve the same thing using logical volumes and ext4. Unlike ZFS logical volume management is a standard part of all linux distos. I've not used ZFS so I don't know how complex its snapshot feature is and how it would compare to LVM snapshot feature. Using LVM does add an extra layer of complexities in file system management but if you are using a 3rd party file system then the complexities that lvm adds shouldn't be a problem for someone capable of using ZFS.

Re:Standards? Standards anyone? (1)

DuckDodgers (541817) | about 7 months ago | (#46571333)

I'm sorry if my post was a little confusing - I don't consider ZFS experimental either. I meant that ZFS is a commonly used Unix filesystem that has more features than ext4, and it can't be part of the Linux kernel. btrfs is an attempt to bring ZFS to Linux without violating any software licenses.

I didn't know about LVM snapshots, thanks for informing me. I also didn't realize LVM supports adding and removing storage devices to the volume while the system is live. I considered snapshots and growth and shrinking of storage the two killer btrfs features, and now I see that one can get those from LVM + ext4.

Okay, I find the argument for adapting btrfs as a primary filesystem weaker. I hope there's something I'm missing.

Mavi Teknik Servis 0530 119 5 229 (0)

Anonymous Coward | about 7 months ago | (#46542147)

Mavi Teknik Servis [maviteknikservis.com] Siz Degerli Müsterilerine Hizmet Vermek için istanbulun Bütün Bölgelerine Servis Göndermektedir.
letisim çin 0530 119 5 229 Numarali Hattan 7 Gün 24 Saat Arayabilirsiniz. Mavi Teknik Servis
Uzman Kadrosu ve Tecrübeli Teknik Elemanlari ile istanbul Halkinin Hizmetinde

Download and testing (0)

Anonymous Coward | about 7 months ago | (#46582019)

Today I am testing openSUSE 13.2 M0, and reports.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?