Linked by Thom Holwerda on Mon 4th Apr 2016 18:05 UTC
FreeBSD

The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 10.3-RELEASE. This is the third release of the stable/10 branch, which improves on the stability of FreeBSD 10.2-RELEASE and introduces some new features.

It's got a ton of improvements to the UEFI boot loader, the Linux compatibility layer, and a whole lot more.

Order by: Score:
Boot environments
by jessesmith on Mon 4th Apr 2016 19:34 UTC
jessesmith
Member since:
2010-03-11

I think one of the really big improvements is support for ZFS boot environments. PC-BSD has had them for a year or so now. On the Linux side of things, openSUSE recently got Btrfs boot environments too. Having used them, I don't think I will ever run a system again that doesn't support boot environments. It's one of those technologies that seems like a small thing, but makes a big difference once it has been put into play.

Reply Score: 2

RE: Boot environments
by Kochise on Tue 5th Apr 2016 11:22 UTC in reply to "Boot environments"
Kochise Member since:
2006-03-03

Like ? Could you explain the benefits ?

Reply Score: 2

RE[2]: Boot environments
by dnebdal on Tue 5th Apr 2016 12:06 UTC in reply to "RE: Boot environments"
dnebdal Member since:
2008-08-27

Like ? Could you explain the benefits ?


I haven't used them much myself, but the basic idea is that instead of having ZFS filesystems for /home and /, you have e.g. /home, /ROOT/one and /ROOT/two ; at boot you get to choose if you want to use one or two as your /.

It's a simple idea, but in practice it means you can fork your current system, chroot into the clone, do a dramatic system upgrade, and then get to pick between the original and the upgraded system when you reboot. Or for that matter, you could set things up so every update happens in a new clone, making it easy to roll back if anything stops working. (ZFS clones are cheap, since they only store the changed blocks.)

Oh, and you could theoretically install debian/kFreeBSD and PC-BSD in their own boot environments and pick between them at boot, as long as their kernels support the ZFS version you use.

Edited 2016-04-05 12:07 UTC

Reply Score: 2

RE[3]: Boot environments
by jessesmith on Tue 5th Apr 2016 12:16 UTC in reply to "RE[2]: Boot environments"
jessesmith Member since:
2010-03-11

Essentially correct, but I think you make it seem overly complicated.

Basically, with boot environments, you use the computer as you usually would. But prior to running any major upgrades or configuration changes, the system makes a snapshot (copy) of the operating system. This requires virtually no additional disk space with ZFS.

If something in the config change or an upgrade breaks the OS, you simply reboot and select the previous snapshot from the boot menu. This rolls back the OS to the last known good state.

This means you can do just about anything to your OS (delete files, break dependnecies) and a simple reboot fixes it.

On openSUSE it is especially nice as YaST does all this for you automatically and you can even do side-by-side diff comparisons of your files. So if a config file changes between snapshots you can see exactly what happened and select which version of the file to keep.

As someone who has worked on servers where another admin changed a config between reboots or a dependency broke during a long uptime, it is very handy to be able to simply roll back to the last known good state.

Reply Score: 3

RE[4]: Boot environments
by Kochise on Tue 5th Apr 2016 12:36 UTC in reply to "RE[3]: Boot environments"
Kochise Member since:
2006-03-03

Isn't it a bit like booting u-boot and selecting your system image or selecting between two users with admin rights ?

Reply Score: 2

RE[5]: Boot environments
by jessesmith on Tue 5th Apr 2016 13:33 UTC in reply to "RE[4]: Boot environments"
jessesmith Member since:
2010-03-11

No, I don't think that parallel works.

Reply Score: 2

RE[4]: Boot environments
by Alfman on Tue 5th Apr 2016 14:38 UTC in reply to "RE[3]: Boot environments"
Alfman Member since:
2011-01-28

I very much like having snapshots at the bootloader level, but the layering violations that ZFS commits troubles me. I'd prefer for it to be at the volume level, independent from the FS. Unfortunately as useful as logical volumes are for snapshotting and allocating volumes with ease, there are no widely accepted standards for volume management. Linux uses LVM, freebsd uses vinum, there's the solaris volume manager, windows 8 adopted "storage spaces". If only we had one good standard, it would be perfect for multibooting different operating systems without worrying about physical partition locations on disk.

Reply Score: 2

RE[5]: Boot environments
by darknexus on Tue 5th Apr 2016 16:45 UTC in reply to "RE[4]: Boot environments"
darknexus Member since:
2008-07-15

If only we had one good standard, it would be perfect for multibooting different operating systems without worrying about physical partition locations on disk.

While you're at it, wish for a universal filesystem that has full support built in all operating systems and is not FAT32. Baby steps, after all.

Reply Score: 2

RE[6]: Boot environments
by jgfenix on Wed 6th Apr 2016 16:48 UTC in reply to "RE[5]: Boot environments"
jgfenix Member since:
2006-05-25

UDF?

Reply Score: 2

RE[7]: Boot environments
by darknexus on Wed 6th Apr 2016 20:20 UTC in reply to "RE[6]: Boot environments"
darknexus Member since:
2008-07-15

UDF?

You're joking, right? Format a USB stick as UDF, then put it in a Windows, Linux, and Mac machine and tell me just how well that works. No cheating, for reading and writing.

Reply Score: 2

RE[5]: Boot environments
by agentj on Tue 5th Apr 2016 17:24 UTC in reply to "RE[4]: Boot environments"
agentj Member since:
2005-08-19

What layering violations ? I like it works for most common case and it does it well. It only prevent some nerd slobs from running filesystem in exoting configuration that virtually nobody else uses or wants.

Reply Score: 2

RE[6]: Boot environments
by fretinator on Tue 5th Apr 2016 17:54 UTC in reply to "RE[5]: Boot environments"
fretinator Member since:
2005-07-06

It only prevent some nerd slobs from running filesystem in exoting configuration that virtually nobody else uses or wants.


You have the gasoline, I have the match. Flame on!

Reply Score: 2

RE[5]: Boot environments
by Kebabbert on Thu 7th Apr 2016 18:42 UTC in reply to "RE[4]: Boot environments"
Kebabbert Member since:
2007-07-27

I very much like having snapshots at the bootloader level, but the layering violations that ZFS commits troubles me. I'd prefer for it to be at the volume level, independent from the FS.

Research shows that ZFS is the safest commodity filesystem out there. CERN researchers says ZFS bests even very expensive high end storage system in terms of data safety.

Linux devs have for long called ZFS a "rampant layering violation", because ZFS is monolithic.
http://arstechnica.com/staff/2007/05/rampant-layering-syndrome/
In Linux you have the filesystem, raid layer, volume manager, etc. Different layers.

ZFS creators rethinked the storage basics and started afresh and came up with this monolithic ZFS. The reason ZFS has superior data integrity, is BECAUSE it is monolithic. That is why ZFS can provide superior data integrity, besting very expensive storage systems out there. As CERN researchers say:
-Adding checksums to detect data corruption is not enough for data integrity.

(For instance hard disks have lot of checksums and still they return corrupt data, 1 corrupt bit in 10^17 read bits, according to Enterprise Fibre Channel disk specs)

You must use a _special_ type of checksum to detect all the different kinds of data corruption that can occur. Not any checksum will do. You need End-to-End checksums for data to be safe.

Even if every layer in Linux storage is checksummed (hard disks have checksums, raid level have checksums, etc), but when the data passes the boundary to another layer - the data might get corrupt. The checksum is _not_ passed to the new level. Instead a new checksum is calculated in the new level, based on what (corrupt) data it received from the underlying level.

ZFS changes this by being MONOLITHIC so there are no different layers. ZFS is in charge of all the layers, so ZFS knows the checksum no matter in which level the data resides in. This means the data does not get corrupt as it passes boundaries. And this is possible ONLY because ZFS is a "rampant layering violation" which the Linux devs mocked ZFS for. They laughed at ZFS and called it badly designed, Sun kernel devs did not know jack, etc etc.

Linux devs did not really understand ZFS. As they did not understand Systemtap (it can crash the server, DTrace can not), nor did they understand Solaris SMF and built the Linux copy systemd. Linux devs just copy without really understanding the reason. For instance, in an old interview Chris Mason said he added checksums to BTRFS only after reading Sun talking about ZFS data integrity, that was only then he realised the importance of end-to-end checksums. And guess what? BTRFS is... monolithic. Just like ZFS. I dont see Linux devs call BTRFS a layering violation? Not Invented Here syndrome?

But Chris did not understand why ZFS is monolithic: because of the desire of End-to-End checksums. And still he did BTRFS monolithic in the beginning, without End-to-End checksums. He did not understand.

So, Alfman, I dont think the future is layered storage, it should be monolithic. Different layers defeats data integrity. Well, now you understand one of the design decisions behind ZFS, why "ZFS commits layering violations"

Edited 2016-04-07 18:45 UTC

Reply Score: 3

RE[4]: Boot environments
by abraxas on Tue 5th Apr 2016 18:40 UTC in reply to "RE[3]: Boot environments"
abraxas Member since:
2005-07-07

Basically, with boot environments, you use the computer as you usually would. But prior to running any major upgrades or configuration changes, the system makes a snapshot (copy) of the operating system. This requires virtually no additional disk space with ZFS.

You can effectively achieve this with LVM and use any filesystem you like on top of it.

Edited 2016-04-05 18:42 UTC

Reply Score: 2

RE[5]: Boot environments
by darknexus on Tue 5th Apr 2016 18:54 UTC in reply to "RE[4]: Boot environments"
darknexus Member since:
2008-07-15

Basically, with boot environments, you use the computer as you usually would. But prior to running any major upgrades or configuration changes, the system makes a snapshot (copy) of the operating system. This requires virtually no additional disk space with ZFS.

You can effectively achieve this with LVM and use any filesystem you like on top of it.

Sure, but it's not generally as automatic or simple. Technically I could achieve it with multiple hard drives, too. That doesn't make it the easiest option to maintain.

Reply Score: 2

RE[6]: Boot environments
by abraxas on Wed 6th Apr 2016 11:59 UTC in reply to "RE[5]: Boot environments"
abraxas Member since:
2005-07-07

Sure, but it's not generally as automatic or simple. Technically I could achieve it with multiple hard drives, too. That doesn't make it the easiest option to maintain.


Take a snapshot and perform updates. It isn't that hard. Now I haven't used ZFS or BTRFS so I don' t know how much easier it is but I wouldn't trade XFS for either one of them. Neither scale nearly as well.

Reply Score: 2

RE[7]: Boot environments
by darknexus on Wed 6th Apr 2016 14:29 UTC in reply to "RE[6]: Boot environments"
darknexus Member since:
2008-07-15

What's different is that often the entire process is integrated, as it was with Solaris Live Upgrade. You simply do the upgrade. It handles every step, including taking the snapshot. That's all I meant. With lvm, if you want the same behavior, you generally have to implement it yourself with scripts. It's not hard, but it's that extra bit of work you don't have to worry about with zfs.

Reply Score: 2

RE[7]: Boot environments
by dnebdal on Thu 7th Apr 2016 15:00 UTC in reply to "RE[6]: Boot environments"
dnebdal Member since:
2008-08-27


Take a snapshot and perform updates. It isn't that hard. Now I haven't used ZFS or BTRFS so I don' t know how much easier it is but I wouldn't trade XFS for either one of them. Neither scale nearly as well.


People apparently create petabyte+ pools with ZFS and it works fine - I have no idea if XFS on lvm scales better, but ZFS seems to be good enough for anything I'm likely to throw at it. ;)

As for snapshots, they're fairly trivial to do ("zfs snapshot pool/filesystem@name"). I haven't used the boot environment tools, but IIRC beadm isn't much harder.

Edited 2016-04-07 15:02 UTC

Reply Score: 2

Comment by satai
by satai on Mon 4th Apr 2016 20:44 UTC
satai
Member since:
2005-07-30

Was inotify implemented for this release?

Reply Score: 1

Thorough benchmarking
by project_2501 on Tue 5th Apr 2016 08:03 UTC
project_2501
Member since:
2006-03-20

A long time i saw a really good set of benchmarks comparing Linux, open/net/freebsd.

They tested stuff like forking, memory allocation, http latency, scaling with number of served sockets, etc etc

http://bulk.fefe.de/scalability


Well you can always find flaws in benchmarks but these were much better than the rather meaningless game frame rate tests ... Or installer reviews.

I'd love for someone to compare and publish comparisons of the main OSes, testing stuff like network stack scalability and latency, memory efficiency, basic numerical performance, stability over time under stress loads, IO throughout scalability and latency, multithread efficiency and degradation limits, some relevant video testing like cpu load during full screen video (netflix, iplayer), etc etc ... Not everyone is a gamer!

Reply Score: 6

RE: Thorough benchmarking
by Alfman on Tue 5th Apr 2016 12:06 UTC in reply to "Thorough benchmarking"
Alfman Member since:
2011-01-28

project_2501,

I'd love for someone to compare and publish comparisons of the main OSes, testing stuff like network stack scalability and latency, memory efficiency, basic numerical performance, stability over time under stress loads, IO throughout scalability and latency, multithread efficiency and degradation limits, some relevant video testing like cpu load during full screen video (netflix, iplayer), etc etc ...



I agree.

It would be interesting if osnews could publish/maintain something like this, but who's going to pay for it? They need an intern or someone to do some free work.

Edited 2016-04-05 12:06 UTC

Reply Score: 2

RE[2]: Thorough benchmarking
by feamatar on Tue 5th Apr 2016 19:32 UTC in reply to "RE: Thorough benchmarking"
feamatar Member since:
2014-02-25

phoronix does that, and it has a paid subscription where one can ask for what kind of benchmarks should be executed.

Reply Score: 1