RAID56 Warning on "multiple serious data-loss bugs"

Hi All, For clarity for the masses, what are the "multiple serious data-loss bugs" as mentioned in the btrfs wiki? The bullet points on this page: https://btrfs.wiki.kernel.org/index.php/RAID56 don't enumerate the bugs.  Not even in a high level.  If anything what can be closest to a bug or

Re: RAID56 Warning on "multiple serious data-loss bugs"

DanglingPointer wrote: Hi All, For clarity for the masses, what are the "multiple serious data-loss bugs" as mentioned in the btrfs wiki? The bullet points on this page: https://btrfs.wiki.kernel.org/index.php/RAID56 don't enumerate the bugs.  Not even in a high level.  If anything what can

Re: RAID56 Warning on "multiple serious data-loss bugs"

On 2019-01-26 7:07 a.m., waxhead wrote: > > What effect exactly the write hole might have on *data* is not pointed > out in detail, but I would imagine that for some it might be desirable > to run a btrfs filesystem with metadata in "RAID" 1/10 mode and data in > "RAID" 5/6. > One big problem

btrfs-heatmap v8

Now that python-btrfs v10 is out, I can also finally update btrfs-heatmap. The new version v8 is available at https://github.com/knorrie/btrfs-heatmap or, probably in your distro package manager soon-ish. Note: Just like python-btrfs, I converted the branches in git for debian packaging to the

Re: Incremental receive completes succesfully despite missing files

On Fri, Jan 25, 2019 at 7:43 PM Dennis Katsonis wrote: > > On 1/25/19 4:22 AM, Chris Murphy wrote: > > On Thu, Jan 24, 2019 at 3:40 AM Dennis K wrote: > >> > >> The fact is, this thread is the first time I've seen explicitly written > >> that parents must be the same at receiving and sending ends

Re: Incremental receive completes succesfully despite missing files

On 1/27/19 10:09 AM, Chris Murphy wrote: > On Fri, Jan 25, 2019 at 7:43 PM Dennis Katsonis > wrote: >> >> On 1/25/19 4:22 AM, Chris Murphy wrote: >>> On Thu, Jan 24, 2019 at 3:40 AM Dennis K wrote: The fact is, this thread is the first time I've seen explicitly written that parent

[PATCH] btrfs: oops in device_list_add()

alloc_fs_devices() can return ERR_PTR(-ENOMEM), so dereferencing its result before the check for IS_ERR() is a bad idea... Fixes: d1a63002829a4 Signed-off-by: Al Viro --- diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 85149f27644d..72adc5643bde 100644 --- a/fs/btrfs/volumes.c