I have a several years experience running Linux I ran Suse about 16 years ago when I bought it in a book store.
I decided to try Opensuse and have never used btfs or xfs. I usually use ext4.
I just wondered if btfs is stable enough for the os why is xfs recommended for /home?
PS. is it possible to install on /dev/sdb without erasing /dev/sda?
Le 02/11/2017 à 05:16, slickrick66 a écrit :
> I just wondered if btfs is stable enough for the os why is xfs
> recommended for /home?
>
> PS. is it possible to install on /dev/sdb without erasing /dev/sda?
>
>
yes it is.
Of course there are some differences from ext4
for me, essentially, the BTRFS snapshot system needs much space on the
partition (100Gb recommended if available), else it need a snapshot
management, but it gives the snapshot security…
there is no way to make a file system smaller with xfs
jdd
> I just wondered if btfs is stable enough for the os why is xfs recommended for /home?
nothing to do with stability. (I believe) that since every file change is stored (COW) on btrfs then snapshots would become too much.
If you are just going to install openSUSE on a laptop of yours for everyday use I would stick with EXT4 (that’s what I’m currently doing).
If you are going to test openSUSE and willing to learn a lot, then go with the default (and be prepared to study accordingly).
My understanding is that BTRFS and XFS might have several advantages in a corporate environment, but might be overkill for “home” use, especially if you are not used to the tricks needed by those filesystems.
PS: of course it is possible to install the system on the device you want, just select the “Expert partitioner” button when at the disk layout proposal screen. If you are used to Linux that should be straightforward; if not so, just ask here on the forum.
BTW, welcome back to openSUSE!
Phoronix did a “Btrfs, EXT4, XFS, F2FS” comparison in 2015: <https://www.phoronix.com/scan.php?page=article&item=linux-43-ssd&num=1>.
Also, there’s this, about 2 years old, “UNIX Men” comparison of EXT4, Btrfs and XFS: <https://www.unixmen.com/review-ext4-vs-btrfs-vs-xfs/>.
[HR][/HR]You pays your money and, you takes your choice.
On Thu, 02 Nov 2017 04:16:01 +0000, slickrick66 wrote:
> I just wondered if btfs is stable enough for the os why is xfs
> recommended for /home?
Snapshots, for one - stability is only one “qualification” (if you will)
for selecting a particular filesystem for a particular use.
Say, for example, you’re running virtual machines. Do you want snapshots
to duplicate virtual hard drives every single time a snapshot is taken?
(Answer: No, you don’t - I actually tried it, and performance - another
“qualification” - tanked on the system).
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
I have no inside knowledge, but I can guess…
There probably is no problem using BTRFS for /home (or for virtual disk storage), but only if configured specifically for that and other scenarios… In other words, implementing would require a pretty fair amount of work and research/testing that hasn’t been done by anyone on a large enough scale today (possibly a future project for TW guinea pigs?)
Various articles have listed desirable features you’d want in all scenarios… particularly file integrity checks, and journaling. Apparently BTRFS does those exceptionally well with very little latency. So, BTRFS can be cool for runtime in general.
But,
the downsides are also commonly described, including
COW - Although it’s nice to attain an exceptionally high level of integrity, it comes with a high performance cost. COW is nice for those systems that can tolerate a bit of write latency, but Users on Workstations tend to expect instantaneous responsiveness.
Snapshot storage - A common question in these openSUSE forums, many Users are surprised by storage requirements when they suddenly run out of disk space.
LVM - Writes on LVM in general can be very slow.
Fragmentation - I’m not sure how this is that different than other file systems but is perhaps exacerbated by COW latency. In any case, if you maintain at least 30% free space and once a year perhaps <move> files that are frequently over-written/updated/changed to another partition or disk and back again, the problem is addressed.
Large RAID - Is your array close to 15 disks?
For those who might want to explore an alternative to BTRFS which has been around a lot longer and has some pretty interesting features of its own, Red Hat recommends ZFS (and does not recommend BTRFS). I’ve played around with ZFS a little bit, it’s very interesting but requires a steep and extensive learning curve (and when was the last time we in openSUSE really had to “learn” a file system?)
Some interesting links to recent or current info…
A lot of the configurations described for virtual disks should be considered if you’re deploying BTRFS for /home
SUSE 12 SP3 Storage
Most of the BTRFS content is relevant, but not the section on “duperemove” because the package isn’t available. You can probably still get it though, if you want to build from source(github) which doesn’t look difficult. Instead of duperemove, I’ve experimented with bedup which has been around a bit longer. Yes, the documentation considers BTRFS as viable virtualization storage… when configured accordingly.
https://www.suse.com/documentation/sles-12/singlehtml/stor_admin/stor_admin.html
BTRFS and virtual disks
https://superuser.com/questions/705304/reasoning-behind-hosting-virtual-disk-images-on-btrfs-filesystem
BTRFS - describes some extensive testing comparing BTRFS to other file systems,
https://serverfault.com/questions/857024/linux-kvm-client-filesystem-btrfs
Plenty of IMO,
TSU
On Fri, 03 Nov 2017 15:36:02 +0000, tsu2 wrote:
> There probably is no problem using BTRFS for /home (or for virtual disk
> storage), but only if configured specifically for that and other
> scenarios… In other words, implementing would require a pretty fair
> amount of work and research/testing that hasn’t been done by anyone on a
> large enough scale today (possibly a future project for TW guinea pigs?)
Really specifically, my setup was using btrfs for hosting VDI files for
VirtualBox - I found that starting 9 VMs at the same time (it’s a beefy
machine), the system would become totally nonresponsive because something
would trigger a snapshot during that process. Snapshots with multiple GB
files are (or were, this was on 42.1 or earlier) high impact to
performance.
I switched to using XFS, since it doesn’t have that snapshot feature, and
that fixed the performance issue (that was recommended when I asked
questions about it of someone with btrfs internals knowledge). Their
recommendation was that that wasn’t a good use case for btrfs, and that I
should look at a different filesystem.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
When the partition if formatted BTRFS,
you can exclude specific directories from snapshotting.
Even our current default BTRFS root partition is configured to exclude a large number of directories, primarily runtime that are always re-created and have no value being saved, and files that are deployed to RAM.
Before BTRFS can be deployed widespread on a partition other than root, all these directories that should be excluded (and maybe some of them might not apply to everyone) need to be identified.
Your comment about snapshot issues for Virtualbox on the /home partition is commonly encountered by KVM/QEMU users because for those the default storage is in the root partition.
TSU
On Sat, 04 Nov 2017 16:06:01 +0000, tsu2 wrote:
> you can exclude specific directories from snapshotting.
Cool, I hadn’t realized that. Going to have to use that on my docker
directory structure. 
For me, though, on the home partition, snapshots didn’t make a lot of
sense anyways.
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Hi
I run my /home on btrfs and exclude from snapshots (it wasn’t clear when first started with btrfs, hence full disk quick…)
You also need to exclude any created outside btrfs if they did exist eg, I use LVM/XFS for /var/lib/libvirt/images on my desktop system.
I realise this is a naive question but how to I exclude /home and other directories from shapshots? This computer only as one Linux partition and it is btfs, but I have not found an explanation of how to organise the filing system – previously use extN which I understand almost.
I am thinking it was a mistake to take the default btfs
Hi
You can see what’s excluded via (as root user, use su - );
btrfs subvolume list /
Then nothing to worry about it’s automatically excluded, are snaphots even enabled on your 42.3 setup?
To exclude a directory at install via expert partitioner and then under the btrfs partition you can select a partition to exclude. Else you can add via YaST partitioner and select the btrfs device and edit, there is a button to hit and add a directory to exclude. It will update /etc/fstab accordingly.
Oh, another snippet for folks, you can check for btrfs i/o errors via;
btrfs device stats -z /dev/sdb1
[/dev/sdb1].write_io_errs 0
[/dev/sdb1].read_io_errs 0
[/dev/sdb1].flush_io_errs 0
[/dev/sdb1].corruption_errs 0
[/dev/sdb1].generation_errs 0
From my experience, I think OP’s original question should have been:
Why on Earth was BTRFS even suggested as default for root partition for Leap ever since 42.1?
It may be usable already, but not good enough yet!
For beginners, this issue (even though viable solutions were proposed there in the thread).
Then the fact BTRFS has no auto-defragmentation routines like ext4; btrfs maintenance service mentioned in the just mentioned thread doesn’t seem to be quite the thing, I wonder if the user testing it got any results…
Another issue I’m finding, though it has seemed “harmless” until now at first sight, sometimes when rebooting or shutting down there are a bunch of messages in the console saying something like “Transport endpoint is not connected” at the end, before rig powers off.
Finally, though still not 100% sure if it’s due to BTRFS, it makes system lag or slowdown a bit at times. In my case, for instance, I notice it sometimes when running Firefox browser. Not a very critical issue though, but it’s there.
I talked to a pal the other day, who has been using openSUSE since several years ago, and he confirmed he began to notice this kind of issues since Leap 42.1, when default suggested file system switched from ext4 to BTRFS. Two more Leap releases later and still the issues.
Again, what was -and still is- Suse people thinking? Yes, even though one can just not take the default suggestion and select ext4 during installation.
Welcome to 2017, we have these things called SSD’s where defragmentation is neither needed or wanted - and with Intel Optane style devices it doesn’t matter if you have 10% or 90% free, the wear is no longer a concern.
It’s a FUSE “error”.
Firefox being a pile of garbage has nothing to do with the FS. It’s just a badly written, badly optimized, inefficient browser made by a company that flaunts privacy but defaults to sending data without asking the user a **** thing. The faster they croak, the better.
But there are many of us in the planet who don’t have very recent PCs!
Specially in companies or offices, where policy is “if it’s not broken, don’t fix it nor replace it”.
Shouldn’t Suse guy take this still in consideration?
And regarding the console error at shutdown time, what on Earth does “a FUSE error” mean?
By the way, I made another effort trying to read it and it says something like:
“systemd-journald: failed to send stream file descriptor to service manager: transport endpoint is not connected”
Again, not always happens. Sometimes does, sometimes doesn’t. Probably just random…
Excuse me, hello?
Would need the exact error to evaluate, but in general there are many possible shutdown errors which are non-critical.
In the case of anything related to FUSE, you should understand that FUSE is just a special type of file system mounting, so any shutdown errors more than likely relate to a FUSE mounted file system not unmounted cleanly before shutdown.
A lot of things might prevent an unmount command from executing in a timely manner, and it’s even possible that an unmount command was not done in an “intelligent” manner. When I first looked into sudden error shutdowns long ago, I found that a lot of times a shutdown might send “soft” (ie request, not forcibly kill) commands like unmount without really knowing the context of those commands, ie Why isn’t the request being honored right away? What’s happening that might prevent a process from ending immediately? This means that when a shutdown is initiated, many processes will stop, but many might not.
So, what do you then do?
Do you keep waiting for <all> processes to stop before shutting down, even if some processes might never shut down on their own? Your shutdown command then might never execute completely.
The usual decision is to perhaps wait a “reasonable” amount of time(which might be the wrong decision in some circumstances) and forcibly send the Kill command, resulting in something like your FUSE error.
Now, let’s consider specifically the consequences of a dirty FUSE unmount…
You’re shutting down, so it’s not like there could be remount errors during the current User session… When the system reboots and the file system is mounted again, it will be done without any regard to the previous dirty unmount.
You do need to ensure that no active file operations like copy or move are happening, because interrupting those operations on <some> file systems will result in file corruption on both source and destination.
So, a dirty unmount can be a critical and perhaps fatal consequence on machines that handle critical data(Like database application servers, which need file integrity to be done both at the file system and at the application levels).
Else, most Users can simply know what’s happening on their machine on shutdown and not worry about a dirty unmount.
Or, install only on journaling file systems which will always ensure a fully complete file operation before committing.
Does that help?
TSU
On Wed, 08 Nov 2017 19:46:02 +0000, F style wrote:
> From my experience, I think OP’s original question should have been: Why
> on Earth was BTRFS even suggested as default for root partition for Leap
> ever since 42.1?
>
> It may be usable already, but not good enough yet!
<looks at my own main system running btrfs on root>
Yep, seems good enough here. I had to tune a few things down because my
root partition size was smaller than I should’ve made it, but works great
here.
Fragmentation in a multi-tasking operating system isn’t a huge deal.
Auto-defragmentation is sometimes useful, but on generally static
drives (like a root partition), not a huge issue.
In fact, it increases the wear on the drive, and decreases the drive
lifetime for volumes that are highly defragmented.
But this ain’t DOS. It’s a modern operating system where fragmentation
is generally not a big performance issue (one exception that comes to
mind is for a swap file - which is why you should use a swap partition
instead).
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
Since moving over to oS TW earlier this year, & thereby hearing for the first time of BtrFS, what sold me on it [for my /] was my further research into TW informing me about Snapper. I simply luuuuuurve Snapper with its roll-back capability; love love love it. So if i need to use BtrFS as a means to enjoy the great benefit of Snapper, then that’s absolutely fine with me. It would be extremely hard for me in any future OS i might use, to forego the roll-back functionality, so i envisage sticking with TW & BtrFS for the long haul.