Announcement

Collapse
No announcement yet.

SUSE Continues Working On Transactional Updates With Btrfs

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

  • SUSE Continues Working On Transactional Updates With Btrfs

    Phoronix: SUSE Continues Working On Transactional Updates With Btrfs

    While Red Hat and several other Linux vendors have either deprecated Btrfs support or at least not embraced it like they originally talked up this "next-gen file-system" years ago, SUSE has continued supporting Btrfs both with openSUSE and SUSE Linux Enterprise...

    http://www.phoronix.com/scan.php?pag...-Trans-Updates

  • Ignacio Taranto
    replied
    Originally posted by WolfpackN64 View Post

    That's one thing that always scares me about Btrfs. I don't want to "set up" my filesystem. I just want it to do what it was designed to do without worrying if any of its features are going to wreck my data.
    Have you ever used openSUSE/SUSE?

    Leave a comment:


  • RomuloP
    replied
    I've never faced a single problem like this, only the provisioning problem and a performance penalty by quotas, I would miss my / fs not being "snapshotable" This is the second machine to where I mirror my system. I really don't like reinstalling things and send receive is a great way of transplanting a system. I was considering playing with ZFS last year (it is good to know more solutions) but ZFS as root appears to be a messy hack... I will play with it anyway, I'm curious about ZVOLS and it's support to other FSs.

    Leave a comment:


  • dfyt
    replied
    Originally posted by waxhead View Post

    I feel this has to be challenged.
    1. How much data did you copy?
    About 2.1T...although BTRFS will tell you 2.3T
    Originally posted by waxhead View Post
    2. Was it large or small files?
    Mixed. VDI's, Movies, Jpgs, Games, Sourcecode. Basically a home folder.
    Originally posted by waxhead View Post
    3. How did you find out that BTRFS did use over 200GB more than ZFS/XFS?
    df -hl. Note this is just a plain format as BTRFS then rsync so no snapshots etc. Source is XFS, then rsync to ZFS and BTRFS

    When I last investigated this I was told it was due to some provisioning done by the filesystem - either way it seems way too excessive to me. Out the box. About a 2 years ago I did the same for my media centre and had big differences between BTRFS and ZFS both with compression off.
    Originally posted by waxhead View Post
    4. Locked directories look like they could be subvolumes as Zan Lynx said. Are they?
    No there were not subvolumes, they we normal subfolders and sometimes even actual files - hence why I say corruption. Even booting from another distro / live would leave those specific files/folders as readonly even as root. Often you would not know which files but apps would misbehave then you see why as the settings files weren't been saved as they were "locked".

    I have never lost data per se with BTRFS but have had regular corruption issues. I have only ever lost an entire drive with ZFS...faulty SATA cable - yet imo this still should not have cause me to be unable to mount the drive.

    For me...

    EXT4 for external drives
    ZFS for raid or home
    XFS root - if XFS get checksumming - it would be awesome.
    Last edited by dfyt; 09-03-2018, 05:15 AM.

    Leave a comment:


  • ZeroPointEnergy
    replied
    I don't get the people who still use something other than BTRFS or ZFS. Even if there are still some edge cases where it has problems, that is what a backup is for which you need anyway because of stuff which is a gazillion times more likely to happen like hardware failure or user errors.

    On the other hand if you use EXT4 or whatever and get bitrot, which is really not uncommon when you have terabytes of data it will corrupt your backups as well and no one will ever notice until it is probably too late.

    Leave a comment:


  • patrakov
    replied
    Regarding snapper support for LVM + EXT4. As a person who used it, I would say it is a bad joke. It did save me from a long recovery procedure twice, by offering to roll back the system to a state it was in 1 hour before. But it also created two problems of its own. The issue is that in such stacked setup there is no good concept of available disk space, and if the LVM thin pool for snapshots fills up, you'll get I/O errors and filesystem corruption in the upper layers.

    See https://lwn.net/Articles/747633/ for what XFS developers promise in this situation (and at least, they describe the status quo and its problems accurately).

    Leave a comment:


  • brrrrttttt
    replied
    Originally posted by WolfpackN64 View Post

    That's one thing that always scares me about Btrfs. I don't want to "set up" my filesystem. I just want it to do what it was designed to do without worrying if any of its features are going to wreck my data.
    It's no more complicated than competing filesystems (ZFS)...

    Leave a comment:


  • pal666
    replied
    Originally posted by dfyt View Post
    I recently backed up a 4TB drive to another identical drive, BTRFS used 200GB more with compression over XFS or even ZFS.
    btrfs duplicates metadata by default even on single drive(and can duplicate data if you choose). xfs does not support raid features at all, zfs requires multiple underlying drives to give you ability to recover from bitrot via raid1 and checksums. btrfs is superior to both of them, it uses more space to protect your data. but idiots will complain
    Originally posted by dfyt View Post
    Additionally whilst I haven't lost data I have often had times where the filesystem locks folders and you can't delete them etc.
    move empty bugged folder to /lost+found/ , problem solved
    Last edited by pal666; 09-03-2018, 12:05 AM.

    Leave a comment:


  • pal666
    replied
    Originally posted by jpg44 View Post
    I dont understand the thinking of Fedora and the choice to go with xfs on LVM. There is no way thats better than a volume and snapshot integration into the filesystem. They say "btrfs has problems"
    instead of saying "we are not btrfs devs, so we do what we can"
    Last edited by pal666; 09-03-2018, 12:04 AM.

    Leave a comment:


  • pal666
    replied
    Originally posted by waxhead View Post
    The reason to stay away from snapshots (for beginners) is because defrag breaks reflinks and can increase space usage significantly.
    this applies only to defrag + longlived snapshots. shortlived snapshots can provide atomicity for backups etc

    Leave a comment:

Working...
X