On Mon, 23 Feb 2015 16:46:34 -0600
T.J. Duchene t.j.duch...@gmail.com wrote:
My philosopher as a free software author is this: The buck stops
with me. If my software screws up, it's my fault and my
responsibility to fix, regardless of the actual root cause is in
code I wrote or a tool
On Tue, Feb 24, 2015 at 12:57 AM, Noel Torres env...@rolamasao.org wrote:
We have RAID tools like mdadm for RAID, and filesystems like ext4 or Reiserfs
for file storage.
Why would I want a tool combining both?
You'd want one so you can, for isntance, avoid a RAID5 write hole. ZFS
seems pretty
On Mon, Feb 23, 2015 at 11:47:16AM +0100, Didier Kryn wrote:
As far as I understand, COW means that the whole file is
rewritten everytime you change a single byte in it (or is it only
some extent?). That's a real mess when you are continuously
appending to files hundreds of megabytes
On Sunday, 22 de February de 2015 18:28:06 Jim Murphy escribió:
[...]
If I have a btrfs mirror and I didn't mess with it by setting FS_NOCOW,
shouldn't I be able to recover the file? I would sure hope so. He
creates this better way of logging, then he seems to not even care if
you can use
On Monday, February 23, 2015 04:46:34 PM you wrote:
My philosopher as a free software author is this: The buck stops with
me. If my software screws up, it's my fault and my responsibility to
fix, regardless of the actual root cause is in code I wrote or a tool I
use.
If I were having
Hi,
First let me make it clear I'm not a fan of either systemd of journald.
I've been watching the btrfs-linux mailing list, when the following
subject popped up a few days ago:
Systemd 219 now sets the special FS_NOCOW file flag for its journal
files, possibly breaking RAID repairs.[1]
Systemd, to me, is a horror story. The more I read the scarier it gets.
At the very beginning of the 219 Lennart announcement you find this:
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
