Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: Lead Btrfs FIle-System Developers Join Facebook

  1. #11
    Join Date
    Oct 2012
    Posts
    14

    Default

    As far as I understand, you always need an fsck tool. You can design a COW FS to make sure that if a OS crash or a power failure happens in the middle of a write, you can restore back to the last flushed coherent state.

    But that only deals with OS crashs or power failures. If you have a disk error for instance, and you manage to extract the data out of the disk, you may want to rebuild a coherent state which omits the corrupted parts. But to be honest, I don't know how btrfs does that or if it does. I've been using btrfs for 6month and came back to ext4 due to the silly metada allocation space full which did not reported the FS as being full and prevented me from booting my OS three times after I upgrade the distribution. Believe, when you have no internet access and you tries to fix that from a busybox emergency environment, it drives you crazy not to even be able to issue "rm" because you get ENOSPC. I got angry and reformatted all my volume, even if i know that this issue has been addressed since then.

    Anyway, fsck was just an example for my point, the compression or dedup cases still apply.

  2. #12
    Join Date
    Dec 2008
    Posts
    146

    Default

    Quote Originally Posted by mark45 View Post
    It's been in development for like 5 years already and still no final format, no stable release. It's one of those projects I stopped caring about.
    Try 6 years. Development began in late 2007.

    Compare to ZFS. Development started in 2001. Then ZFS was included in the June 2006 update of Solaris 10. That is 5 years from beginning of development to deployment in a production OS.

    But ZFS pioneered a lot of new filesystem concepts. btrfs already had all of those ideas available to build on in 2007, so btrfs should have been ready faster than ZFS. Implementation should be faster when you do not need to invent the wheel (only reinvent it).

    Instead, after 6 years of development, btrfs is still not ready to be the default root filesystem of a stable OS release.

    Unfortunately, I think it is evident that the project management of btrfs is ineffective. Announcements like this that the project management is not changing may be meant to be reassuring, but I am not reassured.
    Last edited by jwilliams; 12-04-2013 at 05:51 PM.

  3. #13
    Join Date
    Jul 2007
    Posts
    241

    Default

    Why is it news that a developer opens a Facebook acco... oh wait.

  4. #14
    Join Date
    Nov 2010
    Posts
    73

    Default

    Quote Originally Posted by jwilliams View Post
    Try 6 years. Development began in late 2007.
    It's almost 7 years old

    commit be0e5c097fc206b863ce9fe6b3cfd6974b0110f4
    Author: Chris Mason <chris.mason@oracle.com>
    Date: Fri Jan 26 15:51:26 2007 -0500

    Btrfs: Initial checkin, basic working tree code

    Signed-off-by: Chris Mason <chris.mason@oracle.com>


    https://lkml.org/lkml/2007/6/12/242

    "After the last FS summit, I started working on a new filesystem that
    maintains checksums of all file data and metadata."

    I think that he is talking about 2006 fs summit, because 2007 was at February 1213
    https://www.usenix.org/legacy/event/...p/lsf07cfp.pdf

  5. #15
    Join Date
    Oct 2013
    Posts
    260

    Default

    I guess Facebook really wants to port over to Btrfs from ext4

  6. #16
    Join Date
    Dec 2008
    Posts
    146

    Default

    Quote Originally Posted by michal View Post
    It's almost 7 years old

    commit be0e5c097fc206b863ce9fe6b3cfd6974b0110f4
    Author: Chris Mason <chris.mason@oracle.com>
    Date: Fri Jan 26 15:51:26 2007 -0500

    Btrfs: Initial checkin, basic working tree code

    Signed-off-by: Chris Mason <chris.mason@oracle.com>
    Thanks for the correction!

  7. #17
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,551

    Default

    Quote Originally Posted by Akka View Post
    Are you sure they plan develop a fsck tool at all? I don't think zfs has it? I thought it was unnecessary for this sort of file system?
    What do you mean by "plan"? They already have one, and have had it for a while. It's not critical, but it exists.

  8. #18
    Join Date
    Feb 2010
    Posts
    3

    Default

    Quote Originally Posted by GreatEmerald View Post
    enjolras, no, the priorities are quite fine. Btrfs doesn't need a fsck, because it does all the checking and repair at runtime... There is little reason to also make an offline tool for it.
    Well, I had a filesystem that got corrupted somehow after a crash. You could still mount it but it behaved 'weird'. The fsck tool detected some errors but wasn't able to correct them - it crashed instead. In the end you're told that the best option is to format. Few months later I read some news about new compression algorithms and some new raid mode in btrfs.

    I think this is like the definition of 'having the priorities in the wrong order'.

  9. #19
    Join Date
    Jul 2012
    Posts
    287

    Default

    Quote Originally Posted by jwilliams View Post
    Try 6 years. Development began in late 2007.

    Compare to ZFS. Development started in 2001. Then ZFS was included in the June 2006 update of Solaris 10. That is 5 years from beginning of development to deployment in a production OS.

    But ZFS pioneered a lot of new filesystem concepts. btrfs already had all of those ideas available to build on in 2007, so btrfs should have been ready faster than ZFS. Implementation should be faster when you do not need to invent the wheel (only reinvent it).

    Instead, after 6 years of development, btrfs is still not ready to be the default root filesystem of a stable OS release.

    Unfortunately, I think it is evident that the project management of btrfs is ineffective. Announcements like this that the project management is not changing may be meant to be reassuring, but I am not reassured.
    Blah blah from the sidelines. AFAIK, it is default filesystem for SLES. All your assumptions are just assumptions from a very far distance. Reaching conclusions is a bit rude IMO, because you lack any knowledge or did any investigation at all.

  10. #20
    Join Date
    Dec 2008
    Posts
    146

    Default

    Quote Originally Posted by bkor View Post
    it is default filesystem for SLES.
    False.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •