I’m currently running OpenSuse13.1 on one of my laptops. (Lenovo T61)
I’m considering installing Leap 4.1 but I have concerns about the reliability of btrfs. I’m perfectly happy with ext3 and ext4. Can I still use them with Leap?
Will automount work with btrfs?
You can still use “ext4”. I’m using “ext4” on this computer running Leap.
On the reliability of “btrfs” – I don’t know. I am using it experimentally for Tumbleweed (on a different computer). I have not had any problems. But that long list of mounted subvolumes does clutter the output of “df”
On “automount” - no experience. I wonder what it does with subvolume mounting.
The best thing is to install on VirtualBox or VmWare.
I’m still using ext4 so that I can boot to 13.2, Leap and Tumbleweed.
I’ve been using BTRFS for a year and have had no problems. I have assigned 100 GB to / , 4 GB to swap and 876 GB to /home on a 1 TB drive.
You can use Yast Snapper to create a pre snapshot before an update and a post snapshot after the update.
If you have any problems you can always roll back. BTRFS also monitors and removes snapshots so that root doesn’t get full.
For your Thinkpad I would stick with ext4.
Hi,
Those subvolumes mounting looks like, is adding more time to boot.
Thanks for quick responses. I appreciate it. I think for now, I WILL stick with ext4. It’s never given me any trouble at all.
Bob Smits
Good to hear. Enjoy!
If and when you get a brand new Thinkpad in the future you can consider out BTRFS.
The creator of ext4 said BTRFS was the next step up.
On Thu, 04 Feb 2016 20:56:02 +0000, robertsmits wrote:
> I’m currently running OpenSuse13.1 on one of my laptops. (Lenovo T61)
>
> I’m considering installing Leap 4.1 but I have concerns about the
> reliability of btrfs. I’m perfectly happy with ext3 and ext4. Can I
> still use them with Leap?
>
> Will automount work with btrfs?
I’m using btrfs on an SSD in my main desktop for the / partition.
No problems or complaints, other than the usual “determining free space
can be challenging if you don’t know how” (you have to use the btrfs
program rather than df) and running out of disk space with a snapper
config that’s not right for the system.
My /home partition is XFS for performance reasons (btrfs + large vm
images = very bad performance and idea).
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
I get the sense that it is reliable, although I personally am not yet using it. It is – however – the future, and I will be using it at some point.
See my comments here:
https://forums.opensuse.org/showthread.php/478909-Advisory-June-2013-New-Users-beware-of-using-the-BTRFS-filesystem?p=2752514#post2752514
And see Wolfi’s comments above my post.
This is my third laptop using btrfs exclusively. The first ran 12.1 and
had a spinning rust drive. The second was 12.2 or something and also had
spinning rust. I was much more-diligent about backups back then, fearing
imminent death to data using something that was barely considered ready
for general use.
Today I have had 13.1 (current laptop) on my SSD-based laptop that I
bought (no longer a work-provided laptop) in 2012 (obviously had an
earlier openSUSE version back then) and, again, this is my primary system.
My current install was done in 2013-11 so after over two years, things
are still fine. SSDs help all systems, and btrfs is no exception, but I
kind of guess that Copy-on-Write (CoW) filesystems are helpful to SSDs
since they naturally (due to snapshots) do not overwrite the same blocks a
million times in a row as much as other filesystems do, not that that
potentially problem isn’t already solved usually anyway.
As others have mentioned, if you want to store databases, VMs, or other
big files that change within regularly you should disable CoW on those
files or directories, or use another filesystem (XFS is my next favorite).
The reason is because of how CoW works and how those big variable files
work, which is not a happy combination. Disabling CoW on a directory or
subvolume before putting files within is trivial though:
chattr +C /path/to/the/vm/directory
The biggest caveat with this is that it only works on files that are new
and have zero bytes (no blocks allocated yet), or to directories with
nothing in them yet. Sure, you can set the ‘C’ flag on an existing file
with data, or an existing directory with files, but it does not apply
until you move the file out of, and then back into, place, because at that
point the file is rewritten in a way that is not going to use CoW.
General best practice: create the directory and set the no-CoW attribute
with the command above and then start using it for VMs, databases, etc.
SLES 12 SP1, for what it is worth, automatically sets this attribute out
of the box on various directories that could be used for databases,
including /var/lib/pgsql, /var/lib/mariadb, and /var/lib/mysql so that is
pretty nice. I have not seen if Leap does that yet, but would not be
surprised if it did.
Summary: Go with btrfs; the advantages are great, and the first time a
snapshot saves your system you’ll never go back.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
… for me, though, that is no selling point. I make frequent rotating backups with some historically archived.
And, I always backup before any major change.
It is still the smartest and safest way to do things.
A good percentage of the problems that crop up on this forum would never have happened if the person with the problem had done the same.
Btrfs is unreliable.
I had two bad crashes because of it, and stopped using Btrfs.
On 2016-02-04, robertsmits <robertsmits@no-mx.forums.microfocus.com> wrote:
> I’m considering installing Leap 4.1 but I have concerns about the
> reliability of btrfs. I’m perfectly happy with ext3 and ext4. Can I
> still use them with Leap?
Yes.
> Will automount work with btrfs?
Yes.
As for reliability I don’t know. I have gradually increased the proportion of the 6 partitions per GNU/Linux distribution
I invoke I mkfs.btrfs, so far without any problems on both mechanical and solid-state drives. For performance reasons, I
don’t believe btrfs is an adequate replacement for XFS but I admit this opinion is based on prejudice rather than
evidence. The GUI installer for recent versions of openSUSE implement btrfs by default with a very baroque multiple
subvolume proposal. Since openSUSE makes no attempt to explain this default proposal and seems to hide the need for such
rococo antics behind an opaque wall, I remain highly sceptical and unconvinced by its usefulness.
On 02/05/2016 08:12 AM, flymail wrote:
>
> As for reliability I don’t know. I have gradually increased the proportion of the 6 partitions per GNU/Linux distribution
> I invoke I mkfs.btrfs, so far without any problems on both mechanical and solid-state drives. For performance reasons, I
> don’t believe btrfs is an adequate replacement for XFS but I admit this opinion is based on prejudice rather than
> evidence. The GUI installer for recent versions of openSUSE implement btrfs by default with a very baroque multiple
> subvolume proposal. Since openSUSE makes no attempt to explain this default proposal and seems to hide the need for such
> rococo antics behind an opaque wall, I remain highly sceptical and unconvinced by its usefulness.
The primary reason for the subvolumes is so that snapshots are not
implemented there when they are implemented for the root filesystem. For
example, if you patch your kernel on day 0, then get around to rebooting
the box on day 5, all the while running your PostgreSQL database very
happily, you do not want your snapshot rollback of the root filesystem to
also roll back your PostgreSQL database full of credit card transactions,
losing five days’ worth of transactions. The same applies to log files,
the /home filesystem, and a bunch of other things.
Most experienced Linux folks would probably have a hard time remembering
every likely place for variable data, other han just specifying /var and
/home and hoping that was sufficient (it’s not), so having the default
proposal include this is, to me, very useful. While Linux folks
traditionally want flexibility and the ability to be explicit, we also do
not want to create the entire distribution from scratch, or if we do we
are not going to be members of this (or almost any other) forum.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…