Re: [systemd-devel] [ANNOUNCE] systemd 219

2017-05-03 Thread Florian Kerle 
On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidjaar at gmail.com 
) wrote:


>/В Wed, 18 Feb 2015 01:14:44 +0100 />/Zbigniew Jędrzejewski-Szmek > пишет: />//>/> On Tue, Feb 17, 2015 at 08:05:29PM +0100, Goffredo Baroncelli wrote: />/> > Hi Lennart, />/> > />/> > On 2015-02-16 23:59, Lennart Poettering wrote: />/> > > * journald now sets the special FS_NOCOW file flag for its />/> > > journal files. This should improve performance on btrfs, by />/> > > avoiding heavy fragmentation when journald's write-pattern />/> > > is used on COW file systems. It degrades btrfs' data />/> > > integrity guarantees for the files to the same levels as for />/> > > ext3/ext4 however. This should be OK though as journald does />/> > > its own data integrity checks and all its objects are />/> > > checksummed on disk. Also, journald should handle btrfs disk />/> > > full events a lot more gracefully now, by processing SIGBUS />/> > > errors, and not relying on fallocate() anymore. />/> > />/> > If I read correctly the code, the FS_NOCOW is a temporary 
workaround, i.e. />/> > when the file is closed (or rotated ?) the FS_NOCOW flags is unset 
again. />/> > It is true ? />/> Yes, but you miss the point in general. FS_NOCOW is set during the />/> entire time when the file is being written to, which could be months, />/> and then it is unset when the file will not be written to anymore. So />/> indeed, the file is not protected by btrfs checksums for the majority />/> of time, but journald does its own checksumming, so the contents are />/> protected in a different way. />/> />//>/btrfs checksumming theoretically allows you to transparently recover />/after media corruption if filesystem has redundancy (more than one copy />/of data). Journald checksum will probably detect corruption, but can it />/repair it? /

No it cannot.

But btrfs checksumming cannot fix things for you either if you lose
non-trivial amounts of data. It might be able to fix a few bits of
errors, but not non-trivial amounts. I mean, that's a simple property
of error correction codes: the more you want to be able to correct the
longer must your checksum be. Neither btrfs' nor journald's are
substantial enough to correct even a sector...

Lennart

--
Lennart Poettering, Red Hat


Hi Lennart,

it's correct, that checksums are not suitable to recover a file;
BUT when using btrfs RAID, checksums are used to determine which copy of the 
file is malformed.
(and restore it, if any redundant OK copy exists)

Using FS_NOCOW on journal files does prevent btrfs from restoring the journal, 
even if a sane copy would exist.
(i.e. hardware / drive failure.)
That probably means losing important data.

While this IMHO seems like a temporary workaround until btrfs autodefrag (on a 
per file basis) exist,
I'd rather make this configurable and surely not the default!

Do you have any further info or opinion on this?


Best regards,
Florian

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-18 Thread Lennart Poettering 
On Tue, 17.02.15 23:30, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 Lennart Poettering wrote on 17/02/15 10:08:
   mount something-else /foo
   systemctl start foo.mount
  In this case the second line is a NOP, since the first line already
  mounted something on /foo, and thus made foo.mount active.
 
 So, even if foo.mount (the actual unit file) specifies it's
 What=something (not What=something-else) the fact that *anything* is
 mounted to /foo is sufficient to make the foo.mount unit active?

Yes, and this always has been that way.

 This seems somewhat counter-intuitive to me. I can understand why from
 an implementation perspective - the mount units are all geared around
 the mountpoint not the What=, but it's certainly not what I'd expect as
 a user.

Well it's the only logic that can work really, already since the same
device node is usually known to the kernel by a different name thatn
to userspace. Trying to always map that is really nasty, as one can
see with the GPT generator complexity.

 Wouldn't it be better if there was some other state - e.g. conflict if
 something other than the desired device was mounted to the specified
 destination?

I think it's really safe not to consider that a problem.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-18 Thread Lennart Poettering 
On Tue, 17.02.15 20:05, Goffredo Baroncelli (kreij...@libero.it) wrote:

 Hi Lennart,
 
 On 2015-02-16 23:59, Lennart Poettering wrote:
  * journald now sets the special FS_NOCOW file flag for its
journal files. This should improve performance on btrfs, by
avoiding heavy fragmentation when journald's write-pattern
is used on COW file systems. It degrades btrfs' data
integrity guarantees for the files to the same levels as for
ext3/ext4 however. This should be OK though as journald does
its own data integrity checks and all its objects are
checksummed on disk. Also, journald should handle btrfs disk
full events a lot more gracefully now, by processing SIGBUS
errors, and not relying on fallocate() anymore.
 
 If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e.
 when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. 
 It is true ?

Well, we try to unset it, but this is not allowed by btrfs. However,
given that it might be allowed one day, we do it anyway.

In effect this means FS_NOCOW is set for good once we turn it on.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-18 Thread Joonas Sarajärvi 
2015-02-18 12:19 GMT+02:00 Lennart Poettering lenn...@poettering.net:
 On Wed, 18.02.15 12:13, Joonas Sarajärvi (m...@iki.fi) wrote:

 2015-02-18 12:07 GMT+02:00 Lennart Poettering lenn...@poettering.net:
  On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 
  btrfs checksumming theoretically allows you to transparently recover
  after media corruption if filesystem has redundancy (more than one copy
  of data). Journald checksum will probably detect corruption, but can it
  repair it?
 
  No it cannot.
 
  But btrfs checksumming cannot fix things for you either if you lose
  non-trivial amounts of data. It might be able to fix a few bits of
  errors, but not non-trivial amounts. I mean, that's a simple property
  of error correction codes: the more you want to be able to correct the
  longer must your checksum be. Neither btrfs' nor journald's are
  substantial enough to correct even a sector...
 
  Lennart
 

 My impression is that btrfs can fix the corruption in cases where a
 e.g. a RAID1 of btrfs is used.

 FS_NOCOW does no effect btrfs raid settings. If you want this kind of
 data redundancy then it will continue to be available even though we
 set FS_NOCOW now.


Thank you for the quick response.

Do you mean that btrfs scrub will be able to detect which of the
copies is correct, if one of the copies of a file flagged with
FS_NOCOW gets changed due to disk corruption? My impression is that
FS_NOCOW would result in the redundant copies of file data not having
checksums that'd be correctly maintained. So btrfs scrub could
possibly detect that the copies differ, but it would not be able to
decide which one to discard.

AFAIK btrfs would normally able to do this, write a new copy of the
intact file data and discard the corrupt one.

-Joonas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-18 Thread Lennart Poettering 
On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 В Wed, 18 Feb 2015 01:14:44 +0100
 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:
 
  On Tue, Feb 17, 2015 at 08:05:29PM +0100, Goffredo Baroncelli wrote:
   Hi Lennart,
   
   On 2015-02-16 23:59, Lennart Poettering wrote:
* journald now sets the special FS_NOCOW file flag for its
  journal files. This should improve performance on btrfs, by
  avoiding heavy fragmentation when journald's write-pattern
  is used on COW file systems. It degrades btrfs' data
  integrity guarantees for the files to the same levels as for
  ext3/ext4 however. This should be OK though as journald does
  its own data integrity checks and all its objects are
  checksummed on disk. Also, journald should handle btrfs disk
  full events a lot more gracefully now, by processing SIGBUS
  errors, and not relying on fallocate() anymore.
   
   If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e.
   when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. 
   It is true ?
  Yes, but you miss the point in general. FS_NOCOW is set during the
  entire time when the file is being written to, which could be months,
  and then it is unset when the file will not be written to anymore. So
  indeed, the file is not protected by btrfs checksums for the majority
  of time, but journald does its own checksumming, so the contents are
  protected in a different way.
  
 
 btrfs checksumming theoretically allows you to transparently recover
 after media corruption if filesystem has redundancy (more than one copy
 of data). Journald checksum will probably detect corruption, but can it
 repair it?

No it cannot.

But btrfs checksumming cannot fix things for you either if you lose
non-trivial amounts of data. It might be able to fix a few bits of
errors, but not non-trivial amounts. I mean, that's a simple property
of error correction codes: the more you want to be able to correct the
longer must your checksum be. Neither btrfs' nor journald's are
substantial enough to correct even a sector...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-18 Thread Joonas Sarajärvi 
2015-02-18 12:07 GMT+02:00 Lennart Poettering lenn...@poettering.net:
 On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidj...@gmail.com) wrote:


 btrfs checksumming theoretically allows you to transparently recover
 after media corruption if filesystem has redundancy (more than one copy
 of data). Journald checksum will probably detect corruption, but can it
 repair it?

 No it cannot.

 But btrfs checksumming cannot fix things for you either if you lose
 non-trivial amounts of data. It might be able to fix a few bits of
 errors, but not non-trivial amounts. I mean, that's a simple property
 of error correction codes: the more you want to be able to correct the
 longer must your checksum be. Neither btrfs' nor journald's are
 substantial enough to correct even a sector...

 Lennart


My impression is that btrfs can fix the corruption in cases where a
e.g. a RAID1 of btrfs is used. As journal performance has already been
sufficient for my needs on btrfs, I would prefer to be able to
configure journald so that it'd keep the journal files with default
flags.

-Joonas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-18 Thread Lennart Poettering 
On Wed, 18.02.15 12:13, Joonas Sarajärvi (m...@iki.fi) wrote:

 2015-02-18 12:07 GMT+02:00 Lennart Poettering lenn...@poettering.net:
  On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidj...@gmail.com) wrote:
 
 
  btrfs checksumming theoretically allows you to transparently recover
  after media corruption if filesystem has redundancy (more than one copy
  of data). Journald checksum will probably detect corruption, but can it
  repair it?
 
  No it cannot.
 
  But btrfs checksumming cannot fix things for you either if you lose
  non-trivial amounts of data. It might be able to fix a few bits of
  errors, but not non-trivial amounts. I mean, that's a simple property
  of error correction codes: the more you want to be able to correct the
  longer must your checksum be. Neither btrfs' nor journald's are
  substantial enough to correct even a sector...
 
  Lennart
 
 
 My impression is that btrfs can fix the corruption in cases where a
 e.g. a RAID1 of btrfs is used. 

FS_NOCOW does no effect btrfs raid settings. If you want this kind of
data redundancy then it will continue to be available even though we
set FS_NOCOW now.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-18 Thread Goffredo Baroncelli 
Hi Lennart
On 2015-02-18 11:19, Lennart Poettering wrote:
 On Wed, 18.02.15 12:13, Joonas Sarajärvi (m...@iki.fi) wrote:
 

 
 FS_NOCOW does no effect btrfs raid settings. If you want this kind of
 data redundancy then it will continue to be available even though we
 set FS_NOCOW now.

Whitout checksum, BTRFS was unable to restore a good copy: in case of 
RAID1 a flip of a bit  makes the two copies different. Only the checksum
allows to detected which is the good copy.

This was already discussed in the thread (see the answers of Zygo and 
Chris Murhpy other than the my one)

http://www.spinics.net/lists/linux-btrfs/msg41024.html


 
 Lennart
 
Goffredo

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-18 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Feb 18, 2015 at 11:03:39AM +0100, Lennart Poettering wrote:
 Well it's the only logic that can work really, already since the same
 device node is usually known to the kernel by a different name thatn
 to userspace. Trying to always map that is really nasty, as one can
 see with the GPT generator complexity.
 
  Wouldn't it be better if there was some other state - e.g. conflict if
  something other than the desired device was mounted to the specified
  destination?
 
 I think it's really safe not to consider that a problem.
Yes, especially that the administator must take explicit manual
actions to reach this state. They should remember that they did that.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-18 Thread Maciej Wereski 
Dnia wtorek, 17 lutego 2015 17:23:55 Lennart Poettering pisze:
 On Tue, 17.02.15 17:13, Maciej Wereski (m.were...@partner.samsung.com) 
wrote:
  Hello,
  
  Dnia poniedziałek, 16 lutego 2015 23:59:56 Lennart Poettering pisze:
   Note that this version is not available in Fedora F22/F23 yet. The
   linker on ARM segfaults. Since the i386 and x86_64 versions built
   fine, I decided to release 219 anyway.
  
  I was able to build systemd v219 both on armv7l and aarch64. As a
  workaround I had to disable Link Time Optimizations.
 
 Well, did it segfault for you if you had lto on?
 
 This toolchain bug is tracked here btw:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=1193212

No, we have some issues rather specific to our buildsystem.

-- 
Maciej Wereski
Samsung RD Institute Poland
Samsung Electronics
m.were...@partner.samsung.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-17 Thread Andrei Borzenkov 
В Wed, 18 Feb 2015 01:14:44 +0100
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:

 On Tue, Feb 17, 2015 at 08:05:29PM +0100, Goffredo Baroncelli wrote:
  Hi Lennart,
  
  On 2015-02-16 23:59, Lennart Poettering wrote:
   * journald now sets the special FS_NOCOW file flag for its
 journal files. This should improve performance on btrfs, by
 avoiding heavy fragmentation when journald's write-pattern
 is used on COW file systems. It degrades btrfs' data
 integrity guarantees for the files to the same levels as for
 ext3/ext4 however. This should be OK though as journald does
 its own data integrity checks and all its objects are
 checksummed on disk. Also, journald should handle btrfs disk
 full events a lot more gracefully now, by processing SIGBUS
 errors, and not relying on fallocate() anymore.
  
  If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e.
  when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. 
  It is true ?
 Yes, but you miss the point in general. FS_NOCOW is set during the
 entire time when the file is being written to, which could be months,
 and then it is unset when the file will not be written to anymore. So
 indeed, the file is not protected by btrfs checksums for the majority
 of time, but journald does its own checksumming, so the contents are
 protected in a different way.
 

btrfs checksumming theoretically allows you to transparently recover
after media corruption if filesystem has redundancy (more than one copy
of data). Journald checksum will probably detect corruption, but can it
repair it?


  If so, the time window where a file is un-protect by the checksum is
  quite small. I was worried not about the corruption detection but about 
  loosing 
  the ability to recover the file from a good copy (if available) in case of 
  corruption. 
  But this seems limited only when the file is in use (before the next 
  rotation).
 
 Zbyszek
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-17 Thread Colin Guthrie 
Lennart Poettering wrote on 17/02/15 10:08:
  mount something-else /foo
  systemctl start foo.mount
 In this case the second line is a NOP, since the first line already
 mounted something on /foo, and thus made foo.mount active.

So, even if foo.mount (the actual unit file) specifies it's
What=something (not What=something-else) the fact that *anything* is
mounted to /foo is sufficient to make the foo.mount unit active?

This seems somewhat counter-intuitive to me. I can understand why from
an implementation perspective - the mount units are all geared around
the mountpoint not the What=, but it's certainly not what I'd expect as
a user.

Wouldn't it be better if there was some other state - e.g. conflict if
something other than the desired device was mounted to the specified
destination?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-17 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Feb 18, 2015 at 06:22:38AM +0300, Andrei Borzenkov wrote:
 В Wed, 18 Feb 2015 01:14:44 +0100
 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:
 
  On Tue, Feb 17, 2015 at 08:05:29PM +0100, Goffredo Baroncelli wrote:
   Hi Lennart,
   
   On 2015-02-16 23:59, Lennart Poettering wrote:
* journald now sets the special FS_NOCOW file flag for its
  journal files. This should improve performance on btrfs, by
  avoiding heavy fragmentation when journald's write-pattern
  is used on COW file systems. It degrades btrfs' data
  integrity guarantees for the files to the same levels as for
  ext3/ext4 however. This should be OK though as journald does
  its own data integrity checks and all its objects are
  checksummed on disk. Also, journald should handle btrfs disk
  full events a lot more gracefully now, by processing SIGBUS
  errors, and not relying on fallocate() anymore.
   
   If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e.
   when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. 
   It is true ?
  Yes, but you miss the point in general. FS_NOCOW is set during the
  entire time when the file is being written to, which could be months,
  and then it is unset when the file will not be written to anymore. So
  indeed, the file is not protected by btrfs checksums for the majority
  of time, but journald does its own checksumming, so the contents are
  protected in a different way.
  
 
 btrfs checksumming theoretically allows you to transparently recover
 after media corruption if filesystem has redundancy (more than one copy
 of data). Journald checksum will probably detect corruption, but can it
 repair it?
No.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-17 Thread Lennart Poettering 
On Tue, 17.02.15 17:13, Maciej Wereski (m.were...@partner.samsung.com) wrote:

 Hello,
 
 Dnia poniedziałek, 16 lutego 2015 23:59:56 Lennart Poettering pisze:
 
  
  Note that this version is not available in Fedora F22/F23 yet. The
  linker on ARM segfaults. Since the i386 and x86_64 versions built
  fine, I decided to release 219 anyway.
  
 
 I was able to build systemd v219 both on armv7l and aarch64. As a workaround 
 I 
 had to disable Link Time Optimizations.

Well, did it segfault for you if you had lto on?

This toolchain bug is tracked here btw:

https://bugzilla.redhat.com/show_bug.cgi?id=1193212

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-17 Thread Maciej Wereski 
Hello,

Dnia poniedziałek, 16 lutego 2015 23:59:56 Lennart Poettering pisze:

 
 Note that this version is not available in Fedora F22/F23 yet. The
 linker on ARM segfaults. Since the i386 and x86_64 versions built
 fine, I decided to release 219 anyway.
 

I was able to build systemd v219 both on armv7l and aarch64. As a workaround I 
had to disable Link Time Optimizations.

Tizen 3.0:
gcc 4.9.2
binutils 2.24.90

cheers,
-- 
Maciej Wereski
Samsung RD Institute Poland
Samsung Electronics
m.were...@partner.samsung.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd 219

2015-02-17 Thread Goffredo Baroncelli 
Hi Lennart,

On 2015-02-16 23:59, Lennart Poettering wrote:
 * journald now sets the special FS_NOCOW file flag for its
   journal files. This should improve performance on btrfs, by
   avoiding heavy fragmentation when journald's write-pattern
   is used on COW file systems. It degrades btrfs' data
   integrity guarantees for the files to the same levels as for
   ext3/ext4 however. This should be OK though as journald does
   its own data integrity checks and all its objects are
   checksummed on disk. Also, journald should handle btrfs disk
   full events a lot more gracefully now, by processing SIGBUS
   errors, and not relying on fallocate() anymore.

If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e.
when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. 
It is true ?

If so, the time window where a file is un-protect by the checksum is
quite small. I was worried not about the corruption detection but about loosing 
the ability to recover the file from a good copy (if available) in case of 
corruption. 
But this seems limited only when the file is in use (before the next rotation).

BR
G.Baroncelli
-- 
gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [ANNOUNCE] systemd 219

2015-02-16 Thread Lennart Poettering 
Heya!

Many many improvements, in particular in the area of containers, btrfs
hookup, and networkd. Also, many bugfixes. Enjoy!

http://www.freedesktop.org/software/systemd/systemd-219.tar.xz

Note that this version is not available in Fedora F22/F23 yet. The
linker on ARM segfaults. Since the i386 and x86_64 versions built
fine, I decided to release 219 anyway.

CHANGES WITH 219:

* Introduce a new API sd-hwdb.h for querying the hardware
  metadata database. With this minimal interface one can query
  and enumerate the udev hwdb, decoupled from the old libudev
  library. libudev's interface for this is now only a wrapper
  around sd-hwdb. A new tool systemd-hwdb has been added to
  interface with and update the database.

* When any of systemd's tools copies files (for example due to
  tmpfiles' C lines) a btrfs reflink will attempted first,
  before bytewise copying is done.

* systemd-nspawn gained a new --ephemeral switch. When
  specified a btrfs snapshot is taken of the container's root
  directory, and immediately removed when the container
  terminates again. Thus, a container can be started whose
  changes never alter the container's root directory, and are
  lost on container termination. This switch can also be used
  for starting a container off the root file system of the
  host without affecting the host OS. This switch is only
  available on btrfs file systems.

* systemd-nspawn gained a new --template= switch. It takes the
  path to a container tree to use as template for the tree
  specified via --directory=, should that directory be
  missing. This allows instantiating containers dynamically,
  on first run. This switch is only available on btrfs file
  systems.

* When a .mount unit refers to a mount point on which multiple
  mounts are stacked, and the .mount unit is stopped all of
  the stacked mount points will now be unmounted until no
  mount point remains.

* systemd now has an explicit notion of supported and
  unsupported unit types. Jobs enqueued for unsupported unit
  types will now fail with an unsupported error code. More
  specifically .swap, .automount and .device units are not
  supported in containers, .busname units are not supported on
  non-kdbus systems. .swap and .automount are also not
  supported if their respective kernel compile time options
  are disabled.

* machinectl gained support for two new copy-from and
  copy-to commands for copying files from a running
  container to the host or vice versa.

* machinectl gained support for a new bind command to bind
  mount host directories into local containers. This is
  currently only supported for nspawn containers.

* networkd gained support for configuring bridge forwarding
  database entries (fdb) from .network files.

* A new tiny daemon systemd-importd has been added that can
  download container images in tar, raw, qcow2 or dkr formats,
  and make them available locally in /var/lib/machines, so
  that they can run as nspawn containers. The daemon can GPG
  verify the downloads (not supported for dkr, since it has no
  provisions for verifying downloads). It will transparently
  decompress bz2, xz, gzip compressed downloads if necessary,
  and restore sparse files on disk. The daemon uses privilege
  separation to ensure the actual download logic runs with
  fewer privileges than the deamon itself. machinectl has
  gained new commands pull-tar, pull-raw and pull-dkr to
  make the functionality of importd available to the
  user. With this in place the Fedora and Ubuntu Cloud
  images can be downloaded and booted as containers unmodified
  (the Fedora images lack the appropriate GPG signature files
  currently, so they cannot be verified, but this will change
  soon, hopefully). Note that downloading images is currently
  only fully supported on btrfs.

* machinectl is now able to list container images found in
  /var/lib/machines, along with some metadata about sizes of
  disk and similar. If the directory is located on btrfs and
  quota is enabled, this includes quota display. A new command
  image-status has been added that shows additional
  information about images.

* machinectl is now able to clone container images
  efficiently, if the underlying file system (btrfs) supports
  it, with the new machinectl list-images command. It also
  gained commands for renaming and removing images, as well as
  marking them read-only or