Eight-Way BSD & Linux OS Comparison

[Sergio]

Just because it doesn't have all the data integrity features of file systems like btrfs or zfs doesn't make it 'crappy and insecure', that is just pure BS.

Everything is a balance, I as a desktop user are perfectly happy with the performance/features/safety of a filesystem like ext4, as such I see no reason to use a more resource demanding file system like btrfs or zfs, in short, for my needs I don't think their additional features make up for the increased resource use and loss of performance, YMMV.

This is also mirrored in all other Linux distros I've come across, as they (if they default to anything) default to ext4. Given that PC-BSD is a desktop oriented 'distro' it seems as overkill to default to ZFS.


I'd agree if this was a file system comparison, but it was a 'out-if-the-box' comparison between a bunch of Linux distros and a BSD distro.

Obviously you have to view the results with that in mind, there's no doubt that each and every one of the tested systems could be tweaked to run faster for certain tests than in their default settings.

Yes, you are right... I guess what I wanted to question is the interpretation of the results; indeed, because it is NOT a file system benchmark, it is misleading to use two completely different kinds of beasts, as are ZFS and HAMMER on one side, and ext4 on the other.
Yes, I know the whole out-of-the-box thing, but I'd be more interested in the following:
1. If the intention is to compare OS performance, then use the same file system. This is specially true now that ZFS for Linux is considered for production use.
2. If not possible to use the same file system, at least use the same class of file systems (ZFS, HAMMER, BTRFS are in the same class; UFS and EXT2FS are in the same class).

[finalzone]

I was comparing yum vs. apt, and if yum does extra things that help then great, but from my experience I've had package breakage happen more often on systems using yum so I'm not sure what as a user yum gives me over apt.
All I know is Fedora takes a lot longer to install updates than Ubuntu even if they are small updates, and it doesn't seem to benefit me as a user.

Default behaviour of yum is to check if there is newer dependencies, conflicts and update before the install. You can speed the process by enabling cache via "yum makecache" first then do the installation via "yum -C install". Apt default behaviour requires manual checking i.e. it cannot do all process at once without separate command.
Note that a newer version of you temporarily called dnf expected to be ready for Fedora 22 will use libsolv library which should speed up the process.

[Yfrwlf]

What make you jump to that conclusion? Have you tried pure RPM and DPKG commands to validate your points or you are comparing YUM with APT?
Yum does more stuff than APT in single command (behaviour can be modified via yum.conf) imaking speed advantage moot.

I was comparing yum vs. apt, and if yum does extra things that help then great, but from my experience I've had package breakage happen more often on systems using yum so I'm not sure what as a user yum gives me over apt. The breakage could just be due to poor repo maintenance in Fedora but it doesn't help increase my belief in Yum/RPM.

All I know is Fedora takes a lot longer to install updates than Ubuntu even if they are small updates, and that doesn't seem to be beneficial.

[finalzone]

RPMs also seem much slower than DEBs to install.

What make you jump to that conclusion? Have you tried pure RPM and DPKG commands to validate your points or you are comparing YUM with APT?
Yum does more stuff than APT in single command (behaviour can be modified via yum.conf) imaking speed advantage moot.

[Sonadow]

Given that PC-BSD is a desktop oriented 'distro' it seems as overkill to default to ZFS.

I've always felt that desktop-oriented BSD distributions use ZFS as the default system 'just because they can'.

Think about it: the user gets all the benefits of ZFS in the default install and the performance hit is typically not noticeable to all but the most perceptive users.

[XorEaxEax]

Why use crappy and insecure (and hence extremely fast) ext4?

Just because it doesn't have all the data integrity features of file systems like btrfs or zfs doesn't make it 'crappy and insecure', that is just pure BS.

Everything is a balance, I as a desktop user are perfectly happy with the performance/features/safety of a filesystem like ext4, as such I see no reason to use a more resource demanding file system like btrfs or zfs, in short, for my needs I don't think their additional features make up for the increased resource use and loss of performance, YMMV.

This is also mirrored in all other Linux distros I've come across, as they (if they default to anything) default to ext4. Given that PC-BSD is a desktop oriented 'distro' it seems as overkill to default to ZFS.

Well, I think benchmarks comparing operating systems should use the same file system or, if not possible, at least the same class of file system.

I'd agree if this was a file system comparison, but it was a 'out-if-the-box' comparison between a bunch of Linux distros and a BSD distro.

Obviously you have to view the results with that in mind, there's no doubt that each and every one of the tested systems could be tweaked to run faster for certain tests than in their default settings.

[mithion]

I wonder if you didn't change something during your install Michael. I'm using Mageia 3, fresh install and the cpu governor is set to ondemand.

[root@localhost ~]# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  hardware limits: 850 MHz - 1.70 GHz
  available frequency steps: 1.70 GHz, 1.36 GHz, 850 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 850 MHz and 1.70 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 850 MHz (asserted by call to hardware).
  boost state support:
    Supported: no
    Active: no

[Sergio]

That's a non sequitor. Many Linux filesystems have knobs to toggle some of the performance/safety characteristics including Btrfs. Benchmarks are done with the default safer options usually and any reasonable ones must publish the tweaks done to improve performance if any.

Well, I think benchmarks comparing operating systems should use the same file system or, if not possible, at least the same class of file system.

[RahulSundaram]

Indeed, the nobarrier option. Sorry for using the word 'insecure'; what I wanted to say is that you can make ext4 ridiculously fast, and hence the benchmarks doesn't really compare operating system's performance: i.e benchmarks are useless.

That's a non sequitor. Many Linux filesystems have knobs to toggle some of the performance/safety characteristics including Btrfs. Benchmarks are done with the default safer options usually and any reasonable ones must publish the tweaks done to improve performance if any.

[Sergio]

The only thing he might be referring to is the "nobarrier" option. Yet, even then his statement makes no sense.

Indeed, the nobarrier option. Sorry for using the word 'insecure'; what I wanted to say is that you can make ext4 ridiculously fast, and hence the benchmarks doesn't really compare operating system's performance: i.e benchmarks are useless.