Announcement

Collapse
No announcement yet.

Btrfs In Linux 3.10 Gets Skinny Extents, Quota Rebuilds

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

  • Btrfs In Linux 3.10 Gets Skinny Extents, Quota Rebuilds

    Phoronix: Btrfs In Linux 3.10 Gets Skinny Extents, Quota Rebuilds

    The Btrfs file-system pull request by Chris Wilson has been submitted for inclusion into the Linux 3.10 kernel...

    http://www.phoronix.com/vr.php?view=MTM2OTI

  • #2
    Originally posted by phoronix View Post
    Phoronix: Btrfs In Linux 3.10 Gets Skinny Extents, Quota Rebuilds

    The Btrfs file-system pull request by Chris Wilson has been submitted for inclusion into the Linux 3.10 kernel...

    http://www.phoronix.com/vr.php?view=MTM2OTI
    Chris Wilson???

    Should be Chris Mason.
    Last edited by jwilliams; 05-09-2013, 06:05 PM.

    Comment


    • #3
      I've been hearing about BTRFS for years, but it seems it is not fully stable, yet they throw new features with each kernel version... am I missing something ?

      Comment


      • #4
        Originally posted by wargames View Post
        I've been hearing about BTRFS for years, but it seems it is not fully stable, yet they throw new features with each kernel version... am I missing something ?
        Not really, people work on what they want to work on. Someone on the dev team is gonna be OCD about fixing every bug, for someone else apparently the extents tree was too big for their uses / likes so they changed it, for someone else apparently quotas weren't working quite right so they changed them. All of the major issues about BTRFS have been worked out, im running it on my home server and the only thing that bugs me is there's no fsck.btrfs (but there is btrfsck) and grub-mkconfig freaks out about btrfs being split over two drives but it still properly makes the grub.cfg and boots just fine.

        Comment


        • #5
          Originally posted by wargames View Post
          I've been hearing about BTRFS for years, but it seems it is not fully stable, yet they throw new features with each kernel version... am I missing something ?
          Its not stable?
          I've been running it for a year without issue.

          Comment


          • #6
            Originally posted by dalingrin View Post
            Its not stable?
            I've been running it for a year without issue.
            The question is: have you found it to be better than ext4 ?

            Comment


            • #7
              Originally posted by wargames View Post
              The question is: have you found it to be better than ext4 ?
              In my experience, definitely.

              Comment


              • #8
                Originally posted by dalingrin View Post
                Its not stable?
                I've been running it for a year without issue.
                There's multiple definitions of software stability. One talks about reliability. In this case it talks about rate of development.

                Comment


                • #9
                  Originally posted by wargames View Post
                  The question is: have you found it to be better than ext4 ?
                  I use BTRFS on my large storage drives. i have a btrfs 'raid1' across 3x 3TB drives. btrfs checksums all the data, which gives me confidence that its safe. having the raid in the filesystem means that scrubs or repairs only needs to look at blocks that are actually used. it also means that if the 2 copies differ the filesystem knows which one is correct.

                  the only problem i have ever hit is when i moved added a second drive to an existing btrfs filesystem, and re-striped it to be raid1. I forgot (and the tools did not tell me) to make the metadata raid1 (it was still DUP). when I tried to replace one of the drives (due to SMART errors) there was not a full copy of the metadata on the second drive. I had to put the failing drive back in, re-stripe the metadata and then replace the disk. all went fine and no data was lost. but it would be nice if the tools made sure your metadata was at least as redundant as the data.

                  Comment


                  • #10
                    I have been wanting to change for a while now.

                    So would a btrfs filesystem with LZO compression and LVM encryption be reliable?

                    Comment


                    • #11
                      Or should I use another mode of encryption?

                      Comment


                      • #12
                        Originally posted by ᘜᕟᗃᒟ View Post
                        So would a btrfs filesystem with LZO compression and LVM encryption be reliable?
                        You wouldn't do LVM -> Encryption -> btrfs -> LZO

                        You'd encrypt indivudal partitions with LUKS, like /dev/sda1 and /dev/sdb1, then when you're making the btrfs filesystem you'd do

                        mkfs.btrfs /dev/sda1 /dev/sdb1 -L EncryptedRoot

                        then turn on LZO compression. Btrfs IS its own volume manager so unless you're continually resizing partitions theres no need to do LVM AND btrfs

                        I'm not positive that you can do compression ontop of encryption though, you might be able to, but im not 100% positive.

                        Comment


                        • #13
                          Originally posted by ᘜᕟᗃᒟ View Post
                          So would a btrfs filesystem with LZO compression and LVM encryption be reliable?
                          have a read of
                          https://btrfs.wiki.kernel.org/index...._encryption.3F

                          Comment


                          • #14
                            Hey!

                            Maybe the skinny EXTents will fix that fractal fragmentation nightmare ... stupid buffer under-run ...

                            But to get off topic entirely, reading the newsgroups on Tux3 ... apparently ... Hirofumi changed the horribly slow itable btree search to a
                            simple "allocate the next inode number" counter, and shazam! The slowpoke became a superstar.

                            Amazing ... simply amazing ...

                            Comment


                            • #15
                              Originally posted by juxtatux View Post
                              Hey!

                              Maybe the skinny EXTents will fix that fractal fragmentation nightmare ... stupid buffer under-run ...

                              But to get off topic entirely, reading the newsgroups on Tux3 ... apparently ... Hirofumi changed the horribly slow itable btree search to a
                              simple "allocate the next inode number" counter, and shazam! The slowpoke became a superstar.

                              Amazing ... simply amazing ...
                              That already got reported on Jux, see Michael's article about Tux3 and Dbench. "Allocate the next inode number" is always the fastest way to do it, its just not always the smartest. See the article and the follow up to see why and the explanation.

                              Comment

                              Working...
                              X