RE: Raid 0 setup doubt.

[James Johnston]

Sorry to interject here, but I think it's a bit overreaching to suggest
that swap isn't generally useful any more as a general-purpose member of
the memory hierarchy

> Given that swap on spinning rust is slower than real
> RAM by several orders of magnitude, it'll still be far slower than real
> RAM, but twice as fast as it would be is better than otherwise, so...
> 
> 
> Tho how much RAM /do/ you have, and are you sure you really need swap at
> all?  Many systems today have enough RAM that they don't really need swap
> (at least as swap, see below), unless they're going to be used for
> something extremely memory intensive, where the much lower speed of swap
> isn't a problem.

For me, I use swap on an SSD, which is orders of magnitude faster than HDD.
Swap can still be useful on an SSD and can really close the gap between RAM
speeds and swap speeds.  (The original poster would do well to use one.)

So yeah, it's still "slow memory" but fast enough to be useful IMHO.

I find it's a useful safety net.  I'd rather have slower performance than
have outright failures.  Gives me time to react and free memory in a sane
fashion.  Why *not* use swap, if you have the drive capacity available?
The space is way cheaper than RAM, even for SSD.

> 
> Anyway, for systems with enough memory to not need swap in /normal/
> circumstances, in the event that something's actually leaking memory
> badly enough that swap is needed, there's a very good chance that you'll
> never outrun the leak with swap anyway, as if it's really leaking gigs of
> memory, it'll just eat up whatever gigs of swap you throw at it as well
> and /still/ run out of memory.

Often it's a slow leak and if you monitor the system, you have time to
identify the offending process and kill it before it impacts the rest of
the system.  Swap gives more time to do that.

> 
> Meanwhile, swap to spinning rust really is /slow/.  You're talking 16 GiB
> of swap, and spinning rust speeds of 50 MiB/sec for swap isn't unusual.
> That's ~20 seconds worth of swap-thrashing waiting per GiB, ~320 seconds
> or over five minutes worth of swap thrashing to use the full 16 GiB.  OK,
> so you take that priority= idea and raid0 over two devices, it'll still
> be ~2:40 worth of waiting, to fully use that swap.  Is 16 GiB of swap
> /really/ both needed and worth that sort of wait if you do actually use
> it?
>
> So swap, for its original use as slow memory at least, really isn't that
> much used any longer, tho it can still be quite useful in specific use-
> cases.

On my Windows boxes, I've exhausted system memory, and sometimes *not even
immediately noticed that I was out of physical RAM*.  The SSD-based swap
was that fast.  Eventually I realized the system was somewhat sluggish,
and closing some programs was easy to recover the system, and nothing ever
crashed.

Last week I ran chkdsk /R on a drive and apparently on Windows 7, chkdsk
will allocate all the free RAM it can get... apparently that is a
"feature" - anyway in my case, chkdsk allocates 26 GB on a 32 GB RAM
system that I heavily multitask on.  I never noticed the system was
swapping until an hour or two later when I had to start a VM and got an
error message (VirtualBox needed physical RAM to allocate)...

But before I had SSDs, HDD-based swap was very painful...  IMHO, HDDs
are obsolete for use for storing operating systems and swap.  I strongly
suggest the original poster add an SSD to the mix. :)

And now with things like bcache, we can put SSDs into their proper place
in the memory hierarchy: Registers > L1 cache > L2 > L3 > DRAM > SSD > HDD.
So conceivably the swap could be on both SSD and HDD, but you probably
don't need _that_ much swap...

Best regards,

James Johnston


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Compression causes kernel crashes if there are I/O or checksum errors (was: RE: kernel BUG at fs/btrfs/volumes.c:5519 when hot-removing device in RAID-1)

[James Johnston]

Hi,

After puzzling over the btrfs failure I reported here a week ago, I think there
is a bad incompatibility between compression and RAID-1 (maybe other RAID
levels too?).  I think it is unsafe for users to use compression, at least with
multiple devices until this is fixed/investigated further.  That seems like a
drastic claim, but I know I will not be using it for now.  Otherwise, checksum
errors scattered across multiple devices that *should* be recoverable will
render the file system unusable, even to read data from.  (One alternative
hypothesis might be that defragmentation causes the issue, since I used
defragment to compress existing files.)

I finally was able to simplify this to a hopefully easy to reproduce test case,
described in lengthier detail below.  In summary, suppose we start with an
uncompressed btrfs file system on only one disk containing the root file system,
such as created by a clean install of a Linux distribution.  I then:
(1) enable compress=lzo in fstab, reboot, and then defragment the disk to
compress all the existing files, (2) add a second drive to the array and balance
for RAID-1, (3) reboot for good measure, (4) cause a high level of I/O errors,
such as hot-removal of the second drive, OR simply a high level of bit rot
(i.e. use dd to corrupt most of the disk, while either mounted or unmounted).
This is guaranteed to cause the kernel to crash.

If the compression step is skipped such that the volume is uncompressed, you
get lots of I/O errors logged - as expected.  For hot-removal, as you point out,
patches to auto-degrade the array aren't merged yet.  For bit rot, the file
system should log lots of checksum errors and corrections, but again should
succeed.  Most importantly, the kernel _does not fall over_ and bring the
system down.  I think that's acceptable behavior until the patches you mention
are merged.

> There are a number of things missing from multiple device support,
> including any concept of a device becoming faulty (i.e. persistent
> failures rather than transient which Btrfs seems to handle OK for the
> most part), and then also getting it to go degraded automatically, and
> finally hot spare support. There are patches that could use testing.

I think in general, if the system can't handle a persistent failure, it can't
reliably handle a transient failure either... you're just less likely to
notice...  The permanent failure just stress-tests the failure code - if you
pay attention to the test case when hot removing, you'll note that oftentimes
dozens of I/O errors are mitigated successfully before one of them finally
brings the system down.

What you've described above in the patch series are nice-to-have "fancy
features" and I do hope they eventually get tested and merged, but I also hope
the above patches let you disable them all so that one can stress-test the code
handling I/O failures without having a drive get auto-dropped from the array
before you tested the failure code enough.  The I/O errors in my dmesg I'm OK
with, but I think if the file system crashes the kernel it's bad news.

> I think when testing, it's simpler to not use any additional device
> mapper layers.

The test case eliminates all device mapper layers, and just uses raw
disks/partitions.  Here it is - skip to step #5 for the meat of it:

1.  Set up a new VirtualBox VM with:
* System: Enable EFI
* System: 8 GB RAM
* System: 1 processor
* Storage: Two SATA hard drives, 8 GB each, backed by dynamic VDI files
* Storage: Default IDE CD-ROM is fine
* Storage: The SATA hard drives must be hot-pluggable
* Network: As you require
* Serial port for debugging

2.  Boot to http://releases.ubuntu.com/15.10/ubuntu-15.10-server-amd64.iso

3.  Install Ubuntu 15.10 with default settings except as noted below:
a.  Network/user settings: make up settings/accounts as needed.
b.  Use Manual partitioning with these partitions on /dev/sda, in the
following order:
* 100 MB EFI System Partition
* 500 MB btrfs, mount point at /boot
* Remaining space: btrfs: mount point at /

4.  Install and boot into 4.6 rc-1 mainline kernel:

wget 
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc1-wily/linux-image-4.6.0-040600rc1-generic_4.6.0-040600rc1.201603261930_amd64.deb
dpkg -i 
linux-image-4.6.0-040600rc1-generic_4.6.0-040600rc1.201603261930_amd64.deb
reboot

5.  Set up compression and RAID-1 for root partition onto /dev/sdb:

# Add "compress=lzo" to all btrfs mounts:
vim /etc/fstab
reboot   # to take effect
# Add second drive
btrfs device add /dev/sdb /
# Defragment to compress files
btrfs filesystem defragment -v -c -r /home
btrfs filesystem defragment -v -c -r /
# Balance to RAID-1
btrfs balance start -dconvert=raid1 -mconvert=raid1 -v /
# btrfs fi usage says there was some single data until I did this, too:
btrfs balance start -dconvert=raid1 -mconvert=raid1 -v /home
# Make 

Re: Possible Raid Bug

[Anand Jain]

Hi Patrik,

Thanks for posting a test case. more below.

On 03/26/2016 07:51 PM, Patrik Lundquist wrote:

So with the lessons learned:

# mkfs.btrfs -m raid10 -d raid10 /dev/sdb /dev/sdc /dev/sdd /dev/sde

# mount /dev/sdb /mnt; dmesg | tail
# touch /mnt/test1; sync; btrfs device usage /mnt

Only raid10 profiles.

# echo 1 >/sys/block/sde/device/delete

We lost a disk.

# touch /mnt/test2; sync; dmesg | tail

We've got write errors.

# btrfs device usage /mnt

No 'single' profiles because we haven't remounted yet.

# reboot
# wipefs -a /dev/sde; reboot

# mount -o degraded /dev/sdb /mnt; dmesg | tail
# btrfs device usage /mnt

Still only raid10 profiles.

# touch /mnt/test3; sync; btrfs device usage /mnt

Now we've got 'single' profiles. Replace now or get hosed.


 Since you are replacing the failed device without mount/unmount/reboot,
 so this should work.

 And you would need those parts of hot spare/auto replace patches only
 if the test case had unmount/mount or reboot at this stage.



# btrfs replace start -B 4 /dev/sde /mnt; dmesg | tail

# btrfs device stats /mnt

[/dev/sde].write_io_errs   0
[/dev/sde].read_io_errs0
[/dev/sde].flush_io_errs   0
[/dev/sde].corruption_errs 0
[/dev/sde].generation_errs 0

We didn't inherit the /dev/sde error count. Is that a bug?


  No. Its other way, it would have been a bug if the replace-target
  inherited the error counters.


# btrfs balance start -dconvert=raid10,soft -mconvert=raid10,soft
-sconvert=raid10,soft -vf /mnt; dmesg | tail

# btrfs device usage /mnt

Back to only 'raid10' profiles.

# umount /mnt; mount /dev/sdb /mnt; dmesg | tail

# btrfs device stats /mnt

[/dev/sde].write_io_errs   11
[/dev/sde].read_io_errs0
[/dev/sde].flush_io_errs   2
[/dev/sde].corruption_errs 0
[/dev/sde].generation_errs 0

The old counters are back. That's good, but wtf?


 No. I doubt if they are old counters. The steps above didn't
 show old error counts, but since you have created a file
 test3 so there will be some write_io_errors, which we don;t
 see after the balance. So I doubt if they are old counter
 but instead they are new flush errors.


# btrfs device stats -z /dev/sde

Give /dev/sde a clean bill of health. Won't warn when mounting again.





Thanks, Anand

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Raid 0 setup doubt.

[Chris Murphy]

On Sun, Mar 27, 2016 at 4:35 AM, Jose Otero  wrote:
> Hello,
>
> --
> I apologize beforehand if I'm asking a too basic question for the
> mailing list, or if it has been already answered at nauseam.
> --
>
> I have two hdd (Western Digital 750 GB approx. 700 GiB each), and I
> planning to set up a RAID 0 through btrfs. UEFI firmware/boot, no dual
> boot, only linux.
>
> My question is, given the UEFI partition plus linux swap partition, I
> won't have two equal sized partitions for setting up the RAID 0 array.

If you have odd sized partitions for Btrfs raid0, it won't get mad at
you. It just won't use the extra space on the drive without a swap
partition.


http://www.tldp.org/HOWTO/Partition/setting_up_swap.html
If that's current, you can have a swap on each drive, same size, with
the same priority number, and the kernel will use both kinda like
raid0. And in this case, you can have pretty much identically sized
swap partitions on the two drives.



-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs_destroy_inode WARN_ON.

[Dave Jones]

On Thu, Mar 24, 2016 at 06:54:11PM -0400, Dave Jones wrote:
 > Just hit this on a tree from earlier this morning, v4.5-11140 or so.
 > 
 > WARNING: CPU: 2 PID: 32570 at fs/btrfs/inode.c:9261 
 > btrfs_destroy_inode+0x389/0x3f0 [btrfs]
 > CPU: 2 PID: 32570 Comm: rm Not tainted 4.5.0-think+ #14
 >  c039baf9 ef721ef0 88025966fc08 8957bcdb
 >    88025966fc50 890b41f1
 >  88045d918040 242d4eed6048 88024eed6048 88024eed6048
 > Call Trace:
 >  [] ? btrfs_destroy_inode+0x389/0x3f0 [btrfs]
 >  [] dump_stack+0x68/0x9d
 >  [] __warn+0x111/0x130
 >  [] warn_slowpath_null+0x1d/0x20
 >  [] btrfs_destroy_inode+0x389/0x3f0 [btrfs]
 >  [] destroy_inode+0x67/0x90
 >  [] evict+0x1b7/0x240
 >  [] iput+0x3ae/0x4e0
 >  [] ? dput+0x20e/0x460
 >  [] do_unlinkat+0x256/0x440
 >  [] ? do_rmdir+0x350/0x350
 >  [] ? syscall_trace_enter_phase1+0x87/0x260
 >  [] ? enter_from_user_mode+0x50/0x50
 >  [] ? __lock_is_held+0x25/0xd0
 >  [] ? mark_held_locks+0x22/0xc0
 >  [] ? syscall_trace_enter_phase2+0x12d/0x3d0
 >  [] ? SyS_rmdir+0x20/0x20
 >  [] SyS_unlinkat+0x1b/0x30
 >  [] do_syscall_64+0xf4/0x240
 >  [] entry_SYSCALL64_slow_path+0x25/0x25
 > ---[ end trace a48ce4e6a1b5e409 ]---
 > 
 > 
 > That's WARN_ON(BTRFS_I(inode)->csum_bytes);
 > 
 > *maybe* it's a bad disk, but there's no indication in dmesg of anything awry.
 > Spinning rust on SATA, nothing special.

Same WARN_ON is reachable from umount too..

WARNING: CPU: 2 PID: 20092 at fs/btrfs/inode.c:9261 
btrfs_destroy_inode+0x40c/0x480 [btrfs]
CPU: 2 PID: 20092 Comm: umount Tainted: GW   4.5.0-think+ #1
  a32c482b 8803cd187b60 9d63af84
   c05c5e40 c04d316c
 8803cd187ba8 9d0c4c27 880460d80040 242dcd187bb0
Call Trace:
 [] dump_stack+0x95/0xe1
 [] ? btrfs_destroy_inode+0x40c/0x480 [btrfs]
 [] __warn+0x147/0x170
 [] warn_slowpath_null+0x31/0x40
 [] btrfs_destroy_inode+0x40c/0x480 [btrfs]
 [] ? btrfs_test_destroy_inode+0x40/0x40 [btrfs]
 [] destroy_inode+0x77/0xb0
 [] evict+0x20e/0x2c0
 [] dispose_list+0x70/0xb0
 [] evict_inodes+0x26f/0x2c0
 [] ? inode_add_lru+0x60/0x60
 [] ? fsnotify_unmount_inodes+0x215/0x2c0
 [] generic_shutdown_super+0x76/0x1c0
 [] kill_anon_super+0x29/0x40
 [] btrfs_kill_super+0x31/0x130 [btrfs]
 [] deactivate_locked_super+0x6f/0xb0
 [] deactivate_super+0x99/0xb0
 [] cleanup_mnt+0x70/0xd0
 [] __cleanup_mnt+0x1b/0x20
 [] task_work_run+0xef/0x130
 [] exit_to_usermode_loop+0xf9/0x100
 [] do_syscall_64+0x238/0x2b0
 [] entry_SYSCALL64_slow_path+0x25/0x25

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scrub: Tree block spanning stripes, ignored

[Qu Wenruo]

Ivan P wrote on 2016/03/27 16:31 +0200:

Thanks for the reply,

the raid1 array was created from scratch, so not converted from ext*.
I used btrfs-progs version 4.2.3 on kernel 4.2.5 to create the array, btw.


I don't remember any strange behavior after 4.0, so no clue here.

Go to the subvolume 5 (the top-level subvolume), find inode 71723 and 
try to remove it.

Then, use 'btrfs filesystem sync ' to sync the inode removal.

Finally use latest btrfs-progs to check if the problem disappears.

This problem seems to be quite strange, so I can't locate the root 
cause, but try to remove the file and hopes kernel can handle it.


Thanks,
Qu


Is there a way to fix the current situation without taking the whole
data off the disk?
I'm not familiar with file systems terms, so what exactly could I have
lost, if anything?

Regards,
Ivan

On Sun, Mar 27, 2016 at 4:23 PM, Qu Wenruo > wrote:



On 03/27/2016 05:54 PM, Ivan P wrote:

Read the info on the wiki, here's the rest of the requested
information:

# uname -r
4.4.5-1-ARCH

# btrfs fi show
Label: 'ArchVault'  uuid: cd8a92b6-c5b5-4b19-b5e6-a839828d12d8
 Total devices 1 FS bytes used 2.10GiB
 devid1 size 14.92GiB used 4.02GiB path /dev/sdc1

Label: 'Vault'  uuid: 013cda95-8aab-4cb2-acdd-2f0f78036e02
 Total devices 2 FS bytes used 800.72GiB
 devid1 size 931.51GiB used 808.01GiB path /dev/sda
 devid2 size 931.51GiB used 808.01GiB path /dev/sdb

# btrfs fi df /mnt/vault/
Data, RAID1: total=806.00GiB, used=799.81GiB
System, RAID1: total=8.00MiB, used=128.00KiB
Metadata, RAID1: total=2.00GiB, used=936.20MiB
GlobalReserve, single: total=320.00MiB, used=0.00B

On Fri, Mar 25, 2016 at 3:16 PM, Ivan P > wrote:

Hello,

using kernel  4.4.5 and btrfs-progs 4.4.1, I today ran a
scrub on my
2x1Tb btrfs raid1 array and it finished with 36
unrecoverable errors
[1], all blaming the treeblock 741942071296. Running "btrfs
check
--readonly" on one of the devices lists that extent as
corrupted [2].

How can I recover, how much did I really lose, and how can I
prevent
it from happening again?
If you need me to provide more info, do tell.

[1] http://cwillu.com:8080/188.110.141.36/1


This message itself is normal, it just means a tree block is
crossing 64K stripe boundary.
And due to scrub limit, it can check if it's good or bad.
But

[2] http://pastebin.com/xA5zezqw

This one is much more meaningful, showing several strange bugs.

1. corrupt extent record: key 741942071296 168 1114112
This means, this is a EXTENT_ITEM(168), and according to the offset,
it means the length of the extent is, 1088K, definitely not a valid
tree block size.

But according to [1], kernel think it's a tree block, which is quite
strange.
Normally, such mismatch only happens in fs converted from ext*.

2. Backref 741942071296 root 5 owner 71723 offset 2589392896
num_refs 0 not found in extent tree

num_refs 0, this is also strange, normal backref won't have a zero
refrence number.

3. bad metadata [741942071296, 741943185408) crossing stripe boundary
It could be a false warning fixed in latest btrfsck.
But you're using 4.4.1, so I think that's the problem.

4. bad extent [741942071296, 741943185408), type mismatch with chunk
This seems to explain the problem, a data extent appears in a
metadata chunk.
It seems that you're really using converted btrfs.

If so, just roll it back to ext*. Current btrfs-convert has known
bug but fix is still under review.

If want to use btrfs, use a newly created one instead of btrfs-convert.

Thanks,
Qu


Regards,
Soukyuu

P.S.: please add me to CC when replying as I did not
subscribe to the
mailing list. Majordomo won't let me use my hotmail address
and I
don't want that much traffic on this address.

--
To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
the body of a message to majord...@vger.kernel.org

More majordomo info at http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Raid 0 setup doubt.

[Duncan]

Jose Otero posted on Sun, 27 Mar 2016 12:35:43 +0200 as excerpted:

> Hello,
> 
> --
> I apologize beforehand if I'm asking a too basic question for the
> mailing list, or if it has been already answered at nauseam.
> --

Actually, looks like pretty reasonable questions, to me. =:^)

> I have two hdd (Western Digital 750 GB approx. 700 GiB each), and I
> planning to set up a RAID 0 through btrfs. UEFI firmware/boot, no dual
> boot, only linux.
> 
> My question is, given the UEFI partition plus linux swap partition, I
> won't have two equal sized partitions for setting up the RAID 0 array.
> So, I'm not quite sure how to do it. I'll have:
> 
> /dev/sda:
> 
>16 KiB (GPT partition table)
> sda1:  512 MiB (EFI, fat32)
> sda2:  16 GiB (linux-swap)
> sda3:  rest of the disk /  (btrfs)
> 
> /dev/sdb:
> 
> sdb1:  (btrfs)
> 
> The btrfs partitions on each hdd are not of the same size (admittedly by
> an small difference, but still). Even if a backup copy of the EFI
> partition is created in the second hdd (i.e. sdb) which it may be, not
> sure, because the linux-swap partion is still left out.
> 
> Should I stripe both btrfs partitions together no matter the size?

That should work without issue.

> mkfs.btrfs -m raid0 -d raid0 /dev/sda3 /dev/sdb1
> 
> How will btrfs manage the difference in size?

Btrfs raid0 requires two devices, minimum, striping each chunk across the 
two.  Therefore, with two devices, to the extent that one device is 
larger, the larger (as partitioned) device will leave the difference in 
space unusable, as there's no second device to stripe with.

> Or should I partition out the extra size of /dev/sdb for trying to match
> equally sized partions? in other words:
> 
> /dev/sdb:
> 
> sdb1:  17 GiB approx. free or for whatever I want.
> sdb2:  (btrfs)
> 
> and then:
> 
> mkfs.btrfs -m raid0 -d raid0 /dev/sda3 /dev/sdb2

This should work as well.


But there's another option you didn't mention, that may be useful, 
depending on your exact need and usage of that swap:

Split your swap space in half, say (roughly, you can make one slightly 
larger than the other to allow for the EFI on one device) 8 GiB on each 
of the hdds.  Then, in your fstab or whatever you use to list the swap 
options, put the option priority=100 (or whatever number you find 
appropriate) on /both/ swap partitions.

With an equal priority on both swaps and with both active, the kernel 
will effectively raid0 your swap as well (until one runs out, of course), 
which, given that on spinning rust the device speed is the definite 
performance bottleneck for swap, should roughly double your swap 
performance. =:^)  Given that swap on spinning rust is slower than real 
RAM by several orders of magnitude, it'll still be far slower than real 
RAM, but twice as fast as it would be is better than otherwise, so...


Tho how much RAM /do/ you have, and are you sure you really need swap at 
all?  Many systems today have enough RAM that they don't really need swap 
(at least as swap, see below), unless they're going to be used for 
something extremely memory intensive, where the much lower speed of swap 
isn't a problem.

If you have 8 GiB of RAM or more, this may well be your situation.  With 
4 GiB, you probably have more than enough RAM for normal operation, but 
it may still be useful to have at least some swap, so Linux can keep more 
recently used files cached while swapping out some seldom used 
application RAM, but by 8 GiB you likely have enough RAM for reasonable 
cache AND all your apps and won't actually use swap much at all.

Tho if you frequently edit GiB+ video files and/or work with many virtual 
machines, 8 GiB RAM will likely be actually used, and 16 GiB may be the 
point at which you don't use swap much at all.  And of course if you are 
using LOTS of VMs or doing heavy 4K video editing, 16 GiB or more may 
well still be in heavy use, but with that kind of memory-intensive usage, 
32 GiB of RAM or more would likely be a good investment.

Anyway, for systems with enough memory to not need swap in /normal/ 
circumstances, in the event that something's actually leaking memory 
badly enough that swap is needed, there's a very good chance that you'll 
never outrun the leak with swap anyway, as if it's really leaking gigs of 
memory, it'll just eat up whatever gigs of swap you throw at it as well 
and /still/ run out of memory.

Meanwhile, swap to spinning rust really is /slow/.  You're talking 16 GiB 
of swap, and spinning rust speeds of 50 MiB/sec for swap isn't unusual.  
That's ~20 seconds worth of swap-thrashing waiting per GiB, ~320 seconds 
or over five minutes worth of swap thrashing to use the full 16 GiB.  OK, 
so you take that priority= idea and raid0 over two devices, it'll still 
be ~2:40 worth of waiting, to fully use that swap.  Is 16 GiB of swap 
/really/ both needed and worth that sort of wait if you do actually use 
it?

Tho 

Re: Again, no space left on device while rebalancing and recipe doesnt work

[Duncan]

Martin Steigerwald posted on Sun, 27 Mar 2016 14:10:07 +0200 as excerpted:

> On Freitag, 4. März 2016 12:31:44 CEST Duncan wrote:
>> Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted:
>> > 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
>> >> You're issue isn't the same, because all your space was allocated,
>> >> leaving only 1 MiB unallocated, which isn't normally enough to
>> >> allocate a new chunk to rewrite the data or metadata from the old
>> >> chunks into.
>> >> 
>> >> That's a known issue, with known workarounds as dealt with in the
>> >> FAQ.
>> > 
>> > Ah, thanks, well it was surprising for me that balance failed with
>> > out of space when both data and metadata had not all been used and I
>> > thought it could just use space from those...
>> > 
>> > especially as from FAQ:
>> >> If there is a lot of allocated but unused data or metadata chunks,
>> >> a balance may reclaim some of that allocated space. This is the main
>> >> reason for running a balance on a single-device filesystem.
>> > 
>> > so I think regular balance should be smart enough that it could solve
>> > this on own and wouldn't need to specify any options.
>> 
>> Well it does solve the problem on its own... to the extent that it
>> eliminates empty chunks (kernel 3.17+, it didn't before that).  But if
>> there's even a single 4 KiB file block used in the (nominal 1 GiB sized
>> data) chunk, it's no longer empty and thus not eliminated by the empty
>> chunk cleanup routines.
> 
> It could theoretically copy part of one almost empty chunk into another
> chunk to free it up, couldn´t it? This way it can free some chunks
> completely and then start the regular balance?

To be clear here, as unfortunately I wasn't in the previous reply, "it" 
in this case refers to the kernel's general btrfs handling -- IOW, the 
kernel, since 3.17, routinely deletes entirely empty chunks.

(Tho apparently there are cases when it misses some, as we've had a few 
reports lately of a balance with usage=0 cleaning up more than the 
trivial one or two chunks that could arguably have been "in transit" at 
the time the balance was run... but that would be a bug.)

For the kernel to routinely and automatically move content from one 
partially filled chunk to another in ordered to free the one is a *MUCH* 
higher level of complexity and thus a *MUCH* higher chance of serious 
show-stopping bugs; certainly nothing /I/'d wish to touch, were I a btrfs 
dev.  

It should be noted that btrfs is in general a COW (copy-on-write) 
filesystem, so simply moving content from one chunk into another isn't 
the way it works.  At the individual node level if not at the chunk 
level, the COW nature of btrfs means that modification of the existing 
data in both chunks would require copying the node elsewhere in ordered 
to rewrite it to include the new/modified information, and this must be 
handled atomically such that in the event of a crash, either the old 
version or the new version survives, not a mix of half of one and half of 
the other.  While btrfs is already designed from the ground up with that 
in mind, normal file and metadata updates would handle that within single 
chunks, and coordinating that atomicity across chunks really does add in 
geometric proportion to the complexity of the situation.

Which means there's much more wisdom than might be first appreciated in 
having balance simply stick to the chunk level COW that is its designed 
scope, instead of having it try to do cross-chunk node-level COW, which 
is what you're effectively proposing.  (Of course the complexity is in 
fact rather higher than I'm explaining here, but the fact remains, to the 
extent possible, keeping node level atomic operations to the node level, 
and chunk level atomic operations to the chunk level, **GREATLY** 
simplifies things, and deliberately crossing that level barrier where 
it's not absolutely required is an invitation to bugs so complex and 
severe that they could ultimately collapse the entire filesystem!)

> In either case, its unintuitive for the user to fail this. The
> filesystem tools should allow a balance in *any* case without needing
> special treatment by the user.

In fairness, there's a reason btrfs isn't claiming full stability and 
maturity just yet -- it's stabilizing, but exactly this sort of problems 
need to be worked out, before it can really be called fully stable.  
Meanwhile, as the (borrowed from Latin) saying goes "caveat emptor", "let 
the buyer beware."[1]  It remains the user's responsibility to ensure 
that btrfs is an appropriate filesystem for their use-case, and if so and 
once installed, that it remains within healthy operating parameters, 
enough unallocated space is kept available to complete balances, backups 
are kept in case some bug kills the filesystem, etc.

I think what ultimately needs to and probably will happen, is they'll 
create a new kind of global reserve that will come from unallocated space 

btrfs filesystem du - Failed to lookup root id - Inappropriate ioctl for device

[Peter Becker]

Hi i found the descriped error in if i execute du with btrfs-progs
v4.5 with kernel v4.5.

floyd@nas ~ $ sudo btrfs version
btrfs-progs v4.5

floyd@nas ~ $ uname -r
4.5.0-040500-generic

floyd@nas ~ $ sudo btrfs fi show
Label: 'RAID'  uuid: 3247737b-87f9-4e8c-8db3-2beed50fb104
Total devices 4 FS bytes used 3.71TiB
devid1 size 2.73TiB used 1.40TiB path /dev/sdf
devid2 size 2.73TiB used 1.40TiB path /dev/sdb
devid3 size 2.73TiB used 1.40TiB path /dev/sde
devid4 size 4.55TiB used 3.22TiB path /dev/sdd

Label: 'BACKUP'  uuid: 35e6ff5f-2612-4ef2-9cdb-07b3ccd0f517
Total devices 1 FS bytes used 27.29GiB
devid1 size 1.36TiB used 29.06GiB path /dev/sdc

floyd@nas ~ $ sudo btrfs subv list -o /media/RAID/
ID 258 gen 214551 top level 5 path apps
ID 259 gen 214722 top level 5 path downloads
ID 260 gen 214711 top level 5 path filme
ID 261 gen 214553 top level 5 path misc
ID 262 gen 214722 top level 5 path musik
ID 263 gen 214555 top level 5 path owncloud
ID 264 gen 214556 top level 5 path serien

-- now the error --

floyd@nas ~ $ sudo btrfs fi du /media/RAID/
 Total   Exclusive  Set shared  Filename
 500.00KiB   0.00B   -  /media/RAID//apps/Drive Snapshot
 167.96MiB   0.00B   -  /media/RAID//apps/vmware
 .. [46 rows] ..
ERROR: cannot check space of '/media/RAID/': Unknown error -1

floyd@nas ~ $ sudo btrfs fi du /media/RAID/apps
 Total   Exclusive  Set shared  Filename
 500.00KiB   0.00B   -  /media/RAID//apps/Drive Snapshot
 167.96MiB   0.00B   -  /media/RAID//apps/vmware
 .. [46 rows] ..
ERROR: cannot check space of '/media/RAID/': Unknown error -1

floyd@nas ~ $ sudo btrfs fi du /media/RAID/musik
ERROR: cannot check space of '/media/RAID/': Unknown error -1

but for subvolume "downloads" it finished without error

floyd@nas ~ $ sudo btrfs fi du /media/RAID/
 Total   Exclusive  Set shared  Filename
 500.00KiB   0.00B   -  /media/RAID//apps/Drive Snapshot
 167.96MiB   0.00B   -  /media/RAID//apps/vmware
 ..

-- more details --

floyd@nas ~ $ sudo btrfs inspect-internal rootid /media/RAID/
5

floyd@nas ~ $ sudo btrfs inspect-internal rootid /media/RAID/apps/
258

floyd@nas ~ $ sudo btrfs inspect-internal dump-super
/media/RAID/apps/Drive\ Snapshot/snapshot.exe
superblock: bytenr=65536, device=/media/RAID/apps/Drive Snapshot/snapshot.exe
-
ERROR: bad magic on superblock on /media/RAID/apps/Drive
Snapshot/snapshot.exe at 65536
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: csum errors in VirtualBox VDI files

[Chris Murphy]

On Sun, Mar 27, 2016 at 11:31 AM, Kai Krakow  wrote:
> Am Sat, 26 Mar 2016 22:57:53 -0600
> schrieb Chris Murphy :
>
>> On Sat, Mar 26, 2016 at 7:30 PM, Kai Krakow 
>> wrote:
>>
>> > Both filesystems on this PC show similar corruption now - but they
>> > are connected to completely different buses (SATA3 bcache + 3x SATA2
>> > backing store bache{0,1,2}, and USB3 without bcache = sde), use
>> > different compression (compress=lzo vs. compress-force=zlib), but
>> > similar redundancy scheme (draid=0,mraid=1 vs.
>> > draid=single,mraid=dup). A hardware problem would induce completely
>> > random errors on these pathes.
>> >
>> > Completely different hardware shows similar problems - but that
>> > system is currently not available to me, and will stay there for a
>> > while (it's a non-production installation at my workplace). Why
>> > would similar errors show up here, if it'd be a hardware error of
>> > the first system?
>>
>> Then there's something about the particular combination of mount
>> options you're using with the workload that's inducing this, if it's
>> reproducing on two different systems. What's the workload and what's
>> the full history of the mount options? Looks like it started life as
>> compress lzo and then later compress-force zlib and then after that
>> the addition of space_cache=v2?
>
> Still, that's two (or three) different filesystems:
>
> The first (my main system) had compress=lzo forever, I never used
> compress-force or something different than lzo.
>
> The second (my main system backup) had compress-force=zlib forever,
> never used a different compression option.
>
> The third (the currently offline system) had compress=lzo like the
> first one. It has no backup, system can be rebuild from scratch, no
> important data there. I don't bother about that currently.
>
>> Hopefully Qu has some advice on what's next. It might not be a bad
>> idea to get a btrfs-image going.
>
> I first upgraded to btrfs-progs 4.5 and removed the space_cache=v2
> option (space tree has been removed, ro-incompat flag was reset
> according to dmesg). I only activated that to see if it changes things,
> and I made sure beforehand that this can be removed. Looks like that
> works as documented.
>
> I'll come back to the other thread as soon as I've run the check. It
> takes a while (it contains a few weeks worth of snapshots). Meanwhile
> I'll see if the main fs looks any different with btrfs-progs 4.5. I
> need to get into dracut pre-mount for that.
>
> At least, with space_cache=v2 removed, the delayed_refs problem there
> is gone - so that code obviously has problems.
>
> The main system didn't use space_cache=v2, tho, when the "object
> already exists" problem hit me first.
>
> I'll prepare for btrfs-image. How big is that going to be? I'd prefer
> to make it as sparse as possible. I could hook it up to a 100mbit
> upload but I need to get storage for that first.

Before you go to the trouble of uploading btrfs-image, see if 'btrfs
check' with progs 4.5 clears up the noisy messages that Qu thinks are
false alarms.

As for the csum errors with this one single VDI file, you're going to
have to come up with a way to reproduce it consistently. You'll need
to have a good copy on a filesystem that comes up clean with btrfs
check and scrub. And then reproduce the corruption somehow. One hint
based on the other two users with similar setups or workload is they
aren't using the discard mount option and you are. I'd say unless you
have a newer SSD that supports queued trim, it probably shouldn't be
used, it's known to cause the kinds of hangs you report with drives
that only support non-queued trim. Those drives are better off getting
fstrim e.g. once a week on a timer.

And something that I find annoying is when you say in the first post
"results in a write error and the file system goes read-only" you're
asked by one of the developers to provide the kernel log, and then you
paste only some csum errors not kernel log. And not even the write
error. I think you need to collect more data, this whole thread is
like throwing spaghetti at a wall or throwing darts in a pitch black
room. You need to do more testing to find out what the pattern is,
when it happens and doesn't happen. The traces you're posting don't
help. And they're also incomplete. That's my two cents.


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: csum errors in VirtualBox VDI files

[Kai Krakow]

Am Sat, 26 Mar 2016 22:57:53 -0600
schrieb Chris Murphy :

> On Sat, Mar 26, 2016 at 7:30 PM, Kai Krakow 
> wrote:
> 
> > Both filesystems on this PC show similar corruption now - but they
> > are connected to completely different buses (SATA3 bcache + 3x SATA2
> > backing store bache{0,1,2}, and USB3 without bcache = sde), use
> > different compression (compress=lzo vs. compress-force=zlib), but
> > similar redundancy scheme (draid=0,mraid=1 vs.
> > draid=single,mraid=dup). A hardware problem would induce completely
> > random errors on these pathes.
> >
> > Completely different hardware shows similar problems - but that
> > system is currently not available to me, and will stay there for a
> > while (it's a non-production installation at my workplace). Why
> > would similar errors show up here, if it'd be a hardware error of
> > the first system?  
> 
> Then there's something about the particular combination of mount
> options you're using with the workload that's inducing this, if it's
> reproducing on two different systems. What's the workload and what's
> the full history of the mount options? Looks like it started life as
> compress lzo and then later compress-force zlib and then after that
> the addition of space_cache=v2?

Still, that's two (or three) different filesystems:

The first (my main system) had compress=lzo forever, I never used
compress-force or something different than lzo.

The second (my main system backup) had compress-force=zlib forever,
never used a different compression option.

The third (the currently offline system) had compress=lzo like the
first one. It has no backup, system can be rebuild from scratch, no
important data there. I don't bother about that currently.

> Hopefully Qu has some advice on what's next. It might not be a bad
> idea to get a btrfs-image going.

I first upgraded to btrfs-progs 4.5 and removed the space_cache=v2
option (space tree has been removed, ro-incompat flag was reset
according to dmesg). I only activated that to see if it changes things,
and I made sure beforehand that this can be removed. Looks like that
works as documented.

I'll come back to the other thread as soon as I've run the check. It
takes a while (it contains a few weeks worth of snapshots). Meanwhile
I'll see if the main fs looks any different with btrfs-progs 4.5. I
need to get into dracut pre-mount for that.

At least, with space_cache=v2 removed, the delayed_refs problem there
is gone - so that code obviously has problems.

The main system didn't use space_cache=v2, tho, when the "object
already exists" problem hit me first.

I'll prepare for btrfs-image. How big is that going to be? I'd prefer
to make it as sparse as possible. I could hook it up to a 100mbit
upload but I need to get storage for that first.

-- 
Regards,
Kai

Replies to list-only preferred.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible Raid Bug

[Stephen Williams]

Yeah I think the Gotchas page would be a good place to give people a
heads up.

-- 
  Stephen Williams
  steph...@veryfast.biz

On Sat, Mar 26, 2016, at 09:58 PM, Chris Murphy wrote:
> On Sat, Mar 26, 2016 at 8:00 AM, Stephen Williams 
> wrote:
> 
> > I know this is quite a rare occurrence for home use but for Data center
> > use this is something that will happen A LOT.
> > This really should be placed in the wiki while we wait for a fix. I can
> > see a lot of sys admins crying over this.
> 
> Maybe on the gotchas page? While it's not a data loss bug, it might be
> viewed as an uptime bug because the dataset is stuck being ro and
> hence unmodifiable, until a restore to a rw volume is complete.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: csum errors in VirtualBox VDI files

[Kai Krakow]

Am Sun, 27 Mar 2016 14:18:26 +0200
schrieb Martin Steigerwald :

> On Dienstag, 22. März 2016 09:03:42 CEST Kai Krakow wrote:
> > Hello!
> > 
> > Since one of the last kernel updates (I don't know which exactly),
> > I'm experiencing csum errors within VDI files when running
> > VirtualBox. A side effect of this is, as soon as dmesg shows these
> > errors, commands like "du" and "df" hang until reboot.
> > 
> > I've now restored the file from backup but it happens over and over
> > again.  
> 
> Just as another data point I am irregularily using a VM with
> Virtualbox in a VDI file on a BTRFS RAID 1 on two SSDs and had no
> such issues so far up to kernel 4.5.

Meanwhile I think this is a side effect of some other corruption in the
filesystem.

-- 
Regards,
Kai

Replies to list-only preferred.


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RAID Assembly with Missing Empty Drive

[Henk Slager]

On Sun, Mar 27, 2016 at 4:59 PM, John Marrett  wrote:
>>> If you do want to use a newer one, I'd build against kernel.org, just
>>> because the developers only use that base. And use 4.4.6 or 4.5.
>>
>> At this point I could remove the overlays and recover the filesystem
>> permanently, however I'm also deeply indebted to the btrfs community
>> and want to give anything I can back. I've built (but not installed ;)
>> ) a straight kernel.org 4.5 w/my missing device check patch applied.
>> Is there any interest or value in attempting to switch to this kernel,
>> add/delete a device and see if I experience the same errors as before
>> I tried replace? What information should I gather if I do this?
>
> I've built and installed a 4.5 straight from kernel.org with my patch.
>
> I encountered the same errors in recovery when I use add/delete
> instead of using replace, here's the sequence of commands:
>
> ubuntu@btrfs-recovery:~$ sudo mount -o degraded,ro /dev/sda /mnt
> ubuntu@btrfs-recovery:~$ sudo mount -o remount,rw /mnt
> # Remove first empty device
> ubuntu@btrfs-recovery:~$ sudo btrfs device delete missing /mnt
> # Add blank drive
> ubuntu@btrfs-recovery:~$ sudo btrfs device add /dev/sde /mnt
> # Remove second missing device with data
> ubuntu@btrfs-recovery:~$ sudo btrfs device delete missing /mnt
>
> And the resulting error:
>
> ubuntu@btrfs-recovery:~$ sudo btrfs device delete missing /mnt
> ERROR: error removing the device 'missing' - Input/output error
>
> Here's what we see in dmesg after deleting the missing device:
>
> [  588.231341] BTRFS info (device sdd): relocating block group
> 10560347308032 flags 17
> [  664.306122] BTRFS warning (device sdd): csum failed ino 257 off
> 695730176 csum 2566472073 expected csum 2706136415
> [  664.306164] BTRFS warning (device sdd): csum failed ino 257 off
> 695734272 csum 2566472073 expected csum 2558511802
> [  664.306182] BTRFS warning (device sdd): csum failed ino 257 off
> 695746560 csum 2566472073 expected csum 3360772439
> [  664.306191] BTRFS warning (device sdd): csum failed ino 257 off
> 695750656 csum 2566472073 expected csum 1205516886
> [  664.344179] BTRFS warning (device sdd): csum failed ino 257 off
> 695730176 csum 2566472073 expected csum 2706136415
> [  664.344213] BTRFS warning (device sdd): csum failed ino 257 off
> 695734272 csum 2566472073 expected csum 2558511802
> [  664.344224] BTRFS warning (device sdd): csum failed ino 257 off
> 695746560 csum 2566472073 expected csum 3360772439
> [  664.344233] BTRFS warning (device sdd): csum failed ino 257 off
> 695750656 csum 2566472073 expected csum 1205516886
> [  664.344684] BTRFS warning (device sdd): csum failed ino 257 off
> 695730176 csum 2566472073 expected csum 2706136415
> [  664.344693] BTRFS warning (device sdd): csum failed ino 257 off
> 695734272 csum 2566472073 expected csum 2558511802
>
> Is there anything of value I can do here to help address this possible
> issue in btrfs itself, or should I remove the overlays, replace the
> device and move on?
>
> Please let me know,

I think it is great that with your local patch you managed to get into
a writable situation.
In theory, with for example already a new spare disk already attached
and standby (hot spare patchset and more etc), a direct replace of the
failing disk, so internally or manually with btrfs-replace would have
prevented the few csum and other small errors. It could be that the
errors have another cause than due to the complete failing harddisk
initially, but that won't be easy to trackdown black and white. Also
the ddrescue action and local patch make tracking back difficult and
it was also based on outdated kernel+tools.

I think it is best that you just repeat the fixing again on the real
disks and just make sure you have an uptodate/latest kernel+tools when
fixing the few damaged files.
With   btrfs inspect-internal inode-resolve 257 
you can see what file(s) are damaged.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RAID Assembly with Missing Empty Drive

[John Marrett]

>> If you do want to use a newer one, I'd build against kernel.org, just
>> because the developers only use that base. And use 4.4.6 or 4.5.
>
> At this point I could remove the overlays and recover the filesystem
> permanently, however I'm also deeply indebted to the btrfs community
> and want to give anything I can back. I've built (but not installed ;)
> ) a straight kernel.org 4.5 w/my missing device check patch applied.
> Is there any interest or value in attempting to switch to this kernel,
> add/delete a device and see if I experience the same errors as before
> I tried replace? What information should I gather if I do this?

I've built and installed a 4.5 straight from kernel.org with my patch.

I encountered the same errors in recovery when I use add/delete
instead of using replace, here's the sequence of commands:

ubuntu@btrfs-recovery:~$ sudo mount -o degraded,ro /dev/sda /mnt
ubuntu@btrfs-recovery:~$ sudo mount -o remount,rw /mnt
# Remove first empty device
ubuntu@btrfs-recovery:~$ sudo btrfs device delete missing /mnt
# Add blank drive
ubuntu@btrfs-recovery:~$ sudo btrfs device add /dev/sde /mnt
# Remove second missing device with data
ubuntu@btrfs-recovery:~$ sudo btrfs device delete missing /mnt

And the resulting error:

ubuntu@btrfs-recovery:~$ sudo btrfs device delete missing /mnt
ERROR: error removing the device 'missing' - Input/output error

Here's what we see in dmesg after deleting the missing device:

[  588.231341] BTRFS info (device sdd): relocating block group
10560347308032 flags 17
[  664.306122] BTRFS warning (device sdd): csum failed ino 257 off
695730176 csum 2566472073 expected csum 2706136415
[  664.306164] BTRFS warning (device sdd): csum failed ino 257 off
695734272 csum 2566472073 expected csum 2558511802
[  664.306182] BTRFS warning (device sdd): csum failed ino 257 off
695746560 csum 2566472073 expected csum 3360772439
[  664.306191] BTRFS warning (device sdd): csum failed ino 257 off
695750656 csum 2566472073 expected csum 1205516886
[  664.344179] BTRFS warning (device sdd): csum failed ino 257 off
695730176 csum 2566472073 expected csum 2706136415
[  664.344213] BTRFS warning (device sdd): csum failed ino 257 off
695734272 csum 2566472073 expected csum 2558511802
[  664.344224] BTRFS warning (device sdd): csum failed ino 257 off
695746560 csum 2566472073 expected csum 3360772439
[  664.344233] BTRFS warning (device sdd): csum failed ino 257 off
695750656 csum 2566472073 expected csum 1205516886
[  664.344684] BTRFS warning (device sdd): csum failed ino 257 off
695730176 csum 2566472073 expected csum 2706136415
[  664.344693] BTRFS warning (device sdd): csum failed ino 257 off
695734272 csum 2566472073 expected csum 2558511802

Is there anything of value I can do here to help address this possible
issue in btrfs itself, or should I remove the overlays, replace the
device and move on?

Please let me know,

-JohnF
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scrub: Tree block spanning stripes, ignored

[Qu Wenruo]

On 03/27/2016 05:54 PM, Ivan P wrote:

Read the info on the wiki, here's the rest of the requested information:

# uname -r
4.4.5-1-ARCH

# btrfs fi show
Label: 'ArchVault'  uuid: cd8a92b6-c5b5-4b19-b5e6-a839828d12d8
Total devices 1 FS bytes used 2.10GiB
devid1 size 14.92GiB used 4.02GiB path /dev/sdc1

Label: 'Vault'  uuid: 013cda95-8aab-4cb2-acdd-2f0f78036e02
Total devices 2 FS bytes used 800.72GiB
devid1 size 931.51GiB used 808.01GiB path /dev/sda
devid2 size 931.51GiB used 808.01GiB path /dev/sdb

# btrfs fi df /mnt/vault/
Data, RAID1: total=806.00GiB, used=799.81GiB
System, RAID1: total=8.00MiB, used=128.00KiB
Metadata, RAID1: total=2.00GiB, used=936.20MiB
GlobalReserve, single: total=320.00MiB, used=0.00B

On Fri, Mar 25, 2016 at 3:16 PM, Ivan P  wrote:

Hello,

using kernel  4.4.5 and btrfs-progs 4.4.1, I today ran a scrub on my
2x1Tb btrfs raid1 array and it finished with 36 unrecoverable errors
[1], all blaming the treeblock 741942071296. Running "btrfs check
--readonly" on one of the devices lists that extent as corrupted [2].

How can I recover, how much did I really lose, and how can I prevent
it from happening again?
If you need me to provide more info, do tell.

[1] http://cwillu.com:8080/188.110.141.36/1


This message itself is normal, it just means a tree block is crossing 
64K stripe boundary.

And due to scrub limit, it can check if it's good or bad.
But


[2] http://pastebin.com/xA5zezqw

This one is much more meaningful, showing several strange bugs.

1. corrupt extent record: key 741942071296 168 1114112
This means, this is a EXTENT_ITEM(168), and according to the offset, it 
means the length of the extent is, 1088K, definitely not a valid tree 
block size.


But according to [1], kernel think it's a tree block, which is quite 
strange.

Normally, such mismatch only happens in fs converted from ext*.

2. Backref 741942071296 root 5 owner 71723 offset 2589392896 num_refs 0 
not found in extent tree


num_refs 0, this is also strange, normal backref won't have a zero 
refrence number.


3. bad metadata [741942071296, 741943185408) crossing stripe boundary
It could be a false warning fixed in latest btrfsck.
But you're using 4.4.1, so I think that's the problem.

4. bad extent [741942071296, 741943185408), type mismatch with chunk
This seems to explain the problem, a data extent appears in a metadata 
chunk.

It seems that you're really using converted btrfs.

If so, just roll it back to ext*. Current btrfs-convert has known bug 
but fix is still under review.


If want to use btrfs, use a newly created one instead of btrfs-convert.

Thanks,
Qu



Regards,
Soukyuu

P.S.: please add me to CC when replying as I did not subscribe to the
mailing list. Majordomo won't let me use my hotmail address and I
don't want that much traffic on this address.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: csum errors in VirtualBox VDI files

[Qu Wenruo]

On 03/27/2016 09:50 AM, Kai Krakow wrote:

Am Sat, 26 Mar 2016 20:30:35 +0100
schrieb Kai Krakow :


Am Wed, 23 Mar 2016 12:16:24 +0800
schrieb Qu Wenruo :


Kai Krakow wrote on 2016/03/22 19:48 +0100:

Am Tue, 22 Mar 2016 16:47:10 +0800
schrieb Qu Wenruo :


  [...]

  [...]

  [...]


Apparently, that system does not boot now due to errors in bcache
b-tree. That being that, it may well be some bcache error and not
btrfs' fault. Apparently I couldn't catch the output, I've been
in a hurry. It said "write error" and had some backtrace. I will
come to this back later.

Let's go to the system I currently care about (that one with the
always breaking VDI file):


  [...]

  [...]


After the error occured?

Yes, some text about the extent being compressed and btrfs repair
doesn't currently handle that case (I tried --repair as I'm
having a backup). I simply decided not to investigate that
further at that point but delete and restore the affected file
from backup. However, this is the message from dmesg (tho, I
didn't catch the backtrace):

btrfs_run_delayed_refs:2927: errno=-17 Object already exists


That's nice, at least we have some clue.

It's almost sure, it's a bug either in btrfs kernel which doesn't
handle delayed refs well(low possibility), or, corrupted fs which
create something kernel can't handle(I bet that's the case).


[kernel 4.5.0 gentoo, btrfs-progs 4.4.1]

Well, this time it hit me on the USB backup drive which uses no bcache
and no other fancy options except compress-force=zlib. Apparently,
I've only got a (real) screenshot which I'm going to link here:

https://www.dropbox.com/s/9qbc7np23y8lrii/IMG_20160326_200033.jpg?dl=0

The same drive has no problems except "bad metadata crossing stripe
boundary" - but a lot of them. This drive was never converted, it was
freshly generated several months ago.
[...]


I finally got copy data:

# before mounting let's check the FS:

$ sudo btrfsck /dev/disk/by-label/usb-backup
Checking filesystem on /dev/disk/by-label/usb-backup
UUID: 1318ec21-c421-4e36-a44a-7be3d41f9c3f
checking extents
bad metadata [156041216, 156057600) crossing stripe boundary
bad metadata [181403648, 181420032) crossing stripe boundary
bad metadata [392167424, 392183808) crossing stripe boundary
bad metadata [783482880, 783499264) crossing stripe boundary
bad metadata [784924672, 784941056) crossing stripe boundary
bad metadata [130151612416, 130151628800) crossing stripe boundary
bad metadata [162826813440, 162826829824) crossing stripe boundary
bad metadata [162927083520, 162927099904) crossing stripe boundary
bad metadata [619740659712, 619740676096) crossing stripe boundary
bad metadata [619781947392, 619781963776) crossing stripe boundary
bad metadata [619795644416, 619795660800) crossing stripe boundary
bad metadata [619816091648, 619816108032) crossing stripe boundary
bad metadata [620011388928, 620011405312) crossing stripe boundary
bad metadata [890992459776, 890992476160) crossing stripe boundary
bad metadata [891022737408, 891022753792) crossing stripe boundary
bad metadata [891101773824, 891101790208) crossing stripe boundary
bad metadata [891301199872, 891301216256) crossing stripe boundary
bad metadata [1012219314176, 1012219330560) crossing stripe boundary
bad metadata [1017202409472, 1017202425856) crossing stripe boundary
bad metadata [1017365397504, 1017365413888) crossing stripe boundary
bad metadata [1020764422144, 1020764438528) crossing stripe boundary
bad metadata [1251103342592, 1251103358976) crossing stripe boundary
bad metadata [1251144695808, 1251144712192) crossing stripe boundary
bad metadata [1251147055104, 1251147071488) crossing stripe boundary
bad metadata [1259271225344, 1259271241728) crossing stripe boundary
bad metadata [1266223611904, 1266223628288) crossing stripe boundary
bad metadata [1304750063616, 130475008) crossing stripe boundary
bad metadata [1304790106112, 1304790122496) crossing stripe boundary
bad metadata [1304850792448, 1304850808832) crossing stripe boundary
bad metadata [1304869928960, 1304869945344) crossing stripe boundary
bad metadata [1305089540096, 1305089556480) crossing stripe boundary
bad metadata [1309561651200, 1309561667584) crossing stripe boundary
bad metadata [1309581443072, 1309581459456) crossing stripe boundary
bad metadata [1309583671296, 1309583687680) crossing stripe boundary
bad metadata [1309942808576, 1309942824960) crossing stripe boundary
bad metadata [1310050549760, 1310050566144) crossing stripe boundary
bad metadata [1313031585792, 1313031602176) crossing stripe boundary
bad metadata [1313232912384, 1313232928768) crossing stripe boundary
bad metadata [1555210764288, 1555210780672) crossing stripe boundary
bad metadata [1555395182592, 1555395198976) crossing stripe boundary
bad metadata [205057678, 2050576760832) crossing stripe boundary
bad metadata [2050803957760, 2050803974144) crossing stripe boundary
bad metadata 

Re: csum errors in VirtualBox VDI files

[Qu Wenruo]

On 03/27/2016 03:30 AM, Kai Krakow wrote:

Am Wed, 23 Mar 2016 12:16:24 +0800
schrieb Qu Wenruo :


Kai Krakow wrote on 2016/03/22 19:48 +0100:

Am Tue, 22 Mar 2016 16:47:10 +0800
schrieb Qu Wenruo :


Hi,

Kai Krakow wrote on 2016/03/22 09:03 +0100:

  [...]


When it goes RO, it must have some warning in kernel log.
Would you please paste the kernel log?


Apparently, that system does not boot now due to errors in bcache
b-tree. That being that, it may well be some bcache error and not
btrfs' fault. Apparently I couldn't catch the output, I've been in a
hurry. It said "write error" and had some backtrace. I will come to
this back later.

Let's go to the system I currently care about (that one with the
always breaking VDI file):


  [...]

Does btrfs check report anything wrong?


After the error occured?

Yes, some text about the extent being compressed and btrfs repair
doesn't currently handle that case (I tried --repair as I'm having a
backup). I simply decided not to investigate that further at that
point but delete and restore the affected file from backup.
However, this is the message from dmesg (tho, I didn't catch the
backtrace):

btrfs_run_delayed_refs:2927: errno=-17 Object already exists


That's nice, at least we have some clue.

It's almost sure, it's a bug either in btrfs kernel which doesn't
handle delayed refs well(low possibility), or, corrupted fs which
create something kernel can't handle(I bet that's the case).


[kernel 4.5.0 gentoo, btrfs-progs 4.4.1]

Well, this time it hit me on the USB backup drive which uses no bcache
and no other fancy options except compress-force=zlib. Apparently, I've
only got a (real) screenshot which I'm going to link here:

https://www.dropbox.com/s/9qbc7np23y8lrii/IMG_20160326_200033.jpg?dl=0


Nothing new.
The needed thing is not the warning/error part, but the info part.

Which will output the extent tree leaf with what run_delayed_refs is 
going to do.




The same drive has no problems except "bad metadata crossing stripe
boundary" - but a lot of them. This drive was never converted, it was
freshly generated several months ago.

---8<---
$ sudo btrfsck /dev/disk/by-label/usb-backup
Checking filesystem on /dev/disk/by-label/usb-backup
UUID: 1318ec21-c421-4e36-a44a-7be3d41f9c3f
checking extents
bad metadata [156041216, 156057600) crossing stripe boundary
bad metadata [181403648, 181420032) crossing stripe boundary
bad metadata [392167424, 392183808) crossing stripe boundary
bad metadata [783482880, 783499264) crossing stripe boundary
bad metadata [784924672, 784941056) crossing stripe boundary
bad metadata [130151612416, 130151628800) crossing stripe boundary
bad metadata [162826813440, 162826829824) crossing stripe boundary
bad metadata [162927083520, 162927099904) crossing stripe boundary
bad metadata [619740659712, 619740676096) crossing stripe boundary
bad metadata [619781947392, 619781963776) crossing stripe boundary
bad metadata [619795644416, 619795660800) crossing stripe boundary
bad metadata [619816091648, 619816108032) crossing stripe boundary
bad metadata [620011388928, 620011405312) crossing stripe boundary
bad metadata [890992459776, 890992476160) crossing stripe boundary
bad metadata [891022737408, 891022753792) crossing stripe boundary
bad metadata [891101773824, 891101790208) crossing stripe boundary
bad metadata [891301199872, 891301216256) crossing stripe boundary
[...]
--->8---


Normally false alert, just old btrfs-progs.
Or your fs is converted from ext*.

Update to latest btrfs-progs to see what it output now.


My main drive (which this thread was about) has a huge amount of
different problems according to btrfsck. Repair doesn't work:


Don't use --repair until you know the meaning of the error.

I just found your full fsck output, and will comment there.

Thanks,
Qu


it says
something about overlapping extents and that it needs a careful
thought. I wanted to catch the output when the above problem occured. So
I'd like to defer that until later and first fix my backup drive. If I
lose my main drive, I simply restore from backup. It is very old anyway
(still using 4k node size). Only downside it takes 24+ hours to restore.


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: csum errors in VirtualBox VDI files

[Martin Steigerwald]

On Dienstag, 22. März 2016 09:03:42 CEST Kai Krakow wrote:
> Hello!
> 
> Since one of the last kernel updates (I don't know which exactly), I'm
> experiencing csum errors within VDI files when running VirtualBox. A
> side effect of this is, as soon as dmesg shows these errors, commands
> like "du" and "df" hang until reboot.
> 
> I've now restored the file from backup but it happens over and over
> again.

Just as another data point I am irregularily using a VM with Virtualbox in a 
VDI file on a BTRFS RAID 1 on two SSDs and had no such issues so far up to 
kernel 4.5.

Thanks,
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

[Martin Steigerwald]

On Dienstag, 15. März 2016 08:07:22 CEST Marc Haber wrote:
> On Mon, Mar 14, 2016 at 09:39:51PM +0100, Henk Slager wrote:
> > >> BTW, I restored and mounted your 20160307-fanbtr-image:
> > >> 
> > >> [266169.207952] BTRFS: device label fanbtr devid 1 transid 22215732
> > >> /dev/loop0 [266203.734804] BTRFS info (device loop0): disk space
> > >> caching is enabled [266203.734806] BTRFS: has skinny extents
> > >> [266204.022175] BTRFS: checking UUID tree
> > >> [266239.407249] attempt to access beyond end of device
> > >> [266239.407252] loop0: rw=1073, want=715202688, limit=70576
> > >> [266239.407254] BTRFS error (device loop0): bdev /dev/loop0 errs: wr
> > >> 1, rd 0, flush 0, corrupt 0, gen 0
> > >> [266239.407272] attempt to access beyond end of device
> > >> .. and 16 more
> > >> 
> > >> As a quick fix/workaround, I truncated the image to 1T
> > > 
> > > The original fs was 417 GiB in size. What size does the image claim?
> > 
> > ls -alFh  of the restored image showed 337G I remember.
> > btrfs fi us showed also a number over 400G, I don't have the
> > files/loopdev anymore.
> 
> sounds legit.
> 
> > It could some side effect of btrfs-image, I only have used it for
> > multi-device, where dev id's are ignore, but total image size did not
> > lead to problems.
> 
> The original "ofanbtr" seems to have a problem, since btrfs check
> 
> /media/tempdisk says:
> > > [10/509]mh@fan:~$ sudo btrfs check /media/tempdisk/
> > > Superblock bytenr is larger than device size
> > > Couldn't open file system
> > > [11/509]mh@fan:~$
> > > 
> > > Can this be fixed?
> > 
> > What I would do in order to fix it, is resize the fs to let's say
> > 190GiB. That should write correct values to the superblocks I /hope/.
> > And then resize back to max.
> 
> It doesn't:
> [20/518]mh@fan:~$ sudo btrfs filesystem resize 300G /media/tempdisk/
> Resize '/media/tempdisk/' of '300G'
> [22/520]mh@fan:~$ sudo btrfs check /media/tempdisk/
> Superblock bytenr is larger than device size
> Couldn't open file system
> [23/521]mh@fan:~$ df -h

Are you trying the check on the *mounted* filesystem? "media/tempdisk" appears 
to be a mount point, not a device file.

Unmount it and use the / one device file of the filesystem to check.

Thanks,
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RAID Assembly with Missing Empty Drive

[John Marrett]

>> I was looking under btrfs device, sorry about that. I do have the
>> command. I tried replace and it seemed more promising than the last
>> attempt, it wrote enough data to the new drive to overflow and break
>> my overlay. I'm trying it without the overlay on the destination
>> device, I'll report back later with the results.

It looks like replace worked!

I got the following final output:

ubuntu@btrfs-recovery:~$ sudo btrfs replace status /mnt
Started on 26.Mar 20:59:12, finished on 27.Mar 05:20:01, 0 write errs,
0 uncorr. read errs

The filesystem appears in good health, no more missing devices:

ubuntu@btrfs-recovery:~$ sudo btrfs filesystem show
Label: none  uuid: 67b4821f-16e0-436d-b521-e4ab2c7d3ab7
Total devices 6 FS bytes used 5.47TiB
devid1 size 1.81TiB used 1.71TiB path /dev/sdb
devid2 size 1.81TiB used 1.71TiB path /dev/sde
devid3 size 1.82TiB used 1.72TiB path /dev/sdd
devid4 size 1.82TiB used 1.72TiB path /dev/sdc
devid5 size 2.73TiB used 2.62TiB path /dev/sda
devid6 size 2.73TiB used 2.62TiB path /dev/sdf

btrfs-progs v4.0

However the dmesg output shows some errors despite the 0 uncorr. read
errs reported above:

[112178.006315] BTRFS: checksum error at logical 8576298061824 on dev /dev/sda,
sector 4333289864, root 259, inode 10017264, offset 3216, length 4096, links
 1 (path: mythtv/store/4663_20150809180500.mpg)
[112178.006327] btrfs_dev_stat_print_on_error: 5 callbacks suppressed
[112178.006330] BTRFS: bdev /dev/sda errs: wr 0, rd 5002, flush 0, corrupt 16, g
en 0

And the underlying file does appear to be damaged:

ubuntu@btrfs-recovery:/mnt/@home/mythtv$ dd
if=store/4663_20150809180500.mpg of=/dev/null
dd: error reading ‘store/4663_20150809180500.mpg’: Input/output error
63368+0 records in
63368+0 records out
3216 bytes (32 MB) copied, 1.08476 s, 29.9 MB/s

Here's some dmesg output when accessing a damaged file:

[140789.642357] BTRFS warning (device sdc): csum failed ino 10017264
off 32854016 csum 2566472073 expected csum 1193787476
[140789.642503] BTRFS warning (device sdc): csum failed ino 10017264
off 32919552 csum 2566472073 expected csum 2825707817
[140789.645768] BTRFS warning (device sdc): csum failed ino 10017264
off 32509952 csum 2566472073 expected csum 834024150

I can also see that one device has had a few errors; this is the
device that was ddrescued and recorded some errors before being
ddrescued:

[/dev/sda].write_io_errs   0
[/dev/sda].read_io_errs5002
[/dev/sda].flush_io_errs   0
[/dev/sda].corruption_errs 153
[/dev/sda].generation_errs 0

> If you do want to use a newer one, I'd build against kernel.org, just
> because the developers only use that base. And use 4.4.6 or 4.5.

At this point I could remove the overlays and recover the filesystem
permanently, however I'm also deeply indebted to the btrfs community
and want to give anything I can back. I've built (but not installed ;)
) a straight kernel.org 4.5 w/my missing device check patch applied.
Is there any interest or value in attempting to switch to this kernel,
add/delete a device and see if I experience the same errors as before
I tried replace? What information should I gather if I do this?

-JohnF
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Raid 0 setup doubt.

[Jose Otero]

Hello,

--
I apologize beforehand if I'm asking a too basic question for the
mailing list, or if it has been already answered at nauseam.
--

I have two hdd (Western Digital 750 GB approx. 700 GiB each), and I
planning to set up a RAID 0 through btrfs. UEFI firmware/boot, no dual
boot, only linux.

My question is, given the UEFI partition plus linux swap partition, I
won't have two equal sized partitions for setting up the RAID 0 array.
So, I'm not quite sure how to do it. I'll have:

/dev/sda:

   16 KiB (GPT partition table)
sda1:  512 MiB (EFI, fat32)
sda2:  16 GiB (linux-swap)
sda3:  rest of the disk /  (btrfs)

/dev/sdb:

sdb1:  (btrfs)

The btrfs partitions on each hdd are not of the same size (admittedly by
an small difference, but still). Even if a backup copy of the EFI
partition is created in the second hdd (i.e. sdb) which it may be, not
sure, because the linux-swap partion is still left out.

Should I stripe both btrfs partitions together no matter the size?

mkfs.btrfs -m raid0 -d raid0 /dev/sda3 /dev/sdb1

How will btrfs manage the difference in size?

Or should I partition out the extra size of /dev/sdb for trying to match
equally sized partions? in other words:

/dev/sdb:

sdb1:  17 GiB approx. free or for whatever I want.
sdb2:  (btrfs)

and then:

mkfs.btrfs -m raid0 -d raid0 /dev/sda3 /dev/sdb2

Again, I'm sorry if it's an idiotic question, but I don't have it quite
clear and I would like to do it properly. So, any hint from more
knowable users would be MUCH appreciate it.

Thanks in advance.

JM.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scrub: Tree block spanning stripes, ignored

[Ivan P]

..forgot to paste btrfs-version: 4.4.1
(slightly outdated, but it's the current version on arch linux)

On Sun, Mar 27, 2016 at 11:54 AM, Ivan P  wrote:
> Read the info on the wiki, here's the rest of the requested information:
>
> # uname -r
> 4.4.5-1-ARCH
>
> # btrfs fi show
> Label: 'ArchVault'  uuid: cd8a92b6-c5b5-4b19-b5e6-a839828d12d8
>Total devices 1 FS bytes used 2.10GiB
>devid1 size 14.92GiB used 4.02GiB path /dev/sdc1
>
> Label: 'Vault'  uuid: 013cda95-8aab-4cb2-acdd-2f0f78036e02
>Total devices 2 FS bytes used 800.72GiB
>devid1 size 931.51GiB used 808.01GiB path /dev/sda
>devid2 size 931.51GiB used 808.01GiB path /dev/sdb
>
> # btrfs fi df /mnt/vault/
> Data, RAID1: total=806.00GiB, used=799.81GiB
> System, RAID1: total=8.00MiB, used=128.00KiB
> Metadata, RAID1: total=2.00GiB, used=936.20MiB
> GlobalReserve, single: total=320.00MiB, used=0.00B
>
> On Fri, Mar 25, 2016 at 3:16 PM, Ivan P  wrote:
>> Hello,
>>
>> using kernel  4.4.5 and btrfs-progs 4.4.1, I today ran a scrub on my
>> 2x1Tb btrfs raid1 array and it finished with 36 unrecoverable errors
>> [1], all blaming the treeblock 741942071296. Running "btrfs check
>> --readonly" on one of the devices lists that extent as corrupted [2].
>>
>> How can I recover, how much did I really lose, and how can I prevent
>> it from happening again?
>> If you need me to provide more info, do tell.
>>
>> [1] http://cwillu.com:8080/188.110.141.36/1
>> [2] http://pastebin.com/xA5zezqw
>>
>> Regards,
>> Soukyuu
>>
>> P.S.: please add me to CC when replying as I did not subscribe to the
>> mailing list. Majordomo won't let me use my hotmail address and I
>> don't want that much traffic on this address.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scrub: Tree block spanning stripes, ignored

[Ivan P]

Read the info on the wiki, here's the rest of the requested information:

# uname -r
4.4.5-1-ARCH

# btrfs fi show
Label: 'ArchVault'  uuid: cd8a92b6-c5b5-4b19-b5e6-a839828d12d8
   Total devices 1 FS bytes used 2.10GiB
   devid1 size 14.92GiB used 4.02GiB path /dev/sdc1

Label: 'Vault'  uuid: 013cda95-8aab-4cb2-acdd-2f0f78036e02
   Total devices 2 FS bytes used 800.72GiB
   devid1 size 931.51GiB used 808.01GiB path /dev/sda
   devid2 size 931.51GiB used 808.01GiB path /dev/sdb

# btrfs fi df /mnt/vault/
Data, RAID1: total=806.00GiB, used=799.81GiB
System, RAID1: total=8.00MiB, used=128.00KiB
Metadata, RAID1: total=2.00GiB, used=936.20MiB
GlobalReserve, single: total=320.00MiB, used=0.00B

On Fri, Mar 25, 2016 at 3:16 PM, Ivan P  wrote:
> Hello,
>
> using kernel  4.4.5 and btrfs-progs 4.4.1, I today ran a scrub on my
> 2x1Tb btrfs raid1 array and it finished with 36 unrecoverable errors
> [1], all blaming the treeblock 741942071296. Running "btrfs check
> --readonly" on one of the devices lists that extent as corrupted [2].
>
> How can I recover, how much did I really lose, and how can I prevent
> it from happening again?
> If you need me to provide more info, do tell.
>
> [1] http://cwillu.com:8080/188.110.141.36/1
> [2] http://pastebin.com/xA5zezqw
>
> Regards,
> Soukyuu
>
> P.S.: please add me to CC when replying as I did not subscribe to the
> mailing list. Majordomo won't let me use my hotmail address and I
> don't want that much traffic on this address.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html