Announcement

Collapse
No announcement yet.

Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Thanks for all the answers!

    I think I'll stick with ext4 for my machines for a bit longer, still. I find the idea of snapshots and compression interesting, but without proper space management by the filesystem it just seems like a way to hit troubles.

    I do wish they added data checksums to ext4. If something gets me onto btrfs, it'll be that.

    P.s.: As an aside I also have a 4tb*3 raidz on zfs and although it works nicely, performance could be a bit better, and god help you if you try to use zfs on a 32bit system --- it tries to work then fails miserably. I use these disks to backup other machines and for 32-bit machines I have to backup them over the network instead.

    Comment


    • #42
      Originally posted by Stellarwind View Post
      There is not much to flame about.

      His argument against ZFS is that you can't ship it with distribution, but that doesn't stop NVidia modules.
      Otherwise it works and only suffers from some memory problems on Linux, which are being worked on. Nothing as bad as some people claim.

      Arguments for btrfs are that it is supported by Oracle (last time I checked not for their own database), license and that it mostly works if you use it for very basic scenarios (raid0,raid1), which is not very convincing at least for me.

      In the end, if you want stable cow fs that won't eat your data suddenly, raidz (raid5,6) - you pick ZFS. If you are feeling lucky, want to play with fire and have backups - you pick btrfs.
      Also, ZFS is one of two filesystems (and the one decently performing one) that can be used on all of the major *nixes of today. Fun fact. Linux, OS X (OpenZFS for OSX is a new but stable thing), BSD (pretty sure all of them but mostly FreeBSD, Solaris (although not as major, it still works on it considering it was originally developed for it). NTFS-3G works on pretty much anything too, but the CPU usage on the FUSE stuff is too much and it's lack of a lot of things make it non-practical.

      Comment


      • #43
        stability please

        im using ext4 for everything on a home server with some raid-0's and some raid 1's and other fss on ssd's. Ive never had a crash or any other issue, ever. Because i use it for family photos videos etc and important docs, i dont ever want to hear "not stable".

        I messed around with brfs 5-6 years ago and thought it was da shit. Really, I love it to bits man, and cant wait to start using it on my 6 drives, but i aint moving jack squat till someone says that it is rock solid. period. if they get most of the cool features to rock solid stage then ill migrate even if they have some features that i dont need that are not fully stable... as long as they are crystal clear on which exact features are not 100% solid. if i see any comments anywhere about "minor corruption" it'll just put me off again. When was the last time you heard that about ext4?

        If I feel like this about my own server, how can anyone consider moving to btrfs in an enterprise for a production server? What has Oracle done to make it production worthy on Oracle Linux?? What the hell is Chris M up to? is he deep into feature creep without fixing the core stability issues? Facebook giving him to much stuff to do not fs related? (If he still works there even. I lose track). Im no developer, and i imagine its hard work, but its been many years since we all thought it was good enough to use for testing with minor problems, but it doesnt seem to have moved on from there.

        Comment


        • #44
          Originally posted by Vax456 View Post
          And I've been out having sex with women.
          </doesn't have to be smug>
          As have we - what did you think Gentoo users did while waiting for portage to emerge packages? :P

          Originally posted by 0xBADCODE View Post
          It could be much wise idea just add as much RAM as you can afford and forget swap files/partitions, preferrably forever. Dozen and half of gigz RAM would usually do without swap file at all.
          Actually, if you want hibernation to work, you need at least as much swap as you have RAM. I do agree that swap partitions are preferable to swap files though.

          Comment


          • #45
            Originally posted by dweigert View Post
            You should NEVER use any swap files on a btrfs filesystem - it will hose the filesystem badly.
            AFAIK it will do no such thing. Simply Linux will refuse to use any swap files on Btrfs, citing holes.

            Comment


            • #46
              Originally posted by Stellarwind View Post
              There is not much to flame about.

              His argument against ZFS is that you can't ship it with distribution, but that doesn't stop NVidia modules.
              Otherwise it works and only suffers from some memory problems on Linux, which are being worked on. Nothing as bad as some people claim.

              Arguments for btrfs are that it is supported by Oracle (last time I checked not for their own database), license and that it mostly works if you use it for very basic scenarios (raid0,raid1), which is not very convincing at least for me.

              In the end, if you want stable cow fs that won't eat your data suddenly, raidz (raid5,6) - you pick ZFS. If you are feeling lucky, want to play with fire and have backups - you pick btrfs.
              ZFS, the Zealot's File System

              I like it, use it, it has many things going for it but the uncritical die-hard adoration some of its less informed users devote to it borders on the irrational. It absolutely does have memory problems, not just on Linux but even on Solaris. It *CAN* eat data, in the same cases as BTRFS or pretty much any other FS in existence - specifically if a failure occurs between the moment data blocks are written on disk and the COW commit. I'm not that familiar with BTRFS but as I understand it, it uses "log trees", which are kinda small, simplified, fast, local B-trees where metadata are stored on-the-fly and remain there until a grand commit is made, which, bugs aside, would make BTRFS even *LESS* likely to lose data than ZFS.

              ZFS is also block based, not extent based (with a kludgey hack to aggregate smaller blocks into larger ones) and as such less suitable than BTRFS for extremely large files (HD movies etc.) On the other hand, this ensures marginally lower overhead than BTRFS for random writes (e.g. overwriting part of an existing file).

              My main grief against ZFS is its lack of support for genuine xattrs. It pretends to have them, but they are really just separate files in a hidden directory. Any setxattr() or getxattr() thus essentially entails a full file path resolution and is SLOW. It may not matter in many usage scenarios but for something like SELinux, which relies on real xattrs (fast & atomic), the overhead makes ZFS unusable.

              BTRFS also already has some nice features that ZFS does not. Personally I love reflinks and being able to enable/disable COW for individual files (a Godsend for VM images!). Changing the RAID level of a live FS dynamically is pretty cool too.

              Comment


              • #47
                Originally posted by rdnetto View Post
                Actually, if you want hibernation to work, you need at least as much swap as you have RAM. I do agree that swap partitions are preferable to swap files though.
                I prefer suspend-to-RAM on my notebook. Because storing and readin dozen and half gigz to slow notebook HDD each and every time system goes to powersave looks like really moron idea to me. And I don't give it a fsck on my desktop at all.

                P.S. but one valid point in this thread stands: CoW-backed swap file is really-really-really wrong idea. IIRC, Btrfs does not even supports swap files at all on its own. Though you can work it around via using loop devices but it would kill performance even more and then at least you'll need to disable to CoW for that file (unless you're ***really*** in mood to shot your own leg).

                Hint: you can disable CoW for some particular file by doing chattr +C /your/file but it have to be done before file has been allocated any actual data blocks (means zero-sized file). So if someone really wants some weird configuration, they theoretically can get some swap running on btrfs and even not totally wrecking it, but still, that's weird idea.

                P.P.S. as for shipping and somesuch: it's not hard to guess why I prefer AMD and Intel graphics, isn't it? F...k you Nvidia, one can't even get plug-n-play operation with nvidia cards. In 2014!!! It's just amazing how Nvidia lacks respect of their customers :\.
                Last edited by 0xBADCODE; 20 August 2014, 09:16 PM.

                Comment


                • #48
                  Originally posted by Stellarwind View Post
                  His argument against ZFS is that you can't ship it with distribution, but that doesn't stop NVidia modules.
                  That's not the case. The license forbids merging ZFS into the main kernel source, but that's all. Exactly like the nvidia driver you mention, nothing prevents you from shipping ZFS with a distro provided that is is packaged separately from the kernel itself. For example Debian does just that, ZFS is included in its official repos and can be enabled simply by typing apt-get install zfs.

                  Comment


                  • #49
                    Originally posted by jacob View Post
                    ZFS, the Zealot's File System

                    I like it, use it, it has many things going for it but the uncritical die-hard adoration some of its less informed users devote to it borders on the irrational. It absolutely does have memory problems, not just on Linux but even on Solaris. It *CAN* eat data, in the same cases as BTRFS or pretty much any other FS in existence - specifically if a failure occurs between the moment data blocks are written on disk and the COW commit. I'm not that familiar with BTRFS but as I understand it, it uses "log trees", which are kinda small, simplified, fast, local B-trees where metadata are stored on-the-fly and remain there until a grand commit is made, which, bugs aside, would make BTRFS even *LESS* likely to lose data than ZFS.

                    ZFS is also block based, not extent based (with a kludgey hack to aggregate smaller blocks into larger ones) and as such less suitable than BTRFS for extremely large files (HD movies etc.) On the other hand, this ensures marginally lower overhead than BTRFS for random writes (e.g. overwriting part of an existing file).

                    My main grief against ZFS is its lack of support for genuine xattrs. It pretends to have them, but they are really just separate files in a hidden directory. Any setxattr() or getxattr() thus essentially entails a full file path resolution and is SLOW. It may not matter in many usage scenarios but for something like SELinux, which relies on real xattrs (fast & atomic), the overhead makes ZFS unusable.

                    BTRFS also already has some nice features that ZFS does not. Personally I love reflinks and being able to enable/disable COW for individual files (a Godsend for VM images!). Changing the RAID level of a live FS dynamically is pretty cool too.
                    Also, as the slides mention, ZFS could have patent issues. Something I didn't know about until now.

                    Comment


                    • #50
                      Originally posted by xeekei View Post
                      Also, as the slides mention, ZFS could have patent issues. Something I didn't know about until now.
                      Yeah well. It quite possibly does have some patent issues, but so does helloworld.c

                      Comment

                      Working...
                      X