Announcement

Collapse
No announcement yet.

Fedora 33 Making Progress With Their Btrfs-By-Default On The Desktop

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

  • RahulSundaram
    replied
    Originally posted by kreijack View Post

    What it is strange to me is that RedHat didn't pushed stratis on Fedora; this could be a good benchmark for this technology.
    This isn't really surprising. Fedora is a lot more popular on the workstation type of environment and while Fedora server does exist and more closely reflects RHEL, this difference does drive some changes one way or the other. Fedora workstation for instance continues to use Ext4 and has shifted to Xfs like RHEL has. Stratis is squared targeted at solving enterprise use cases which aren't all that appealing to majority of Fedora users. It is available and users can opt-in and that's pretty much it

    Leave a comment:


  • herman
    replied
    Originally posted by kreijack View Post



    I don't think that there is a conflict between RedHat and Fedora. The RedHat decision was taken few years ago. In the meantime BTRFS is stabilized, and the adoption of BTRFS from Suse helped the Fedora decision. Pay attention that BTRFS is a default which can be override at installation time.

    Moreover take in consideration that RedHat and Fedora have different target: the former has a "conservative" target, which is more open to a more stable filesystem (like xfs or ext4) . The latter has a target more open to the innovation, even if it is less stable. Often Fedora seems to be the technology preview for RedHat. It can be viewed as test bench for feature which *could* be adopted in RedHat. If BTRFS will not satisfy the Fedora users, it can be dropped and RedHat will not take the risk of a "epic fail".

    It has to be pointed out that In the meantime, RedHat started the development of stratis; however I think that if you requires to stratis features like quota+snapshot+lwn+shrinking of a volume+raid, you will ends to performance even slower than BTRFS. So I don't think that stratis is (nor will) be a full replacement of BTRFS.
    What it is strange to me is that RedHat didn't pushed stratis on Fedora; this could be a good benchmark for this technology.
    The way I see it, Fedora's adoption of btrfs is a commitment from the dev team to work on making it more stable. This is the closest we'll get for now to Red Hat reconsidering their decision. Fedora pulled it off before with adopting Wayland and Gnome 3. It will be a huge success story if Fedora keeps btrfs and it spreads to other distros.

    Leave a comment:


  • kreijack
    replied
    Originally posted by ALRBP View Post
    I do not understand Redhat. They stop supporting Btrfs in their enterprise distribution but want to make it default in their community distribution…
    Originally posted by ALRBP View Post
    I know this proposition does not come from Redhat, but I did not know that Fedora was independent enough to take decisions opposed to those of Redhat.
    I don't think that there is a conflict between RedHat and Fedora. The RedHat decision was taken few years ago. In the meantime BTRFS is stabilized, and the adoption of BTRFS from Suse helped the Fedora decision. Pay attention that BTRFS is a default which can be override at installation time.

    Moreover take in consideration that RedHat and Fedora have different target: the former has a "conservative" target, which is more open to a more stable filesystem (like xfs or ext4) . The latter has a target more open to the innovation, even if it is less stable. Often Fedora seems to be the technology preview for RedHat. It can be viewed as test bench for feature which *could* be adopted in RedHat. If BTRFS will not satisfy the Fedora users, it can be dropped and RedHat will not take the risk of a "epic fail".

    It has to be pointed out that In the meantime, RedHat started the development of stratis; however I think that if you requires to stratis features like quota+snapshot+lwn+shrinking of a volume+raid, you will ends to performance even slower than BTRFS. So I don't think that stratis is (nor will) be a full replacement of BTRFS.
    What it is strange to me is that RedHat didn't pushed stratis on Fedora; this could be a good benchmark for this technology.

    Leave a comment:


  • pal666
    replied
    Originally posted by ALRBP View Post
    I did not know that Fedora was independent enough to take decisions opposed to those of Redhat.
    basically, you sourced your information from some garbage bin

    Leave a comment:


  • pal666
    replied
    Originally posted by Mario Junior View Post
    when the system allows you to use flags in fstab, as currently, the system will not start if there are any flags for btrfs in fstab .
    i have any flags for btrfs in fstab with no issues(subvol=)

    Leave a comment:


  • Zan Lynx
    replied
    Originally posted by pc777 View Post
    So can you actually know how much space you have left and does deletion actually work?
    This entirely depends on your definition of "work."

    Generally with CoW filesystems or LVM snapshots the answer is "No." You cannot know how much space is left and you cannot rely on deletion to "work."

    That is because with shared references and snapshots you have to go to a ton of extra work to determine if a file deletion will free any space. Since it might exist in multiple snapshots and reference copies, deleting one might not free any space at all.

    The "space left" calculation is tough too. With btrfs the amount of metadata used by a file will be hard to predict. If you're using compression, the amount a file will compress is hard to predict.

    Then there's features like "autodefrag." I use it on my NAS hard drive storage array, because without it the performance some things goes to the dogs. However, a "defrag" operation can split copies from reference copies (like snapshots) and so a disk operation might write 4K into the middle of a database file, and then surprise! autodefrag rewrote 8 MB of the file and your 4K write to an existing file suddenly used 8 MB more disk space.

    Another thing about deletion that confuses some people. Many filesystems, not just btrfs, queue deletion up in the background. That means you can delete a big file, or a subvolume or a snapshot, and it appears to go away. However, the actual delete operation may take minutes and you won't get the disk space back until it finishes.

    Leave a comment:


  • pc777
    replied
    So can you actually know how much space you have left and does deletion actually work?

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by ALRBP View Post

    I know this proposition does not come from Redhat, but I did not know that Fedora was independent enough to take decisions opposed to those of Redhat.
    I haven't seen anything that indicates that Red Hat is opposed to this change *for* Fedora. There have been some discussions around handling say blocker bugs etc but those are reasonable concerns and it appears that Facebook is willing to dedicate some resources for this. Other volunteer contributors have stepped in to shepherd this change as well

    Leave a comment:


  • jacob
    replied
    Originally posted by Mario Junior View Post
    Call me when you implement the BTRFS partitioning available in OpenSUSE and when you allow adding the flags for BTRFS BEFORE installing the system and when the system allows you to use flags in fstab, as currently, the system will not start if there are any flags for btrfs in fstab .
    With BTRFS the important flags (compression type, space_cache etc) are persistent.

    Leave a comment:


  • Zan Lynx
    replied
    Originally posted by Mario Junior View Post

    Code:
    subvol=root,compress=zstd,ssd_spread,noatime,space_cache 0 0
    The only reason that could fail is if zstd compression requires a kernel module that isn't being built into the initramfs. You could force dracut to include it. Read "man dracut" and add it to the dracut.conf file.

    Leave a comment:

Working...
X