* Size of scrubbed Data
@ 2016-09-15 15:48 Stefan Malte Schumacher
2016-09-15 20:11 ` g6094199
2016-09-15 21:18 ` Chris Murphy
0 siblings, 2 replies; 10+ messages in thread
From: Stefan Malte Schumacher @ 2016-09-15 15:48 UTC (permalink / raw)
To: linux-btrfs
Hello
I have encountered a very strange phenomenon while using btrfs-scrub.
I believe it may be a result of replacing my old installation of
Debian Jessie with Debian Stretch, resulting in a Kernel Switch from
3.16+63 to 4.6.0-1. I scrub my filesystem once a month and let anacron
send me the results. My filesystem, consisting of four four-gigabyte
drives with both data and metadata as RAID1 was reported as containing
nearly 12TiB of data in scrubs done in May, June, July and August. But
then it changed and suddenly shows only 9TiB in size, despite the fact
that I did not delete any large files. If I remember correctly my
switch from Debian Jessie to Stretch was around that time period.
Could someone explain this behavior to me? Was a new way of
calculating the size of scrubed data introduced? How can I check if I
have lost data? I have a backup, but only one generation and rsync
will by now have deleted files on the NAS, which might have lost on
the fileserver. According to the long and short self-tests, which I
run with smartmontools my drives are alright. How do I proceed?
Yours
Stefan
uname -a
Linux mars 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64 GNU/Linux
btrfs --version
btrfs-progs v4.7.1
btrfs fi show
Label: none uuid: 8c668854-db5d-45a7-875d-43c4e82a829e
Total devices 4 FS bytes used 6.06TiB
devid 1 size 3.64TiB used 3.09TiB path /dev/sde
devid 2 size 3.64TiB used 3.09TiB path /dev/sdc
devid 3 size 3.64TiB used 3.09TiB path /dev/sdd
devid 4 size 3.64TiB used 3.09TiB path /dev/sda
btrfs fi df /mnt/btrfs-raid/
Data, RAID1: total=6.17TiB, used=6.05TiB
System, RAID1: total=32.00MiB, used=916.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, RAID1: total=10.00GiB, used=8.14GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
Maybe this is also of use in identifying the problem:
grep btrfs *
grep: apt: Ist ein Verzeichnis
grep: cups: Ist ein Verzeichnis
dpkg.log:2016-09-03 15:20:16 upgrade btrfs-progs:amd64 4.7-1 4.7.1-1
dpkg.log:2016-09-03 15:20:16 status triggers-awaited btrfs-progs:amd64 4.7-1
dpkg.log:2016-09-03 15:20:16 status half-configured btrfs-progs:amd64 4.7-1
dpkg.log:2016-09-03 15:20:16 status unpacked btrfs-progs:amd64 4.7-1
dpkg.log:2016-09-03 15:20:16 status half-installed btrfs-progs:amd64 4.7-1
dpkg.log:2016-09-03 15:20:16 status half-installed btrfs-progs:amd64 4.7-1
dpkg.log:2016-09-03 15:20:17 status unpacked btrfs-progs:amd64 4.7.1-1
dpkg.log:2016-09-03 15:20:17 status unpacked btrfs-progs:amd64 4.7.1-1
dpkg.log:2016-09-03 15:20:45 configure btrfs-progs:amd64 4.7.1-1 <keine>
dpkg.log:2016-09-03 15:20:45 status unpacked btrfs-progs:amd64 4.7.1-1
dpkg.log:2016-09-03 15:20:45 status unpacked btrfs-progs:amd64 4.7.1-1
dpkg.log:2016-09-03 15:20:45 status half-configured btrfs-progs:amd64 4.7.1-1
dpkg.log:2016-09-03 15:20:46 status triggers-awaited btrfs-progs:amd64 4.7.1-1
dpkg.log:2016-09-03 15:20:51 status installed btrfs-progs:amd64 4.7.1-1
dpkg.log.1:2016-08-10 16:58:23 upgrade btrfs-progs:amd64 4.5.2-1 4.6.1-1
dpkg.log.1:2016-08-10 16:58:23 status triggers-awaited btrfs-progs:amd64 4.5.2-1
dpkg.log.1:2016-08-10 16:58:23 status half-configured btrfs-progs:amd64 4.5.2-1
dpkg.log.1:2016-08-10 16:58:23 status unpacked btrfs-progs:amd64 4.5.2-1
dpkg.log.1:2016-08-10 16:58:23 status half-installed btrfs-progs:amd64 4.5.2-1
dpkg.log.1:2016-08-10 16:58:24 status half-installed btrfs-progs:amd64 4.5.2-1
dpkg.log.1:2016-08-10 16:58:24 status unpacked btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-10 16:58:24 status unpacked btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-10 17:01:25 configure btrfs-progs:amd64 4.6.1-1 <keine>
dpkg.log.1:2016-08-10 17:01:25 status unpacked btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-10 17:01:26 status unpacked btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-10 17:01:26 status half-configured btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-10 17:01:26 status triggers-awaited btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-10 17:02:34 status installed btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-19 00:45:05 upgrade btrfs-progs:amd64 4.6.1-1 4.7-1
dpkg.log.1:2016-08-19 00:45:05 status triggers-awaited btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-19 00:45:05 status half-configured btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-19 00:45:05 status unpacked btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-19 00:45:05 status half-installed btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-19 00:45:06 status half-installed btrfs-progs:amd64 4.6.1-1
dpkg.log.1:2016-08-19 00:45:06 status unpacked btrfs-progs:amd64 4.7-1
dpkg.log.1:2016-08-19 00:45:06 status unpacked btrfs-progs:amd64 4.7-1
dpkg.log.1:2016-08-19 00:47:06 configure btrfs-progs:amd64 4.7-1 <keine>
dpkg.log.1:2016-08-19 00:47:06 status unpacked btrfs-progs:amd64 4.7-1
dpkg.log.1:2016-08-19 00:47:06 status unpacked btrfs-progs:amd64 4.7-1
dpkg.log.1:2016-08-19 00:47:06 status half-configured btrfs-progs:amd64 4.7-1
dpkg.log.1:2016-08-19 00:47:06 status triggers-awaited btrfs-progs:amd64 4.7-1
dpkg.log.1:2016-08-19 00:49:22 status installed btrfs-progs:amd64 4.7-1
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Size of scrubbed Data
2016-09-15 15:48 Size of scrubbed Data Stefan Malte Schumacher
@ 2016-09-15 20:11 ` g6094199
2016-09-15 21:10 ` Stefan Malte Schumacher
2016-09-15 21:18 ` Chris Murphy
1 sibling, 1 reply; 10+ messages in thread
From: g6094199 @ 2016-09-15 20:11 UTC (permalink / raw)
To: Btrfs BTRFS
Hi Stefan,
1st you should run an balance on system data to move the single data to
raid1. imho.
then do the scrub again.
btw are there any scrubbing errors in dmesg? disks are ok?! any
compression involved? changed freespacecache to v2?
sash
Am 15.09.2016 um 17:48 schrieb Stefan Malte Schumacher:
> Hello
>
>
> I have encountered a very strange phenomenon while using btrfs-scrub.
> I believe it may be a result of replacing my old installation of
> Debian Jessie with Debian Stretch, resulting in a Kernel Switch from
> 3.16+63 to 4.6.0-1. I scrub my filesystem once a month and let anacron
> send me the results. My filesystem, consisting of four four-gigabyte
> drives with both data and metadata as RAID1 was reported as containing
> nearly 12TiB of data in scrubs done in May, June, July and August. But
> then it changed and suddenly shows only 9TiB in size, despite the fact
> that I did not delete any large files. If I remember correctly my
> switch from Debian Jessie to Stretch was around that time period.
> Could someone explain this behavior to me? Was a new way of
> calculating the size of scrubed data introduced? How can I check if I
> have lost data? I have a backup, but only one generation and rsync
> will by now have deleted files on the NAS, which might have lost on
> the fileserver. According to the long and short self-tests, which I
> run with smartmontools my drives are alright. How do I proceed?
>
>
>
> Yours
>
> Stefan
>
> uname -a
> Linux mars 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64 GNU/Linux
>
> btrfs --version
> btrfs-progs v4.7.1
>
> btrfs fi show
> Label: none uuid: 8c668854-db5d-45a7-875d-43c4e82a829e
> Total devices 4 FS bytes used 6.06TiB
> devid 1 size 3.64TiB used 3.09TiB path /dev/sde
> devid 2 size 3.64TiB used 3.09TiB path /dev/sdc
> devid 3 size 3.64TiB used 3.09TiB path /dev/sdd
> devid 4 size 3.64TiB used 3.09TiB path /dev/sda
>
>
> btrfs fi df /mnt/btrfs-raid/
> Data, RAID1: total=6.17TiB, used=6.05TiB
> System, RAID1: total=32.00MiB, used=916.00KiB
> System, single: total=4.00MiB, used=0.00B
> Metadata, RAID1: total=10.00GiB, used=8.14GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
>
> Maybe this is also of use in identifying the problem:
> grep btrfs *
> grep: apt: Ist ein Verzeichnis
> grep: cups: Ist ein Verzeichnis
> dpkg.log:2016-09-03 15:20:16 upgrade btrfs-progs:amd64 4.7-1 4.7.1-1
> dpkg.log:2016-09-03 15:20:16 status triggers-awaited btrfs-progs:amd64 4.7-1
> dpkg.log:2016-09-03 15:20:16 status half-configured btrfs-progs:amd64 4.7-1
> dpkg.log:2016-09-03 15:20:16 status unpacked btrfs-progs:amd64 4.7-1
> dpkg.log:2016-09-03 15:20:16 status half-installed btrfs-progs:amd64 4.7-1
> dpkg.log:2016-09-03 15:20:16 status half-installed btrfs-progs:amd64 4.7-1
> dpkg.log:2016-09-03 15:20:17 status unpacked btrfs-progs:amd64 4.7.1-1
> dpkg.log:2016-09-03 15:20:17 status unpacked btrfs-progs:amd64 4.7.1-1
> dpkg.log:2016-09-03 15:20:45 configure btrfs-progs:amd64 4.7.1-1 <keine>
> dpkg.log:2016-09-03 15:20:45 status unpacked btrfs-progs:amd64 4.7.1-1
> dpkg.log:2016-09-03 15:20:45 status unpacked btrfs-progs:amd64 4.7.1-1
> dpkg.log:2016-09-03 15:20:45 status half-configured btrfs-progs:amd64 4.7.1-1
> dpkg.log:2016-09-03 15:20:46 status triggers-awaited btrfs-progs:amd64 4.7.1-1
> dpkg.log:2016-09-03 15:20:51 status installed btrfs-progs:amd64 4.7.1-1
> dpkg.log.1:2016-08-10 16:58:23 upgrade btrfs-progs:amd64 4.5.2-1 4.6.1-1
> dpkg.log.1:2016-08-10 16:58:23 status triggers-awaited btrfs-progs:amd64 4.5.2-1
> dpkg.log.1:2016-08-10 16:58:23 status half-configured btrfs-progs:amd64 4.5.2-1
> dpkg.log.1:2016-08-10 16:58:23 status unpacked btrfs-progs:amd64 4.5.2-1
> dpkg.log.1:2016-08-10 16:58:23 status half-installed btrfs-progs:amd64 4.5.2-1
> dpkg.log.1:2016-08-10 16:58:24 status half-installed btrfs-progs:amd64 4.5.2-1
> dpkg.log.1:2016-08-10 16:58:24 status unpacked btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-10 16:58:24 status unpacked btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-10 17:01:25 configure btrfs-progs:amd64 4.6.1-1 <keine>
> dpkg.log.1:2016-08-10 17:01:25 status unpacked btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-10 17:01:26 status unpacked btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-10 17:01:26 status half-configured btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-10 17:01:26 status triggers-awaited btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-10 17:02:34 status installed btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-19 00:45:05 upgrade btrfs-progs:amd64 4.6.1-1 4.7-1
> dpkg.log.1:2016-08-19 00:45:05 status triggers-awaited btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-19 00:45:05 status half-configured btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-19 00:45:05 status unpacked btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-19 00:45:05 status half-installed btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-19 00:45:06 status half-installed btrfs-progs:amd64 4.6.1-1
> dpkg.log.1:2016-08-19 00:45:06 status unpacked btrfs-progs:amd64 4.7-1
> dpkg.log.1:2016-08-19 00:45:06 status unpacked btrfs-progs:amd64 4.7-1
> dpkg.log.1:2016-08-19 00:47:06 configure btrfs-progs:amd64 4.7-1 <keine>
> dpkg.log.1:2016-08-19 00:47:06 status unpacked btrfs-progs:amd64 4.7-1
> dpkg.log.1:2016-08-19 00:47:06 status unpacked btrfs-progs:amd64 4.7-1
> dpkg.log.1:2016-08-19 00:47:06 status half-configured btrfs-progs:amd64 4.7-1
> dpkg.log.1:2016-08-19 00:47:06 status triggers-awaited btrfs-progs:amd64 4.7-1
> dpkg.log.1:2016-08-19 00:49:22 status installed btrfs-progs:amd64 4.7-1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Size of scrubbed Data
2016-09-15 20:11 ` g6094199
@ 2016-09-15 21:10 ` Stefan Malte Schumacher
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Malte Schumacher @ 2016-09-15 21:10 UTC (permalink / raw)
To: g6094199; +Cc: Btrfs BTRFS
Hi sash
How do I move the single system data to raid1? Dmesg doesnt show any
scrubbing errors, according to Smart all the disks are okay. I am not
using any any compression. How would I change freespacecache to v2 and
what benefits would it entail?
I think I need to add the following to my original question: How is
"total bytes scrubbed" calculated? On a Raid1, shouldnt it be exactly
two times the actual data size on the disk?
Yours
Stefan
2016-09-15 22:11 GMT+02:00 <g6094199@freenet.de>:
> Hi Stefan,
>
> 1st you should run an balance on system data to move the single data to
> raid1. imho.
> then do the scrub again.
> btw are there any scrubbing errors in dmesg? disks are ok?! any
> compression involved? changed freespacecache to v2?
>
>
> sash
>
>
>
> Am 15.09.2016 um 17:48 schrieb Stefan Malte Schumacher:
>> Hello
>>
>>
>> I have encountered a very strange phenomenon while using btrfs-scrub.
>> I believe it may be a result of replacing my old installation of
>> Debian Jessie with Debian Stretch, resulting in a Kernel Switch from
>> 3.16+63 to 4.6.0-1. I scrub my filesystem once a month and let anacron
>> send me the results. My filesystem, consisting of four four-gigabyte
>> drives with both data and metadata as RAID1 was reported as containing
>> nearly 12TiB of data in scrubs done in May, June, July and August. But
>> then it changed and suddenly shows only 9TiB in size, despite the fact
>> that I did not delete any large files. If I remember correctly my
>> switch from Debian Jessie to Stretch was around that time period.
>> Could someone explain this behavior to me? Was a new way of
>> calculating the size of scrubed data introduced? How can I check if I
>> have lost data? I have a backup, but only one generation and rsync
>> will by now have deleted files on the NAS, which might have lost on
>> the fileserver. According to the long and short self-tests, which I
>> run with smartmontools my drives are alright. How do I proceed?
>>
>>
>>
>> Yours
>>
>> Stefan
>>
>> uname -a
>> Linux mars 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64 GNU/Linux
>>
>> btrfs --version
>> btrfs-progs v4.7.1
>>
>> btrfs fi show
>> Label: none uuid: 8c668854-db5d-45a7-875d-43c4e82a829e
>> Total devices 4 FS bytes used 6.06TiB
>> devid 1 size 3.64TiB used 3.09TiB path /dev/sde
>> devid 2 size 3.64TiB used 3.09TiB path /dev/sdc
>> devid 3 size 3.64TiB used 3.09TiB path /dev/sdd
>> devid 4 size 3.64TiB used 3.09TiB path /dev/sda
>>
>>
>> btrfs fi df /mnt/btrfs-raid/
>> Data, RAID1: total=6.17TiB, used=6.05TiB
>> System, RAID1: total=32.00MiB, used=916.00KiB
>> System, single: total=4.00MiB, used=0.00B
>> Metadata, RAID1: total=10.00GiB, used=8.14GiB
>> GlobalReserve, single: total=512.00MiB, used=0.00B
>>
>> Maybe this is also of use in identifying the problem:
>> grep btrfs *
>> grep: apt: Ist ein Verzeichnis
>> grep: cups: Ist ein Verzeichnis
>> dpkg.log:2016-09-03 15:20:16 upgrade btrfs-progs:amd64 4.7-1 4.7.1-1
>> dpkg.log:2016-09-03 15:20:16 status triggers-awaited btrfs-progs:amd64 4.7-1
>> dpkg.log:2016-09-03 15:20:16 status half-configured btrfs-progs:amd64 4.7-1
>> dpkg.log:2016-09-03 15:20:16 status unpacked btrfs-progs:amd64 4.7-1
>> dpkg.log:2016-09-03 15:20:16 status half-installed btrfs-progs:amd64 4.7-1
>> dpkg.log:2016-09-03 15:20:16 status half-installed btrfs-progs:amd64 4.7-1
>> dpkg.log:2016-09-03 15:20:17 status unpacked btrfs-progs:amd64 4.7.1-1
>> dpkg.log:2016-09-03 15:20:17 status unpacked btrfs-progs:amd64 4.7.1-1
>> dpkg.log:2016-09-03 15:20:45 configure btrfs-progs:amd64 4.7.1-1 <keine>
>> dpkg.log:2016-09-03 15:20:45 status unpacked btrfs-progs:amd64 4.7.1-1
>> dpkg.log:2016-09-03 15:20:45 status unpacked btrfs-progs:amd64 4.7.1-1
>> dpkg.log:2016-09-03 15:20:45 status half-configured btrfs-progs:amd64 4.7.1-1
>> dpkg.log:2016-09-03 15:20:46 status triggers-awaited btrfs-progs:amd64 4.7.1-1
>> dpkg.log:2016-09-03 15:20:51 status installed btrfs-progs:amd64 4.7.1-1
>> dpkg.log.1:2016-08-10 16:58:23 upgrade btrfs-progs:amd64 4.5.2-1 4.6.1-1
>> dpkg.log.1:2016-08-10 16:58:23 status triggers-awaited btrfs-progs:amd64 4.5.2-1
>> dpkg.log.1:2016-08-10 16:58:23 status half-configured btrfs-progs:amd64 4.5.2-1
>> dpkg.log.1:2016-08-10 16:58:23 status unpacked btrfs-progs:amd64 4.5.2-1
>> dpkg.log.1:2016-08-10 16:58:23 status half-installed btrfs-progs:amd64 4.5.2-1
>> dpkg.log.1:2016-08-10 16:58:24 status half-installed btrfs-progs:amd64 4.5.2-1
>> dpkg.log.1:2016-08-10 16:58:24 status unpacked btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-10 16:58:24 status unpacked btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-10 17:01:25 configure btrfs-progs:amd64 4.6.1-1 <keine>
>> dpkg.log.1:2016-08-10 17:01:25 status unpacked btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-10 17:01:26 status unpacked btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-10 17:01:26 status half-configured btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-10 17:01:26 status triggers-awaited btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-10 17:02:34 status installed btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-19 00:45:05 upgrade btrfs-progs:amd64 4.6.1-1 4.7-1
>> dpkg.log.1:2016-08-19 00:45:05 status triggers-awaited btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-19 00:45:05 status half-configured btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-19 00:45:05 status unpacked btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-19 00:45:05 status half-installed btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-19 00:45:06 status half-installed btrfs-progs:amd64 4.6.1-1
>> dpkg.log.1:2016-08-19 00:45:06 status unpacked btrfs-progs:amd64 4.7-1
>> dpkg.log.1:2016-08-19 00:45:06 status unpacked btrfs-progs:amd64 4.7-1
>> dpkg.log.1:2016-08-19 00:47:06 configure btrfs-progs:amd64 4.7-1 <keine>
>> dpkg.log.1:2016-08-19 00:47:06 status unpacked btrfs-progs:amd64 4.7-1
>> dpkg.log.1:2016-08-19 00:47:06 status unpacked btrfs-progs:amd64 4.7-1
>> dpkg.log.1:2016-08-19 00:47:06 status half-configured btrfs-progs:amd64 4.7-1
>> dpkg.log.1:2016-08-19 00:47:06 status triggers-awaited btrfs-progs:amd64 4.7-1
>> dpkg.log.1:2016-08-19 00:49:22 status installed btrfs-progs:amd64 4.7-1
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Size of scrubbed Data
2016-09-15 15:48 Size of scrubbed Data Stefan Malte Schumacher
2016-09-15 20:11 ` g6094199
@ 2016-09-15 21:18 ` Chris Murphy
2016-09-16 12:21 ` Nicholas Steeves
2016-09-17 14:34 ` Tim Walberg
1 sibling, 2 replies; 10+ messages in thread
From: Chris Murphy @ 2016-09-15 21:18 UTC (permalink / raw)
To: Stefan Malte Schumacher; +Cc: Btrfs BTRFS
On Thu, Sep 15, 2016 at 9:48 AM, Stefan Malte Schumacher
<stefan.m.schumacher@gmail.com> wrote:
>
> btrfs --version
> btrfs-progs v4.7.1
Upgrade to 4.7.2 or downgrade to 4.6.1 before using btrfs check; see
the changelog for details. I'm not recommending that you use btrfs
check, just staying this version of tools is not reliable for some
file systems.
> btrfs fi df /mnt/btrfs-raid/
> Data, RAID1: total=6.17TiB, used=6.05TiB
> System, RAID1: total=32.00MiB, used=916.00KiB
> System, single: total=4.00MiB, used=0.00B
> Metadata, RAID1: total=10.00GiB, used=8.14GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
The 3rd line is possibly rather dangerous in that it might mean
there's some tiny amount of system data that has only one copy on one
drive. And since it's a system chunk, if it's true that there's only
one copy, if it were damaged or lost, it'd take out the whole volume.
btrfs balance start -mconvert=raid1,soft <mp>
See what that gets you, and then recheck with btrfs fi df or better
use btrfs fi us.
Unfortunately I don't have an answer for the original question.
--
Chris Murphy
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Size of scrubbed Data
2016-09-15 21:18 ` Chris Murphy
@ 2016-09-16 12:21 ` Nicholas Steeves
2016-09-17 11:02 ` Stefan Malte Schumacher
2016-09-17 14:34 ` Tim Walberg
1 sibling, 1 reply; 10+ messages in thread
From: Nicholas Steeves @ 2016-09-16 12:21 UTC (permalink / raw)
To: Chris Murphy; +Cc: Stefan Malte Schumacher, Btrfs BTRFS
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
Thank you for the assistance Chris :-)
On 15 September 2016 at 17:18, Chris Murphy <lists@colorremedies.com> wrote:
>> On Thu, Sep 15, 2016 at 9:48 AM, Stefan Malte Schumacher
>> <stefan.m.schumacher@gmail.com> wrote:
...
>> I believe it may be a result of replacing my old installation of
>> Debian Jessie with Debian Stretch
...
>
>>
>> btrfs --version
>> btrfs-progs v4.7.1
>
> Upgrade to 4.7.2 or downgrade to 4.6.1 before using btrfs check; see
> the changelog for details. I'm not recommending that you use btrfs
> check, just saying this version of tools is not reliable for some
> file systems.
Hi Stefan, as far as I can tell 4.7.2 is currently blocked from
migrating from unstable to testing due to a glibc version transition,
so the easiest thing to do is to get fall back on 4.6.1 found here:
http://snapshot.debian.org/package/btrfs-progs/4.6.1-1/
Cheers,
Nicholas
P.S. You're brave to run testing before the soft-freeze! Occasionally
security fixes in sid can't propagate to testing, because a transition
like this is in progress ( https://www.debian.org/security/faq#testing
).
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Size of scrubbed Data
2016-09-16 12:21 ` Nicholas Steeves
@ 2016-09-17 11:02 ` Stefan Malte Schumacher
2016-09-17 13:27 ` Adam Borowski
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Malte Schumacher @ 2016-09-17 11:02 UTC (permalink / raw)
To: Nicholas Steeves; +Cc: Chris Murphy, Btrfs BTRFS
Hello
Thanks for the information. I did another run of scrubbing et voila:
total bytes scrubbed: 12.11TiB with 0 errors, which is pretty much two
times the amount of actual data stored on the filesystem. I am
relieved, but still would like to know why this went wrong in the
first place and why it is working again without me doing anything to
fix it.
Concerning Testing: I only use it on desktops and home servers, which
do not offer any services to the net. I am very fond of Debian and
always use stable or even old-stable on work servers, but was finally
to annoyed at the fact that the software I was using on a fresh
installation was practically already out of date.
Yours sincerely
Stefan
2016-09-16 14:21 GMT+02:00 Nicholas Steeves <nsteeves@gmail.com>:
> Thank you for the assistance Chris :-)
>
> On 15 September 2016 at 17:18, Chris Murphy <lists@colorremedies.com> wrote:
>>> On Thu, Sep 15, 2016 at 9:48 AM, Stefan Malte Schumacher
>>> <stefan.m.schumacher@gmail.com> wrote:
> ...
>>> I believe it may be a result of replacing my old installation of
>>> Debian Jessie with Debian Stretch
> ...
>>
>>>
>>> btrfs --version
>>> btrfs-progs v4.7.1
>>
>> Upgrade to 4.7.2 or downgrade to 4.6.1 before using btrfs check; see
>> the changelog for details. I'm not recommending that you use btrfs
>> check, just saying this version of tools is not reliable for some
>> file systems.
>
> Hi Stefan, as far as I can tell 4.7.2 is currently blocked from
> migrating from unstable to testing due to a glibc version transition,
> so the easiest thing to do is to get fall back on 4.6.1 found here:
> http://snapshot.debian.org/package/btrfs-progs/4.6.1-1/
>
>
> Cheers,
> Nicholas
>
> P.S. You're brave to run testing before the soft-freeze! Occasionally
> security fixes in sid can't propagate to testing, because a transition
> like this is in progress ( https://www.debian.org/security/faq#testing
> ).
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Size of scrubbed Data
2016-09-17 11:02 ` Stefan Malte Schumacher
@ 2016-09-17 13:27 ` Adam Borowski
0 siblings, 0 replies; 10+ messages in thread
From: Adam Borowski @ 2016-09-17 13:27 UTC (permalink / raw)
To: Stefan Malte Schumacher; +Cc: Nicholas Steeves, Chris Murphy, Btrfs BTRFS
On Sat, Sep 17, 2016 at 01:02:18PM +0200, Stefan Malte Schumacher wrote:
> Concerning Testing: I only use it on desktops and home servers, which
> do not offer any services to the net. I am very fond of Debian and
> always use stable or even old-stable on work servers, but was finally
> to annoyed at the fact that the software I was using on a fresh
> installation was practically already out of date.
These days *-backports has pretty much everything you'd want for a real
reason, and maintainers tend to be forthcoming when asked; the rules allow
anyone with upload rights to backport anything (the string attached is
"you're then responsible for bugs and other problems") but it's customary to
ask the regular maintainer first.
Of course you won't get bling this way -- it's unreasonable to backport more
than a few dependant packages so a desktop environment is right out. But
server packages, a major new version of an editor or mail client, or
sometimes even a new game are fine.
Obviously, stuff like new kernels or new btrfs-progs tend to come fast.
On the other hand, this means using testing outside of (soft-) freezes
became far less supported than it used to be in the past.
--
Second "wet cat laying down on a powered-on box-less SoC on the desk" close
shave in a week. Protect your ARMs, folks!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Size of scrubbed Data
2016-09-15 21:18 ` Chris Murphy
2016-09-16 12:21 ` Nicholas Steeves
@ 2016-09-17 14:34 ` Tim Walberg
2016-09-17 15:08 ` Tim Walberg
2016-09-17 15:24 ` Chris Murphy
1 sibling, 2 replies; 10+ messages in thread
From: Tim Walberg @ 2016-09-17 14:34 UTC (permalink / raw)
To: Chris Murphy; +Cc: Stefan Malte Schumacher, Btrfs BTRFS
On 09/15/2016 15:18 -0600, Chris Murphy wrote:
>> > System, single: total=4.00MiB, used=0.00B
>> > Metadata, RAID1: total=10.00GiB, used=8.14GiB
>> > GlobalReserve, single: total=512.00MiB, used=0.00B
>>
>> btrfs balance start -mconvert=raid1,soft <mp>
Since the single profile data is single, that should probably be
"-s" instead of "-m"... I.e.
btrfs balance start -sconvert=raid1,soft <mp>
It may also need "-f", since btrfs balance is a bit more paranoid
about reprofiling system data.
--
twalberg@gmail.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Size of scrubbed Data
2016-09-17 14:34 ` Tim Walberg
@ 2016-09-17 15:08 ` Tim Walberg
2016-09-17 15:24 ` Chris Murphy
1 sibling, 0 replies; 10+ messages in thread
From: Tim Walberg @ 2016-09-17 15:08 UTC (permalink / raw)
To: Chris Murphy; +Cc: Stefan Malte Schumacher, Btrfs BTRFS
On 09/17/2016 09:34 -0500, Walberg, Tim wrote:
>> On 09/15/2016 15:18 -0600, Chris Murphy wrote:
>> >> > System, single: total=4.00MiB, used=0.00B
>> >> > Metadata, RAID1: total=10.00GiB, used=8.14GiB
>> >> > GlobalReserve, single: total=512.00MiB, used=0.00B
>> >>
>> >> btrfs balance start -mconvert=raid1,soft <mp>
>>
>>
Gaaa... I meant "since the single profile data is system, ..."
>> Since the single profile data is single, that should probably be
>> "-s" instead of "-m"... I.e.
>>
>> btrfs balance start -sconvert=raid1,soft <mp>
>>
>> It may also need "-f", since btrfs balance is a bit more paranoid
>> about reprofiling system data.
>>
>>
>>
>> --
>> twalberg@gmail.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
End of included message
--
twalberg@gmail.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Size of scrubbed Data
2016-09-17 14:34 ` Tim Walberg
2016-09-17 15:08 ` Tim Walberg
@ 2016-09-17 15:24 ` Chris Murphy
1 sibling, 0 replies; 10+ messages in thread
From: Chris Murphy @ 2016-09-17 15:24 UTC (permalink / raw)
To: Tim Walberg; +Cc: Chris Murphy, Stefan Malte Schumacher, Btrfs BTRFS
On Sat, Sep 17, 2016 at 8:34 AM, Tim Walberg <twalberg@comcast.net> wrote:
> On 09/15/2016 15:18 -0600, Chris Murphy wrote:
>>> > System, single: total=4.00MiB, used=0.00B
>>> > Metadata, RAID1: total=10.00GiB, used=8.14GiB
>>> > GlobalReserve, single: total=512.00MiB, used=0.00B
>>>
>>> btrfs balance start -mconvert=raid1,soft <mp>
>
>
> Since the single profile data is single, that should probably be
> "-s" instead of "-m"... I.e.
>
> btrfs balance start -sconvert=raid1,soft <mp>
>
> It may also need "-f", since btrfs balance is a bit more paranoid
> about reprofiling system data.
Originally -m only handled metadata, not system chunks. But these days
-m includes metadata and system chunks, where -s is only system
chunks.
--
Chris Murphy
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-09-17 15:24 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-15 15:48 Size of scrubbed Data Stefan Malte Schumacher
2016-09-15 20:11 ` g6094199
2016-09-15 21:10 ` Stefan Malte Schumacher
2016-09-15 21:18 ` Chris Murphy
2016-09-16 12:21 ` Nicholas Steeves
2016-09-17 11:02 ` Stefan Malte Schumacher
2016-09-17 13:27 ` Adam Borowski
2016-09-17 14:34 ` Tim Walberg
2016-09-17 15:08 ` Tim Walberg
2016-09-17 15:24 ` Chris Murphy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.