Re: Understanding "btrfs filesystem usage"

[Ulli Horlacher]

On Tue 2018-10-30 (17:10), Ulli Horlacher wrote:
> 
> On Mon 2018-10-29 (17:57), Remi Gauvin wrote:
> 
> > On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
> > 
> > > I want to know how many free space is left and have problems in
> > > interpreting the output of: 
> > > 
> > > btrfs filesystem usage
> > > btrfs filesystem df
> > > btrfs filesystem show
> > 
> > In my not so humble opinion, the filesystem usage command has the
> > easiest to understand output.  It' lays out all the pertinent information.
> > 
> > You can clearly see 825GiB is allocated, with 494GiB used, therefore,
> > filesystem show is actually using the "Allocated" value as "Used".
> > Allocated can be thought of "Reserved For".
> 
> And what is "Device unallocated"? Not reserved?

The answer is in the FAQ and I am stupid not to looked at it, first :-}

https://btrfs.wiki.kernel.org/index.php/FAQ#How_much_free_space_do_I_have.3F


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20181030161003.ga25...@rus.uni-stuttgart.de>

Re: Understanding "btrfs filesystem usage"

[Chris Murphy]

On Tue, Oct 30, 2018 at 10:10 AM, Ulli Horlacher
 wrote:
>
> On Mon 2018-10-29 (17:57), Remi Gauvin wrote:
>> On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
>>
>> > I want to know how many free space is left and have problems in
>> > interpreting the output of:
>> >
>> > btrfs filesystem usage
>> > btrfs filesystem df
>> > btrfs filesystem show
>>
>> In my not so humble opinion, the filesystem usage command has the
>> easiest to understand output.  It' lays out all the pertinent information.
>>
>> You can clearly see 825GiB is allocated, with 494GiB used, therefore,
>> filesystem show is actually using the "Allocated" value as "Used".
>> Allocated can be thought of "Reserved For".
>
> And what is "Device unallocated"? Not reserved?

That's a reasonable interpretation. Unallocated space is space that's
not used for anything: no data, no metadata, and isn't reference by
any block group.

It's not a relevant number day to day, I'd say it's advanced leaning
toward esoteric knowledge of Btrfs internals. At this point I'd like
to see a simper output by default, and have a verbose option for
advanced users, and an export option that spits out a superset of all
available information in a format parsable for scripts. But I know
there are other project that depend on btrfs user space output, rather
than having something specifically invented for them that's easily
parsed, and can be kept consistent and extendible, separate from human
user consumption. Oh well!




>> The disparity between 498GiB used and 823Gib is pretty high.  This is
>> probably the result of using an SSD with an older kernel.  If your
>> kernel is not very recent, (sorry, I forget where this was fixed,
>> somewhere around 4.14 or 4.15), then consider mounting with the nossd
>> option.
>
> I am running kernel 4.4 (it is a Ubuntu 16.04 system)
> But /local is on a SSD. Should I really use nossd mount option?!

Yes. But it's not a file system integrity suggestion, it's an optimization.


>
>
>
>> You can improve this by running a balance.
>>
>> Something like:
>> btrfs balance start -dusage=55
>
> I run balance via cron weekly (adapted
> https://software.opensuse.org/package/btrfsmaintenance)

With a newer kernel you can probably reduce this further depending on
your workload and use case. And optionally follow it up with executing
fstrim, or just enable fstrim.timer (we don't recommend using discard
mount option for most use cases as it too aggressively discards very
recently stale Btrfs metadata and can make recovery from crashes
harder).

There is a trim bug that causes FITRIM to only get applied to
unallocated space on older file systems, that have been balanced such
that block group logical addresses are outside the physical address
space of the device which prevents the free space inside of such block
groups to be passed over for FITRIM. Looks like this will be fixed in
kernel 4.20/5.0




-- 
Chris Murphy

Re: Understanding "btrfs filesystem usage"

[Austin S. Hemmelgarn]

On 10/30/2018 12:10 PM, Ulli Horlacher wrote:


On Mon 2018-10-29 (17:57), Remi Gauvin wrote:

On 2018-10-29 02:11 PM, Ulli Horlacher wrote:


I want to know how many free space is left and have problems in
interpreting the output of:

btrfs filesystem usage
btrfs filesystem df
btrfs filesystem show


In my not so humble opinion, the filesystem usage command has the
easiest to understand output.  It' lays out all the pertinent information.

You can clearly see 825GiB is allocated, with 494GiB used, therefore,
filesystem show is actually using the "Allocated" value as "Used".
Allocated can be thought of "Reserved For".


And what is "Device unallocated"? Not reserved?



As the output of the Usage command and df command clearly show, you have
almost 400GiB space available.


This is the good part :-)



The disparity between 498GiB used and 823Gib is pretty high.  This is
probably the result of using an SSD with an older kernel.  If your
kernel is not very recent, (sorry, I forget where this was fixed,
somewhere around 4.14 or 4.15), then consider mounting with the nossd
option.


I am running kernel 4.4 (it is a Ubuntu 16.04 system)
But /local is on a SSD. Should I really use nossd mount option?!

Probably, and you may even want to use it on newer (patched) kernels.

This requires some explanation though.

SSD's are write limited media (write to them too much, and they stop 
working).  This is generally a pretty well known fact, and while it is 
true, it's not anywhere near as much of an issue on modern SSD"s as 
people make it out to be (pretty much, if you've got an SSD made in the 
last 5 years, you almost certainly don't have to worry about this).  The 
`ssd` code in BTRFS behaves as if this is still an issue (and does so in 
a way that doesn't even solve it well).


Put simply, when BTRFS goes to look for space, it treats requests for 
space that ask for less than a certain size as if they are that minimum 
size, and only tries to look for smaller spots if it can't find one at 
least that minimum size.  This has a couple of advantages in terms of 
write performance, especially in the common case of a mostly empty 
filesystem.


For the default (`nossd`) case, that minimum size is 64kB.  So, in most 
cases, the potentially wasted space actually doesn't matter much (most 
writes are bigger than 64k) unless you're doing certain things.


For the old (`ssd`) case, that minimum size is 2MB.  Even with the 
common cases that would normally not have an issue with the 64k default, 
this ends up wasting a _huge_ amount of space.


For the new `ssd` behavior, the minimum is different for data and 
metadata (IIRC, metadata uses the 64k default, while data still uses the 
2M size).  This solves the biggest issues (which were seen with 
metadata), but doesn't completely remove the problem.


Expanding on this further, some unusual workloads actually benefit from 
the old `ssd` behavior, so on newer kernels `ssd_spread` gives that 
behavior.  However, many workloads actually do better with the `nossd` 
behavior (especially the pathological worst case stuff like databases 
and VM disk images), so if you have a recent SSD, you probably want to 
just use that.




You can improve this by running a balance.

Something like:
btrfs balance start -dusage=55


I run balance via cron weekly (adapted
https://software.opensuse.org/package/btrfsmaintenance)

Re: Understanding "btrfs filesystem usage"

[Ulli Horlacher]

On Mon 2018-10-29 (17:57), Remi Gauvin wrote:
> On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
> 
> > I want to know how many free space is left and have problems in
> > interpreting the output of: 
> > 
> > btrfs filesystem usage
> > btrfs filesystem df
> > btrfs filesystem show
> 
> In my not so humble opinion, the filesystem usage command has the
> easiest to understand output.  It' lays out all the pertinent information.
> 
> You can clearly see 825GiB is allocated, with 494GiB used, therefore,
> filesystem show is actually using the "Allocated" value as "Used".
> Allocated can be thought of "Reserved For".

And what is "Device unallocated"? Not reserved?


> As the output of the Usage command and df command clearly show, you have
> almost 400GiB space available.

This is the good part :-)


> The disparity between 498GiB used and 823Gib is pretty high.  This is
> probably the result of using an SSD with an older kernel.  If your
> kernel is not very recent, (sorry, I forget where this was fixed,
> somewhere around 4.14 or 4.15), then consider mounting with the nossd
> option.

I am running kernel 4.4 (it is a Ubuntu 16.04 system)
But /local is on a SSD. Should I really use nossd mount option?!



> You can improve this by running a balance.
> 
> Something like:
> btrfs balance start -dusage=55

I run balance via cron weekly (adapted 
https://software.opensuse.org/package/btrfsmaintenance)


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<85a63523-7e77-f4ca-9947-2c957c5c5...@georgianit.com>

Re: Understanding "btrfs filesystem usage"

[Eli V]

On Mon, Oct 29, 2018 at 6:46 PM Hugo Mills  wrote:
>
> On Mon, Oct 29, 2018 at 05:57:10PM -0400, Remi Gauvin wrote:
> > On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
> > > I want to know how many free space is left and have problems in
> > > interpreting the output of:
> > >
> > > btrfs filesystem usage
> > > btrfs filesystem df
> > > btrfs filesystem show
> > >
> > >
> >
> > In my not so humble opinion, the filesystem usage command has the
> > easiest to understand output.  It' lays out all the pertinent information.
>
>Opinions are divided. I find it almost impossible to read, and
> always use btrfs fi df and btrfs fi show together.

I find the tabular output via -T makes btrfs file usage much easier to
read, and it's now the only command I use to look at it space usage on
btrfs.

>
>There's short tutorials of how to read the output in both cases in
> the FAQ, which is where I start out by directing people in this
> instance.
>
>Hugo.
>
> > You can clearly see 825GiB is allocated, with 494GiB used, therefore,
> > filesystem show is actually using the "Allocated" value as "Used".
> > Allocated can be thought of "Reserved For".  As the output of the Usage
> > command and df command clearly show, you have almost 400GiB space available.
> >
> > Note that the btrfs commands are clearly and explicitly displaying
> > values in Binary units, (Mi, and Gi prefix, respectively).  If you want
> > df command to match, use -h instead of -H (see man df)
> >
> > An observation:
> >
> > The disparity between 498GiB used and 823Gib is pretty high.  This is
> > probably the result of using an SSD with an older kernel.  If your
> > kernel is not very recent, (sorry, I forget where this was fixed,
> > somewhere around 4.14 or 4.15), then consider mounting with the nossd
> > option.  You can improve this by running a balance.
> >
> > Something like:
> > btrfs balance start -dusage=55
> >
> > You do *not* want to end up with all your space allocated to Data, but
> > not actually used by data.  Bad things can happen if you run out of
> > Unallocated space for more metadata. (not catastrophic, but awkward and
> > unexpected downtime that can be a little tricky to sort out.)
> >
> >
>
> > begin:vcard
> > fn:Remi Gauvin
> > n:Gauvin;Remi
> > org:Georgian Infotech
> > adr:;;3-51 Sykes St. N.;Meaford;ON;N4L 1X3;Canada
> > email;internet:r...@georgianit.com
> > tel;work:226-256-1545
> > version:2.1
> > end:vcard
> >
>
>
> --
> Hugo Mills | Great oxymorons of the world, no. 8:
> hugo@... carfax.org.uk | The Latest In Proven Technology
> http://carfax.org.uk/  |
> PGP: E2AB1DE4  |

Re: Understanding "btrfs filesystem usage"

[Hugo Mills]

On Mon, Oct 29, 2018 at 05:57:10PM -0400, Remi Gauvin wrote:
> On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
> > I want to know how many free space is left and have problems in
> > interpreting the output of: 
> > 
> > btrfs filesystem usage
> > btrfs filesystem df
> > btrfs filesystem show
> > 
> >
> 
> In my not so humble opinion, the filesystem usage command has the
> easiest to understand output.  It' lays out all the pertinent information.

   Opinions are divided. I find it almost impossible to read, and
always use btrfs fi df and btrfs fi show together.

   There's short tutorials of how to read the output in both cases in
the FAQ, which is where I start out by directing people in this
instance.

   Hugo.

> You can clearly see 825GiB is allocated, with 494GiB used, therefore,
> filesystem show is actually using the "Allocated" value as "Used".
> Allocated can be thought of "Reserved For".  As the output of the Usage
> command and df command clearly show, you have almost 400GiB space available.
> 
> Note that the btrfs commands are clearly and explicitly displaying
> values in Binary units, (Mi, and Gi prefix, respectively).  If you want
> df command to match, use -h instead of -H (see man df)
> 
> An observation:
> 
> The disparity between 498GiB used and 823Gib is pretty high.  This is
> probably the result of using an SSD with an older kernel.  If your
> kernel is not very recent, (sorry, I forget where this was fixed,
> somewhere around 4.14 or 4.15), then consider mounting with the nossd
> option.  You can improve this by running a balance.
> 
> Something like:
> btrfs balance start -dusage=55
> 
> You do *not* want to end up with all your space allocated to Data, but
> not actually used by data.  Bad things can happen if you run out of
> Unallocated space for more metadata. (not catastrophic, but awkward and
> unexpected downtime that can be a little tricky to sort out.)
> 
> 

> begin:vcard
> fn:Remi Gauvin
> n:Gauvin;Remi
> org:Georgian Infotech
> adr:;;3-51 Sykes St. N.;Meaford;ON;N4L 1X3;Canada
> email;internet:r...@georgianit.com
> tel;work:226-256-1545
> version:2.1
> end:vcard
> 


-- 
Hugo Mills | Great oxymorons of the world, no. 8:
hugo@... carfax.org.uk | The Latest In Proven Technology
http://carfax.org.uk/  |
PGP: E2AB1DE4  |


signature.asc
Description: Digital signature

Re: Understanding "btrfs filesystem usage"

[Remi Gauvin]

On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
> I want to know how many free space is left and have problems in
> interpreting the output of: 
> 
> btrfs filesystem usage
> btrfs filesystem df
> btrfs filesystem show
> 
>

In my not so humble opinion, the filesystem usage command has the
easiest to understand output.  It' lays out all the pertinent information.

You can clearly see 825GiB is allocated, with 494GiB used, therefore,
filesystem show is actually using the "Allocated" value as "Used".
Allocated can be thought of "Reserved For".  As the output of the Usage
command and df command clearly show, you have almost 400GiB space available.

Note that the btrfs commands are clearly and explicitly displaying
values in Binary units, (Mi, and Gi prefix, respectively).  If you want
df command to match, use -h instead of -H (see man df)

An observation:

The disparity between 498GiB used and 823Gib is pretty high.  This is
probably the result of using an SSD with an older kernel.  If your
kernel is not very recent, (sorry, I forget where this was fixed,
somewhere around 4.14 or 4.15), then consider mounting with the nossd
option.  You can improve this by running a balance.

Something like:
btrfs balance start -dusage=55

You do *not* want to end up with all your space allocated to Data, but
not actually used by data.  Bad things can happen if you run out of
Unallocated space for more metadata. (not catastrophic, but awkward and
unexpected downtime that can be a little tricky to sort out.)


<>

Re: Have 15GB missing in btrfs filesystem.

[Marc MERLIN]

On Sun, Oct 28, 2018 at 07:27:22AM +0800, Qu Wenruo wrote:
> > I can't drop all the snapshots since at least two is used for btrfs
> > send/receive backups.
> > However, if I delete more snapshots, and do a full balance, you think
> > it'll free up more space?
> 
> No.
> 
> You're already too worried about an non-existing problem.
> Your fs looks pretty healthy.

Thanks both for the answers. I'll go back and read them more carefully
later to see how I can adjust my monitoring but basically I hit the 90%
space used in df alert, and I know that once I get close to full, or
completely full, very bad things happen with btrfs, making the system
sometimes so unusable that it's very hard to reclaim space and fix the
issue (not counting that if you have btrfs send snapshots, you're forced
to break the snapshot relationship and start over since deleting data
does not reclaim blocks that are obviously still marked as used by the
last snapshot that was sent to the backup server).

Long story short, I try very hard to not ever hit this problem again :)

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

Re: Have 15GB missing in btrfs filesystem.

[Qu Wenruo]

On 2018/10/28 上午1:42, Marc MERLIN wrote:
> On Wed, Oct 24, 2018 at 01:07:25PM +0800, Qu Wenruo wrote:
>>> saruman:/mnt/btrfs_pool1# btrfs balance start -musage=80 -v .
>>> Dumping filters: flags 0x6, state 0x0, force is off
>>>   METADATA (flags 0x2): balancing, usage=80
>>>   SYSTEM (flags 0x2): balancing, usage=80
>>> Done, had to relocate 5 out of 202 chunks
>>> saruman:/mnt/btrfs_pool1# btrfs fi show .
>>> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>>> Total devices 1 FS bytes used 188.24GiB
>>> devid1 size 228.67GiB used 203.54GiB path /dev/mapper/pool1
>>>
>>> and it's back to 15GB :-/
>>>
>>> How can I get 188.24 and 203.54 to converge further? Where is all that
>>> space gone?
>>
>> Your original chunks are already pretty compact.
>> Thus really no need to do extra balance.
>>
>> You may get some extra space by doing full system balance (no usage=
>> filter), but that's really not worthy in my opinion.
>>
>> Maybe you could try defrag to free some space wasted by CoW instead?
>> (If you're not using many snapshots)
> 
> Thanks for the reply.
> 
> So right now, I have:
> saruman:~# btrfs fi show /mnt/btrfs_pool1/
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>   Total devices 1 FS bytes used 188.25GiB
>   devid1 size 228.67GiB used 203.54GiB path /dev/mapper/pool1

The fs is over 50G, so your metadata chunk will be allocated in 1G size.

> 
> saruman:~# btrfs fi df /mnt/btrfs_pool1/
> Data, single: total=192.48GiB, used=184.87GiB

Your data usage is over 96%, so your data chunks are already pretty compact.

In theory you could reach the minimal data usage 185G, but I think any
new data write would cause new data chunks to be created in that case.

To reclaim that 7.5G, you need to use -dusage filter other than your
-musage filter.
And your usage parameter may be pretty low.

> System, DUP: total=32.00MiB, used=48.00KiB
> Metadata, DUP: total=5.50GiB, used=3.38GiB

Metadata looks more sparse than data.

But considering your metadata chunks are allocated in 1G size and CoW
happens more frequently, it's not that easy to reclaim more space.

And even you succeeded relocating all these metadata chunks, you could
only reclaim at most 2~4G.

> GlobalReserve, single: total=512.00MiB, used=0.00B
> 
> I've been using btrfs for a long time now but I've never had a
> filesystem where I had 15GB apparently unusable (7%) after a balance.

You really don't need to worry, and that "15G" is not unusable.

It's will mostly likely to be used by data, and from your "fi df"
output, your data:metadata ratio is over 10, so it should be completely
fine.

> 
> I can't drop all the snapshots since at least two is used for btrfs
> send/receive backups.
> However, if I delete more snapshots, and do a full balance, you think
> it'll free up more space?

No.

You're already too worried about an non-existing problem.
Your fs looks pretty healthy.

Thanks,
Qu

> I can try a defrag next, but since I have COW for snapshots, it's not
> going to help much, correct?>
> Thanks,
> Marc
> 



signature.asc
Description: OpenPGP digital signature

Re: Have 15GB missing in btrfs filesystem.

[Remi Gauvin]

On 2018-10-27 04:19 PM, Marc MERLIN wrote:

> Thanks for confirming. Because I always have snapshots for btrfs
> send/receive, defrag will duplicate as you say, but once the older
> snapshots get freed up, the duplicate blocks should go away, correct?
> 
> Back to usage, thanks for pointing out that command:
> saruman:/mnt/btrfs_pool1# btrfs fi usage .
> Overall:
> Device size:   228.67GiB
> Device allocated:  203.54GiB
> Device unallocated: 25.13GiB
> Device missing:0.00B
> Used:  192.01GiB
> Free (estimated):   32.44GiB  (min: 19.88GiB)
> Data ratio: 1.00
> Metadata ratio: 2.00
> Global reserve:512.00MiB  (used: 0.00B)
> 
> Data,single: Size:192.48GiB, Used:185.16GiB
>/dev/mapper/pool1   192.48GiB
> 
> Metadata,DUP: Size:5.50GiB, Used:3.42GiB
>/dev/mapper/pool111.00GiB
> 
> System,DUP: Size:32.00MiB, Used:48.00KiB
>/dev/mapper/pool164.00MiB
> 
> Unallocated:
>/dev/mapper/pool125.13GiB
> 
> 
> I'm still seing that I'm using 192GB, but 203GB allocated.
> Do I have 25GB usable:
> Device unallocated: 25.13GiB
> 
> Or 35GB usable?
> Device size:   228.67GiB
>   -
> Used:192.01GiB
>   = 36GB ?
> 


The answer is somewhere between the two.  (BTRFS's estimate of 32.44
Free is probably as close as you'll get to predicting.)

So you have 7.32GB  allocated but still free space for data, and 25GB of
completely unallocated disk space. However, as you add more data, or
create more snapshots and create metadata duplication, some of that 25GB
will be allocated for Metadata.  Remember that Metadata is Duplicated
(so that 3.42GB of Metadata you are using now is actually using 6.84GB
of disk space, out of the allocated 11GB

You want to be careful that unallocated space doesn't run out.If the
system runs out of usable space for metadata, it can be tricky to get
yourself out of the corner.  That is why a large discrepency between
Data Size and Used would be a concern.  If those 25GB of space were
allocated to data, your would get out of space errors even if the 25GB
was still unused.

On that note, you seem to have a rather high metadata to data ratio..
(at least, compared to my limited experience.).  Are you using noatime
on your filesystems?  without it, snapshots will end up causing
duplicated metadata when atime updates.




<>

Re: Have 15GB missing in btrfs filesystem.

[Andrei Borzenkov]

27.10.2018 21:12, Remi Gauvin пишет:
> On 2018-10-27 01:42 PM, Marc MERLIN wrote:
> 
>>
>> I've been using btrfs for a long time now but I've never had a
>> filesystem where I had 15GB apparently unusable (7%) after a balance.
>>
> 
> The space isn't unusable.  It's just allocated.. (It's used in the sense
> that it's reserved for data chunks.).  Start writing data to the drive,
> and the data will fill that space before more gets allocated.. (Unless

No (at least, not necessarily).

On empty filesystem:

bor@10:~> df -h /mnt
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdb1  1023M   17M  656M   3% /mnt
bor@10:~> sudo dd if=/dev/zero of=/mnt/foo bs=100M count=1
1+0 records in
1+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.260088 s, 403 MB/s
bor@10:~> sync
bor@10:~> df -h /mnt
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdb1  1023M  117M  556M  18% /mnt
bor@10:~> sudo filefrag -v /mnt/foo
Filesystem type is: 9123683e
File size of /mnt/foo is 104857600 (25600 blocks of 4096 bytes)
 ext: logical_offset:physical_offset: length:   expected: flags:
   0:0..   14419:  36272.. 50691:  14420:
   1:14420..   25599: 125312..136491:  11180:  50692:
last,eof
/mnt/foo: 2 extents found
bor@10:~> sudo dd if=/dev/zero of=/mnt/foo bs=10M count=1 conv=notrunc
seek=2
1+0 records in
1+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.034 s, 350 MB/s
bor@10:~> sync
bor@10:~> df -h /mnt
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdb1  1023M  127M  546M  19% /mnt
bor@10:~> sudo filefrag -v /mnt/foo
Filesystem type is: 9123683e
File size of /mnt/foo is 104857600 (25600 blocks of 4096 bytes)
 ext: logical_offset:physical_offset: length:   expected: flags:
   0:0..5119:  36272.. 41391:   5120:
   1: 5120..7679:  33696.. 36255:   2560:  41392:
   2: 7680..   14419:  43952.. 50691:   6740:  36256:
   3:14420..   25599: 125312..136491:  11180:  50692:
last,eof
/mnt/foo: 4 extents found
bor@10:~> sudo dd if=/dev/zero of=/mnt/foo bs=10M count=1 conv=notrunc
seek=7
1+0 records in
1+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0314211 s, 334 MB/s
bor@10:~> sync
bor@10:~> df -h /mnt
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdb1  1023M  137M  536M  21% /mnt
bor@10:~> sudo filefrag -v /mnt/foo
Filesystem type is: 9123683e
File size of /mnt/foo is 104857600 (25600 blocks of 4096 bytes)
 ext: logical_offset:physical_offset: length:   expected: flags:
   0:0..5119:  36272.. 41391:   5120:
   1: 5120..7679:  33696.. 36255:   2560:  41392:
   2: 7680..   14419:  43952.. 50691:   6740:  36256:
   3:14420..   17919: 125312..128811:   3500:  50692:
   4:17920..   20479: 136492..139051:   2560: 128812:
   5:20480..   25599: 131372..136491:   5120: 139052:
last,eof
/mnt/foo: 6 extents found
bor@10:~> ll -sh /mnt
total 100M
100M -rw-r--r-- 1 root root 100M Oct 27 23:30 foo
bor@10:~>

So you still have the single file with size of 100M but space consumed
on filesystem is 120M because two initial large extents remain. Each
write of 10M will get new extent allocated, but large extents are not
split. If you look at file details

bor@10:~/python-btrfs/examples> sudo ./show_file.py /mnt/foo
filename /mnt/foo tree 5 inum 259
inode generation 239 transid 242 size 104857600 nbytes 104857600
block_group 0 mode 100644 nlink 1 uid 0 gid 0 rdev 0 flags 0x0(none)
inode ref list size 1
inode ref index 3 name utf-8 foo
extent data at 0 generation 239 ram_bytes 46563328 compression none type
regular disk_bytenr 148570112 disk_num_bytes 46563328 offset 0 num_bytes
20971520

This extent consumes about 44MB on disk but only 20MB of it is part of file.

extent data at 20971520 generation 241 ram_bytes 10485760 compression
none type regular disk_bytenr 138018816 disk_num_bytes 10485760 offset 0
num_bytes 10485760
extent data at 31457280 generation 239 ram_bytes 46563328 compression
none type regular disk_bytenr 148570112 disk_num_bytes 46563328 offset
31457280 num_bytes 15106048

And another 14MB. So 10MB allocated on disk are "lost".

extent data at 46563328 generation 239 ram_bytes 12500992 compression
none type regular disk_bytenr 195133440 disk_num_bytes 12500992 offset 0
num_bytes 12500992
extent data at 59064320 generation 239 ram_bytes 45793280 compression
none type regular disk_bytenr 513277952 disk_num_bytes 45793280 offset 0
num_bytes 14336000
extent data at 73400320 generation 242 ram_bytes 10485760 compression
none type regular disk_bytenr 559071232 disk_num_bytes 10485760 offset 0
num_bytes 10485760
extent data at 83886080 generation 239 ram_bytes 45793280 compression
none type regular disk_bytenr 513277952 disk_num_bytes 45793280 offset
24821760 num_bytes 20971520

Same here. 10MB in extent at 513277952 are lost.

There is no 

Re: Have 15GB missing in btrfs filesystem.

[Marc MERLIN]

On Sat, Oct 27, 2018 at 02:12:02PM -0400, Remi Gauvin wrote:
> On 2018-10-27 01:42 PM, Marc MERLIN wrote:
> 
> > 
> > I've been using btrfs for a long time now but I've never had a
> > filesystem where I had 15GB apparently unusable (7%) after a balance.
> > 
> 
> The space isn't unusable.  It's just allocated.. (It's used in the sense
> that it's reserved for data chunks.).  Start writing data to the drive,
> and the data will fill that space before more gets allocated.. (Unless
> you are using an older kernel and the filesystem gets mounted with ssd
> option, in which case, you'll want to add nossd option to prevent that
> behaviour.)
> 
> You can use btrfs fi usage to display that more clearly.
 
Got it. I have disk space free alerts based on df, which I know doesn't
mean that much on btrfs. Maybe I'll just need to change that alert code
to make it btrfs aware.
 
> > I can try a defrag next, but since I have COW for snapshots, it's not
> > going to help much, correct?
> 
> The defrag will end up using more space, as the fragmented parts of
> files will get duplicated.  That being said, if you have the luxury to
> defrag *before* taking new snapshots, that would be the time to do it.

Thanks for confirming. Because I always have snapshots for btrfs
send/receive, defrag will duplicate as you say, but once the older
snapshots get freed up, the duplicate blocks should go away, correct?

Back to usage, thanks for pointing out that command:
saruman:/mnt/btrfs_pool1# btrfs fi usage .
Overall:
Device size: 228.67GiB
Device allocated:203.54GiB
Device unallocated:   25.13GiB
Device missing:  0.00B
Used:192.01GiB
Free (estimated): 32.44GiB  (min: 19.88GiB)
Data ratio:   1.00
Metadata ratio:   2.00
Global reserve:  512.00MiB  (used: 0.00B)

Data,single: Size:192.48GiB, Used:185.16GiB
   /dev/mapper/pool1 192.48GiB

Metadata,DUP: Size:5.50GiB, Used:3.42GiB
   /dev/mapper/pool1  11.00GiB

System,DUP: Size:32.00MiB, Used:48.00KiB
   /dev/mapper/pool1  64.00MiB

Unallocated:
   /dev/mapper/pool1  25.13GiB


I'm still seing that I'm using 192GB, but 203GB allocated.
Do I have 25GB usable:
Device unallocated:   25.13GiB

Or 35GB usable?
Device size: 228.67GiB
  -
Used:192.01GiB
  = 36GB ?

Yes I know that I shouldn't get close to filling up the device, just
trying to clear up if I should stay below 25GB or below 35GB

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

Re: Have 15GB missing in btrfs filesystem.

[Remi Gauvin]

On 2018-10-27 01:42 PM, Marc MERLIN wrote:

> 
> I've been using btrfs for a long time now but I've never had a
> filesystem where I had 15GB apparently unusable (7%) after a balance.
> 

The space isn't unusable.  It's just allocated.. (It's used in the sense
that it's reserved for data chunks.).  Start writing data to the drive,
and the data will fill that space before more gets allocated.. (Unless
you are using an older kernel and the filesystem gets mounted with ssd
option, in which case, you'll want to add nossd option to prevent that
behaviour.)

You can use btrfs fi usage to display that more clearly.


> I can try a defrag next, but since I have COW for snapshots, it's not
> going to help much, correct?

The defrag will end up using more space, as the fragmented parts of
files will get duplicated.  That being said, if you have the luxury to
defrag *before* taking new snapshots, that would be the time to do it.

<>

Re: Have 15GB missing in btrfs filesystem.

[Marc MERLIN]

On Wed, Oct 24, 2018 at 01:07:25PM +0800, Qu Wenruo wrote:
> > saruman:/mnt/btrfs_pool1# btrfs balance start -musage=80 -v .
> > Dumping filters: flags 0x6, state 0x0, force is off
> >   METADATA (flags 0x2): balancing, usage=80
> >   SYSTEM (flags 0x2): balancing, usage=80
> > Done, had to relocate 5 out of 202 chunks
> > saruman:/mnt/btrfs_pool1# btrfs fi show .
> > Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
> > Total devices 1 FS bytes used 188.24GiB
> > devid1 size 228.67GiB used 203.54GiB path /dev/mapper/pool1
> > 
> > and it's back to 15GB :-/
> > 
> > How can I get 188.24 and 203.54 to converge further? Where is all that
> > space gone?
> 
> Your original chunks are already pretty compact.
> Thus really no need to do extra balance.
> 
> You may get some extra space by doing full system balance (no usage=
> filter), but that's really not worthy in my opinion.
> 
> Maybe you could try defrag to free some space wasted by CoW instead?
> (If you're not using many snapshots)

Thanks for the reply.

So right now, I have:
saruman:~# btrfs fi show /mnt/btrfs_pool1/
Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
Total devices 1 FS bytes used 188.25GiB
devid1 size 228.67GiB used 203.54GiB path /dev/mapper/pool1

saruman:~# btrfs fi df /mnt/btrfs_pool1/
Data, single: total=192.48GiB, used=184.87GiB
System, DUP: total=32.00MiB, used=48.00KiB
Metadata, DUP: total=5.50GiB, used=3.38GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

I've been using btrfs for a long time now but I've never had a
filesystem where I had 15GB apparently unusable (7%) after a balance.

I can't drop all the snapshots since at least two is used for btrfs
send/receive backups.
However, if I delete more snapshots, and do a full balance, you think
it'll free up more space?
I can try a defrag next, but since I have COW for snapshots, it's not
going to help much, correct?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

Re: Have 15GB missing in btrfs filesystem.

[Qu Wenruo]

On 2018/10/24 上午8:36, Marc MERLIN wrote:
> Normally when btrfs fi show will show lost space because 
> your trees aren't balanced.

Not always the case.

Btrfs uses two level allocation:
1) Chunk
   2 types, data, metadata, and system.

   And that's "used" space of "btrfs fi show", or "Device allocated" of
   "btrfs fi usage"

2) Extent
   2 types, data and metadata.

   And that's "used" space of "btrfs fi df"

A metadata extent can only get allocated from a metadata chunk
(or a system chunk, but system chunks are pretty small).
A data extent can only get allocated from data chunk.

Balance can only solve the case where an near empty metadata chunk can't
be freed since it's still used by some metadata extents, or similar case
for data chunks.

It can't really magically reclaim free space from void.


From your description, I don't think it's the case.

> Balance usually reclaims that space, or most of it.
> In this case, not so much.
> 
> kernel 4.17.6:
> 
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>   Total devices 1 FS bytes used 186.89GiB
>   devid1 size 228.67GiB used 207.60GiB path /dev/mapper/pool1
> 
> Ok, I have 21GB between used by FS and used in block layer.
> 
> saruman:/mnt/btrfs_pool1# btrfs balance start -dusage=40 -v .
> Dumping filters: flags 0x1, state 0x0, force is off
>   DATA (flags 0x2): balancing, usage=40
> Done, had to relocate 1 out of 210 chunks
> saruman:/mnt/btrfs_pool1# btrfs balance start -musage=60 -v .
> Dumping filters: flags 0x6, state 0x0, force is off
>   METADATA (flags 0x2): balancing, usage=60
>   SYSTEM (flags 0x2): balancing, usage=60
> Done, had to relocate 4 out of 209 chunks
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>   Total devices 1 FS bytes used 186.91GiB
>   devid1 size 228.67GiB used 205.60GiB path /dev/mapper/pool1
> 
> That didn't help much, delta is now 19GB
> 
> saruman:/mnt/btrfs_pool1# btrfs balance start -dusage=80 -v .
> Dumping filters: flags 0x1, state 0x0, force is off
>   DATA (flags 0x2): balancing, usage=80
> Done, had to relocate 8 out of 207 chunks
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>   Total devices 1 FS bytes used 187.03GiB
>   devid1 size 228.67GiB used 201.54GiB path /dev/mapper/pool1
> 
> Ok, now delta is 14GB
> 
> saruman:/mnt/btrfs_pool1# btrfs balance start -musage=80 -v .
> Dumping filters: flags 0x6, state 0x0, force is off
>   METADATA (flags 0x2): balancing, usage=80
>   SYSTEM (flags 0x2): balancing, usage=80
> Done, had to relocate 5 out of 202 chunks
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>   Total devices 1 FS bytes used 188.24GiB
>   devid1 size 228.67GiB used 203.54GiB path /dev/mapper/pool1
> 
> and it's back to 15GB :-/
> 
> How can I get 188.24 and 203.54 to converge further? Where is all that
> space gone?

Your original chunks are already pretty compact.
Thus really no need to do extra balance.

You may get some extra space by doing full system balance (no usage=
filter), but that's really not worthy in my opinion.

Maybe you could try defrag to free some space wasted by CoW instead?
(If you're not using many snapshots)

Thanks,
Qu

> 
> Thanks,
> Marc
> 



signature.asc
Description: OpenPGP digital signature

Re: Have 15GB missing in btrfs filesystem.

[Andrei Borzenkov]

24.10.2018 3:36, Marc MERLIN пишет:
> Normally when btrfs fi show will show lost space because 
> your trees aren't balanced.
> Balance usually reclaims that space, or most of it.
> In this case, not so much.
> 
> kernel 4.17.6:
> 
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>   Total devices 1 FS bytes used 186.89GiB
>   devid1 size 228.67GiB used 207.60GiB path /dev/mapper/pool1
> 
> Ok, I have 21GB between used by FS and used in block layer.
> 
> saruman:/mnt/btrfs_pool1# btrfs balance start -dusage=40 -v .
> Dumping filters: flags 0x1, state 0x0, force is off
>   DATA (flags 0x2): balancing, usage=40
> Done, had to relocate 1 out of 210 chunks
> saruman:/mnt/btrfs_pool1# btrfs balance start -musage=60 -v .
> Dumping filters: flags 0x6, state 0x0, force is off
>   METADATA (flags 0x2): balancing, usage=60
>   SYSTEM (flags 0x2): balancing, usage=60
> Done, had to relocate 4 out of 209 chunks
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>   Total devices 1 FS bytes used 186.91GiB
>   devid1 size 228.67GiB used 205.60GiB path /dev/mapper/pool1
> 
> That didn't help much, delta is now 19GB
> 
> saruman:/mnt/btrfs_pool1# btrfs balance start -dusage=80 -v .
> Dumping filters: flags 0x1, state 0x0, force is off
>   DATA (flags 0x2): balancing, usage=80
> Done, had to relocate 8 out of 207 chunks
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>   Total devices 1 FS bytes used 187.03GiB
>   devid1 size 228.67GiB used 201.54GiB path /dev/mapper/pool1
> 
> Ok, now delta is 14GB
> 
> saruman:/mnt/btrfs_pool1# btrfs balance start -musage=80 -v .
> Dumping filters: flags 0x6, state 0x0, force is off
>   METADATA (flags 0x2): balancing, usage=80
>   SYSTEM (flags 0x2): balancing, usage=80
> Done, had to relocate 5 out of 202 chunks
> saruman:/mnt/btrfs_pool1# btrfs fi show .
> Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
>   Total devices 1 FS bytes used 188.24GiB
>   devid1 size 228.67GiB used 203.54GiB path /dev/mapper/pool1
> 
> and it's back to 15GB :-/
> 
> How can I get 188.24 and 203.54 to converge further? Where is all that
> space gone?
> 

Most likely this is due to partially used extents which has been
explained more than once on this list. When large extent is partially
overwritten, extent is not physically split - it remains allocated in
full but only part of it is referenced. Balance does not change it (at
least that is my understanding) - it moves extents, but here we have
internal fragmentation inside of extent. Defragmentation should rewrite
files, but if you have snapshots, it is unclear if there will be any gain.

I wonder if there is any tool that can compute physical vs. logical
space consumption (i.e. how much space in extent is actually
referenced). Should be possible using python-btrfs but probably time
consuming as it needs to walk each extent.

Have 15GB missing in btrfs filesystem.

[Marc MERLIN]

Normally when btrfs fi show will show lost space because 
your trees aren't balanced.
Balance usually reclaims that space, or most of it.
In this case, not so much.

kernel 4.17.6:

saruman:/mnt/btrfs_pool1# btrfs fi show .
Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
Total devices 1 FS bytes used 186.89GiB
devid1 size 228.67GiB used 207.60GiB path /dev/mapper/pool1

Ok, I have 21GB between used by FS and used in block layer.

saruman:/mnt/btrfs_pool1# btrfs balance start -dusage=40 -v .
Dumping filters: flags 0x1, state 0x0, force is off
  DATA (flags 0x2): balancing, usage=40
Done, had to relocate 1 out of 210 chunks
saruman:/mnt/btrfs_pool1# btrfs balance start -musage=60 -v .
Dumping filters: flags 0x6, state 0x0, force is off
  METADATA (flags 0x2): balancing, usage=60
  SYSTEM (flags 0x2): balancing, usage=60
Done, had to relocate 4 out of 209 chunks
saruman:/mnt/btrfs_pool1# btrfs fi show .
Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
Total devices 1 FS bytes used 186.91GiB
devid1 size 228.67GiB used 205.60GiB path /dev/mapper/pool1

That didn't help much, delta is now 19GB

saruman:/mnt/btrfs_pool1# btrfs balance start -dusage=80 -v .
Dumping filters: flags 0x1, state 0x0, force is off
  DATA (flags 0x2): balancing, usage=80
Done, had to relocate 8 out of 207 chunks
saruman:/mnt/btrfs_pool1# btrfs fi show .
Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
Total devices 1 FS bytes used 187.03GiB
devid1 size 228.67GiB used 201.54GiB path /dev/mapper/pool1

Ok, now delta is 14GB

saruman:/mnt/btrfs_pool1# btrfs balance start -musage=80 -v .
Dumping filters: flags 0x6, state 0x0, force is off
  METADATA (flags 0x2): balancing, usage=80
  SYSTEM (flags 0x2): balancing, usage=80
Done, had to relocate 5 out of 202 chunks
saruman:/mnt/btrfs_pool1# btrfs fi show .
Label: 'btrfs_pool1'  uuid: fda628bc-1ca4-49c5-91c2-4260fe967a23
Total devices 1 FS bytes used 188.24GiB
devid1 size 228.67GiB used 203.54GiB path /dev/mapper/pool1

and it's back to 15GB :-/

How can I get 188.24 and 203.54 to converge further? Where is all that
space gone?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

Re: Interpreting `btrfs filesystem show'

[Martin Steigerwald]

Hugo Mills - 15.10.18, 16:26:
> On Mon, Oct 15, 2018 at 05:24:08PM +0300, Anton Shepelev wrote:
> > Hello, all
> > 
> > While trying to resolve free space problems, and found that
> > 
> > I cannot interpret the output of:
> > > btrfs filesystem show
> > 
> > Label: none  uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
> > Total devices 1 FS bytes used 34.06GiB
> > devid1 size 40.00GiB used 37.82GiB path /dev/sda2
> > 
> > How come the total used value is less than the value listed
> > for the only device?
> 
>"Used" on the device is the mount of space allocated. "Used" on the
> FS is the total amount of actual data and metadata in that
> allocation.
> 
>You will also need to look at the output of "btrfs fi df" to see
> the breakdown of the 37.82 GiB into data, metadata and currently
> unused.

I usually use btrfs fi usage -T, cause

1. It has all the information.

2. It differentiates between used and allocated.

% btrfs fi usage -T /
Overall:
Device size: 100.00GiB
Device allocated: 54.06GiB
Device unallocated:   45.94GiB
Device missing:  0.00B
Used: 46.24GiB
Free (estimated): 25.58GiB  (min: 25.58GiB)
Data ratio:   2.00
Metadata ratio:   2.00
Global reserve:   70.91MiB  (used: 0.00B)

Data Metadata  System  
Id Path RAID1RAID1 RAID1Unallocated
--   -  ---
 2 /dev/mapper/msata-debian 25.00GiB   2.00GiB 32.00MiB22.97GiB
 1 /dev/mapper/sata-debian  25.00GiB   2.00GiB 32.00MiB22.97GiB
--   -  ---
   Total25.00GiB   2.00GiB 32.00MiB45.94GiB
   Used 22.38GiB 754.66MiB 16.00KiB  


For RAID it in some place reports the raw size and sometimes the logical 
size. Especially in the "Total" line I find this a bit inconsistent. 
"RAID1" columns show logical size, "Unallocated" shows raw size.

Also "Used:" in the global section shows raw size and "Free 
(estimated):" shows logical size.

Thanks
-- 
Martin

Re: Interpreting `btrfs filesystem show'

[Austin S. Hemmelgarn]

On 2018-10-15 10:42, Anton Shepelev wrote:

Hugo Mills to Anton Shepelev:


While trying to resolve free space problems, and found
that I cannot interpret the output of:


btrfs filesystem show


Label: none  uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
Total devices 1 FS bytes used 34.06GiB
devid1 size 40.00GiB used 37.82GiB path /dev/sda2

How come the total used value is less than the value
listed for the only device?


   "Used" on the device is the mount of space allocated.
"Used" on the FS is the total amount of actual data and
metadata in that allocation.

   You will also need to look at the output of "btrfs fi
df" to see the breakdown of the 37.82 GiB into data,
metadata and currently unused.

See
https://btrfs.wiki.kernel.org/index.php/FAQ#Understanding_free_space.2C_using_the_original_tools
 for the details


Thank you, Hugo, understood.  mount/amount is a very fitting
typo :-)

Does the standard `du' tool work correctly for btfrfs?

For the default 'physical usage' mode, it functionally does not work 
correctly, because it does not know about reflinks.  The easiest way to 
see this is to create a couple of snapshots of a subvolume alongside the 
subvolume, and then run `du -s --totals` on those snapshots and the 
subvolume.  It will report the total space usage to be equal to the sum 
of the values reported for each snapshot and the subvolume, when it 
should instead only count the space usage for shared data once.


For the 'apparent usage' mode provided by the GNU implementation, it 
does work correctly.

Re: Interpreting `btrfs filesystem show'

[Hugo Mills]

On Mon, Oct 15, 2018 at 05:40:40PM +0300, Anton Shepelev wrote:
> Hugo Mills to Anton Shepelev:
> 
> >>While trying to resolve free space problems, and found
> >>that I cannot interpret the output of:
> >>
> >>> btrfs filesystem show
> >>
> >>Label: none  uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
> >>Total devices 1 FS bytes used 34.06GiB
> >>devid1 size 40.00GiB used 37.82GiB path /dev/sda2
> >>
> >>How come the total used value is less than the value
> >>listed for the only device?
> >
> >   "Used" on the device is the mount of space allocated.
> >"Used" on the FS is the total amount of actual data and
> >metadata in that allocation.
> >
> >   You will also need to look at the output of "btrfs fi
> >df" to see the breakdown of the 37.82 GiB into data,
> >metadata and currently unused.
> >
> >See
> >https://btrfs.wiki.kernel.org/index.php/FAQ#Understanding_free_space.2C_using_the_original_tools
> > for the details
> 
> Thank you, Hugo, understood.  mount/amount is a very fitting
> typo :-)
> 
> Do the standard `du' and `du' tools report correct values
> with btrfs?

   Well...

   du will tell you the size of the files you asked it about, but it
doesn't know about reflinks, so it'll double-count if you've got a
reflink copy of something. Other than that, it should be accurate, I
think. There's also a "btrfs fi du" which can tell you the amount of
shared and unique data as well, so you can know, for example, how much
space you'll reclaim if you delete those files.

   df should be mostly OK, but it does sometimes get its estimate of
the total usable size of the FS wrong, particularly if the FS is
unbalanced. However, as the FS fills up, the estimate gets better,
because it gets more evenly balanced across devices over time.

   Hugo.

-- 
Hugo Mills | "Your problem is that you have a negative
hugo@... carfax.org.uk | personality."
http://carfax.org.uk/  | "No, I don't!"
PGP: E2AB1DE4  |  Londo and Vir, Babylon 5


signature.asc
Description: Digital signature

Re: Interpreting `btrfs filesystem show'

[Anton Shepelev]

Hugo Mills to Anton Shepelev:

>>While trying to resolve free space problems, and found
>>that I cannot interpret the output of:
>>
>>> btrfs filesystem show
>>
>>Label: none  uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
>>Total devices 1 FS bytes used 34.06GiB
>>devid1 size 40.00GiB used 37.82GiB path /dev/sda2
>>
>>How come the total used value is less than the value
>>listed for the only device?
>
>   "Used" on the device is the mount of space allocated.
>"Used" on the FS is the total amount of actual data and
>metadata in that allocation.
>
>   You will also need to look at the output of "btrfs fi
>df" to see the breakdown of the 37.82 GiB into data,
>metadata and currently unused.
>
>See
>https://btrfs.wiki.kernel.org/index.php/FAQ#Understanding_free_space.2C_using_the_original_tools
> for the details

Thank you, Hugo, understood.  mount/amount is a very fitting
typo :-)

Does the standard `du' tool work correctly for btfrfs?

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

Re: Interpreting `btrfs filesystem show'

[Hugo Mills]

On Mon, Oct 15, 2018 at 02:26:41PM +, Hugo Mills wrote:
> On Mon, Oct 15, 2018 at 05:24:08PM +0300, Anton Shepelev wrote:
> > Hello, all
> > 
> > While trying to resolve free space problems, and found that
> > I cannot interpret the output of:
> > 
> > > btrfs filesystem show
> > 
> > Label: none  uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
> > Total devices 1 FS bytes used 34.06GiB
> > devid1 size 40.00GiB used 37.82GiB path /dev/sda2
> > 
> > How come the total used value is less than the value listed
> > for the only device?
> 
>"Used" on the device is the mount of space allocated. "Used" on the

s/mount/amount/

> FS is the total amount of actual data and metadata in that allocation.
> 
>You will also need to look at the output of "btrfs fi df" to see
> the breakdown of the 37.82 GiB into data, metadata and currently
> unused.
> 
>See 
> https://btrfs.wiki.kernel.org/index.php/FAQ#Understanding_free_space.2C_using_the_original_tools
>  for the details.
> 
>Hugo.
> 

-- 
Hugo Mills | "Your problem is that you have a negative
hugo@... carfax.org.uk | personality."
http://carfax.org.uk/  | "No, I don't!"
PGP: E2AB1DE4  |  Londo and Vir, Babylon 5


signature.asc
Description: Digital signature

Re: Interpreting `btrfs filesystem show'

[Hugo Mills]

On Mon, Oct 15, 2018 at 05:24:08PM +0300, Anton Shepelev wrote:
> Hello, all
> 
> While trying to resolve free space problems, and found that
> I cannot interpret the output of:
> 
> > btrfs filesystem show
> 
> Label: none  uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
> Total devices 1 FS bytes used 34.06GiB
> devid1 size 40.00GiB used 37.82GiB path /dev/sda2
> 
> How come the total used value is less than the value listed
> for the only device?

   "Used" on the device is the mount of space allocated. "Used" on the
FS is the total amount of actual data and metadata in that allocation.

   You will also need to look at the output of "btrfs fi df" to see
the breakdown of the 37.82 GiB into data, metadata and currently
unused.

   See 
https://btrfs.wiki.kernel.org/index.php/FAQ#Understanding_free_space.2C_using_the_original_tools
 for the details.

   Hugo.

-- 
Hugo Mills | "Your problem is that you have a negative
hugo@... carfax.org.uk | personality."
http://carfax.org.uk/  | "No, I don't!"
PGP: E2AB1DE4  |  Londo and Vir, Babylon 5


signature.asc
Description: Digital signature

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[evan d]

Thanks for looking at it for me, appreciate the input.
On Sun, Oct 7, 2018 at 2:25 PM evan d  wrote:
>
> > > I may as well use wipefs to clear crud from both drives, partition and
> > > format them and then use them elsewhere.   -- this more or less
> > > accurately summarise the situation?
> >
> > Unfortunately, yes.
>
>
> I recall the machine these drives were in lost the onboard NIC when
> the desktop switch it was connected to went up in smoke.  Perhaps it
> was at that point the corruption occurred, albeit I seem to recall
> checking the drives at the time.  Such is life.  If they pass extended
> SMART tests they'll go back into use.

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[evan d]

> > I may as well use wipefs to clear crud from both drives, partition and
> > format them and then use them elsewhere.   -- this more or less
> > accurately summarise the situation?
>
> Unfortunately, yes.


I recall the machine these drives were in lost the onboard NIC when
the desktop switch it was connected to went up in smoke.  Perhaps it
was at that point the corruption occurred, albeit I seem to recall
checking the drives at the time.  Such is life.  If they pass extended
SMART tests they'll go back into use.

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[Qu Wenruo]

On 2018/10/7 下午6:39, evan d wrote:
>>> like so?:
>>> grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" /dev/sdc
>>>
>> Yes. And it will be very slow, since you're going to read out the whole
>> disk.
>>
>> But I don't really think you would get some hit, according to current
>> result.
> 
> Ok, so it is what it is.  Based on what you're telling me, whilst the
> data may be there and intact, the superblock is irretrievably damaged
> and the data is thus for all intents and purposes lost.

Although the result is the same (data all lost), but I don't believe
it's only super block corrupted.
If you have some special magic string, like "#!/bin/bash" or "\x7f\x45
\x4c\x46\x02\x01\x01\x00" (elf header) , you could try to grep through
the whole disk.

I believe the data (or at least part of the data) is also corrupted in
this case.

> 
> I may as well use wipefs to clear crud from both drives, partition and
> format them and then use them elsewhere.   -- this more or less
> accurately summarise the situation?

Unfortunately, yes.

Thanks,
Qu

> 



signature.asc
Description: OpenPGP digital signature

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[evan d]

> > like so?:
> > grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" /dev/sdc
> >
> Yes. And it will be very slow, since you're going to read out the whole
> disk.
>
> But I don't really think you would get some hit, according to current
> result.

Ok, so it is what it is.  Based on what you're telling me, whilst the
data may be there and intact, the superblock is irretrievably damaged
and the data is thus for all intents and purposes lost.

I may as well use wipefs to clear crud from both drives, partition and
format them and then use them elsewhere.   -- this more or less
accurately summarise the situation?

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[Qu Wenruo]

On 2018/10/7 下午4:28, evan d wrote:
 # dd if=/dev/sdb bs=1M of=last_chance.raw count=128 skip=256M
 # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" last_chance.raw
> 
> grep returns no result on either drive
> 
> If still no hit, you could try just run the grep command on the disk.
> 
> like so?:
> grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" /dev/sdc
> 
Yes. And it will be very slow, since you're going to read out the whole
disk.

But I don't really think you would get some hit, according to current
result.

Thanks,
Qu



signature.asc
Description: OpenPGP digital signature

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[evan d]

> >> # dd if=/dev/sdb bs=1M of=last_chance.raw count=128 skip=256M
> >> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" last_chance.raw

grep returns no result on either drive

 If still no hit, you could try just run the grep command on the disk.

like so?:
grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" /dev/sdc

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[Qu Wenruo]

On 2018/10/7 下午4:09, evan d wrote:
>> If first 128M doesn't hit, I highly doubt something more strange happened.
> 
> Not sure I follow, do you mean if it doesn't hit then it's likely
> something else went wrong?

Yes.

If it's just a simple offset, it should hit.
If it's some simple corruption like bit rot, it shouldn't cause all
super blocks to be corrupted so seriously.

> 
> 
>> I'm considering something like encryption.
>> Maybe the disk is already encrypted by hardware?
> 
> The drives were never encrypted, none of my drives are
> 
> 
>> Windows is just a black box, I have no idea what a Windows could do to a
>> disk.
>>
>> But it doesn't explain why the 2nd super block can't be located, unless
>> Windows is wipe more data than the first 128M.
> 
> I'm thinking Windows may have tried to convert them to Dynamic disk on
> detecting them and assuming they're empty.

If that's the case, and sharing with Windows can't be avoided, then next
time please use partition table (GPT/MBR) other than raw disks.

> 
>>
>> If the disk is larger than 256G, would you please try to locate the last
>> possible super at 256G?
> 
> They're both 6TB drives
> 
>>
>> # dd if=/dev/sdb bs=1M of=last_chance.raw count=128 skip=256M
>> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" last_chance.raw
> 
> dd returns:
> dd: /dev/sdb: cannot skip: Invalid argument

My fault, skip should be 256K not 256M.

Thanks,
Qu

> 



signature.asc
Description: OpenPGP digital signature

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[evan d]

> If first 128M doesn't hit, I highly doubt something more strange happened.

Not sure I follow, do you mean if it doesn't hit then it's likely
something else went wrong?


> I'm considering something like encryption.
> Maybe the disk is already encrypted by hardware?

The drives were never encrypted, none of my drives are


> Windows is just a black box, I have no idea what a Windows could do to a
> disk.
>
> But it doesn't explain why the 2nd super block can't be located, unless
> Windows is wipe more data than the first 128M.

I'm thinking Windows may have tried to convert them to Dynamic disk on
detecting them and assuming they're empty.

>
> If the disk is larger than 256G, would you please try to locate the last
> possible super at 256G?

They're both 6TB drives

>
> # dd if=/dev/sdb bs=1M of=last_chance.raw count=128 skip=256M
> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" last_chance.raw

dd returns:
dd: /dev/sdb: cannot skip: Invalid argument

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[Qu Wenruo]

On 2018/10/7 下午2:47, evan d wrote:
>> None of your super blocks has correct magic.
> 
> 
> I take it this applies to both drives?

Yes, both drivers have something wrong.

> 
> 
> 
>> This means either your whole disk get corrupted, or something introduced
>> some offset.
>>
>> Please try the following commands to dump more data around super blocks,
>> so we could be able to find the possible offset:
>>
>> # dd if=/dev/sdb of=possible_sb_range.raw bs=1M count=128
>> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" possible_sb_range.
>>
>> For a valid btrfs without any offset, the result should look like:
>> 65600:_BHRfS_M
>> 67108928:_BHRfS_M
> 
> # dd if=/dev/sdc of=possible_sb_range.sdc.raw bs=1M count=128
> 128+0 records in
> 128+0 records out
> 134217728 bytes (134 MB, 128 MiB) copied, 0.737479 s, 182 MB/s
> 
> # dd if=/dev/sdb of=possible_sb_range.sdb.raw bs=1M count=128
> 128+0 records in
> 128+0 records out
> 134217728 bytes (134 MB, 128 MiB) copied, 0.726327 s, 185 MB/s
> 
> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" possible_sb_range.sdb.raw
> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" possible_sb_range.sdc.raw
> 
> Both return nothing.

Then this is not good at all.

The super blocks should be at 64K and 64M.
If first 128M doesn't hit, I highly doubt something more strange happened.

> 
> Both drives pass S.M.A.R.T. testing so I'd have to think the
> corruption stems from some kind of offset rather than random
> corruption.

Corruption shouldn't happen like this.

And offset shouldn't be so large to offset the whole 128M range.

I'm considering something like encryption.
Maybe the disk is already encrypted by hardware?

>  They may have accidentally been inserted into a Windows
> machine (but not partitioned or formatted).  Could this be a likely
> cause?

Windows is just a black box, I have no idea what a Windows could do to a
disk.

But it doesn't explain why the 2nd super block can't be located, unless
Windows is wipe more data than the first 128M.

If the disk is larger than 256G, would you please try to locate the last
possible super at 256G?

# dd if=/dev/sdb bs=1M of=last_chance.raw count=128 skip=256M
# grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" last_chance.raw

If still no hit, you could try just run the grep command on the disk.
It would take a long long time reading all data from the disk.

If still no hit, it means definitely not some easy offset.

Thanks,
Qu
> 



signature.asc
Description: OpenPGP digital signature

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[evan d]

> None of your super blocks has correct magic.


I take it this applies to both drives?



> This means either your whole disk get corrupted, or something introduced
> some offset.
>
> Please try the following commands to dump more data around super blocks,
> so we could be able to find the possible offset:
>
> # dd if=/dev/sdb of=possible_sb_range.raw bs=1M count=128
> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" possible_sb_range.
>
> For a valid btrfs without any offset, the result should look like:
> 65600:_BHRfS_M
> 67108928:_BHRfS_M

# dd if=/dev/sdc of=possible_sb_range.sdc.raw bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 0.737479 s, 182 MB/s

# dd if=/dev/sdb of=possible_sb_range.sdb.raw bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 0.726327 s, 185 MB/s

# grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" possible_sb_range.sdb.raw
# grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" possible_sb_range.sdc.raw

Both return nothing.

Both drives pass S.M.A.R.T. testing so I'd have to think the
corruption stems from some kind of offset rather than random
corruption.  They may have accidentally been inserted into a Windows
machine (but not partitioned or formatted).  Could this be a likely
cause?

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[Qu Wenruo]

On 2018/10/7 下午2:10, evan d wrote:
>> Please try "btrfs ins dump-super -fFa" on these two disks.
>>
>> If it's only the primary superblock corrupted, the backup should be good.
>>
>> If backup is also corrupted, either it has some offset or the whole data
>> is corrupted.
> 
> # btrfs ins dump-super -fFa /dev/sdb
> superblock: bytenr=65536, device=/dev/sdb
> -
> csum_type 0 (crc32c)
> csum_size 4
> csum 0x [DON'T MATCH]
> bytenr 0
> flags 0x0
> magic  [DON'T MATCH]
[snip]
> superblock: bytenr=274877906944, device=/dev/sdb
> -
> csum_type 26294 (INVALID)
> csum_size 32
> csum 0x05401fa3a3e8cd64075ce9fdbb9e60a01d58061a3cff3bc0235d18912ab755a2
> [UNKNOWN CSUM TYPE OR SIZE]
> bytenr 7401042280310172376
> flags 0x5a8a759265673a05
> ( WRITTEN |
>   METADUMP |
>   unknown flag: 0x5a8a759065673a04 )
> magic .~...6.. [DON'T MATCH]
[snip]

None of your super blocks has correct magic.

This means either your whole disk get corrupted, or something introduced
some offset.

Please try the following commands to dump more data around super blocks,
so we could be able to find the possible offset:

# dd if=/dev/sdb of=possible_sb_range.raw bs=1M count=128
# grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" possible_sb_range.

For a valid btrfs without any offset, the result should look like:
65600:_BHRfS_M
67108928:_BHRfS_M

If your result doesn't look like this but still has two similar hits,
then you could calculate the offset, and use dm-linear to remap the disk
and try to recover the fs.

Thanks,
Qu



signature.asc
Description: OpenPGP digital signature

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[evan d]

> Please try "btrfs ins dump-super -fFa" on these two disks.
>
> If it's only the primary superblock corrupted, the backup should be good.
>
> If backup is also corrupted, either it has some offset or the whole data
> is corrupted.

# btrfs ins dump-super -fFa /dev/sdb
superblock: bytenr=65536, device=/dev/sdb
-
csum_type 0 (crc32c)
csum_size 4
csum 0x [DON'T MATCH]
bytenr 0
flags 0x0
magic  [DON'T MATCH]
fsid ----
label
generation 0
root 0
sys_array_size 0
chunk_root_generation 0
root_level 0
chunk_root 0
chunk_root_level 0
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 0
bytes_used 0
sectorsize 0
nodesize 0
leafsize (deprecated) 0
stripesize 0
root_dir 0
num_devices 0
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x0
cache_generation 0
uuid_tree_generation 0
dev_item.uuid ----
dev_item.fsid ---- [match]
dev_item.type 0
dev_item.total_bytes 0
dev_item.bytes_used 0
dev_item.io_align 0
dev_item.io_width 0
dev_item.sector_size 0
dev_item.devid 0
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
sys_chunk_array[2048]:
backup_roots[4]:

superblock: bytenr=67108864, device=/dev/sdb
-
csum_type 29777 (INVALID)
csum_size 32
csum 0xdfa25558dc616d7f36b287aa0081da91b78ec4910ba082b8d807708dcf608c91
[UNKNOWN CSUM TYPE OR SIZE]
bytenr 18068171547813619898
flags 0xbaca4264c914fdc
( METADUMP |
  METADUMP_V2 |
  unknown flag: 0xbaca4204c914fdc )
magic Y...FE./ [DON'T MATCH]
fsid 870d0bb4-65de-453b-2592-88b2cda7c38b
label 
>.<...@...B%...<.N..S.*.>^.p.x.v..o..<).u..B}./...B..3:8..&}-k...o6..Y..R..'o..G.lG.-...$'S!.h.-...".*.S..xf..@d...W..*..w..V.)..q..|.pgt.L...z.i...(..3Ar...;B.j.]:I.X...=x.(u.<..2U..0
.n..^}...^..Y.a#.X...G..d..
generation 2272432616352171010
root 6354703493070726827
sys_array_size 2955003080
chunk_root_generation 6888771666932949452
root_level 123
chunk_root 1494381076279922822
chunk_root_level 127
log_root 2134514170013133221
log_root_transid 9424889336279151653
log_root_level 153
total_bytes 2681859058010843869
bytes_used 16135710043447639801
sectorsize 1588161000
nodesize 3303803296
leafsize (deprecated) 1829755703
stripesize 606246139
root_dir 1342036912498050847
num_devices 17153780124435501376
compat_flags 0xf49b2c3a96602d1e
compat_ro_flags 0x8bec2f0d81d2ef13
( FREE_SPACE_TREE |
  FREE_SPACE_TREE_VALID |
  unknown flag: 0x8bec2f0d81d2ef10 )
incompat_flags 0x1af3f95d789a706e
( DEFAULT_SUBVOL |
  MIXED_GROUPS |
  COMPRESS_LZO |
  BIG_METADATA |
  EXTENDED_IREF |
  unknown flag: 0x1af3f95d789a7000 )
cache_generation 733155394646473
uuid_tree_generation 6538806993670512709
dev_item.uuid c1494bde-9546-5ef1-5d08-e259707d06d3
dev_item.fsid 584a42f5-4f79-58cc-3f5e-bdd9733b94d3 [DON'T MATCH]
dev_item.type 15668929679594826040
dev_item.total_bytes 1644623768791993611
dev_item.bytes_used 13437937382560806996
dev_item.io_align 449600477
dev_item.io_width 3390996026
dev_item.sector_size 2580293710
dev_item.devid 8727228223548828735
dev_item.dev_group 3143108434
dev_item.seek_speed 99
dev_item.bandwidth 34
dev_item.generation 15553054142077970558
sys_chunk_array[2048]:
ERROR: sys_array_size 2955003080 shouldn't exceed 2048 bytes
backup_roots[4]:
backup 0:
backup_tree_root: 15696464816120474628 gen: 16022257131800929882 level: 86
backup_chunk_root: 301766055038840723 gen: 16810756911197712753 level: 114
backup_extent_root: 6651488794176833875 gen: 10776594467847637718 level: 60
backup_fs_root: 1826104903792017114 gen: 3329223824114931446 level: 159
backup_dev_root: 11721506207622158585 gen: 10455859429120851009 level: 198
backup_csum_root: 5686172936498246011 gen: 5319088827707453088 level: 168
backup_total_bytes: 7660601670332883006
backup_bytes_used: 3723313713264611767
backup_num_devices: 1913069816786984281

backup 1:
backup_tree_root: 9129110729577497674 gen: 17870813394716935947 level: 45
backup_chunk_root: 3169491491968745044 gen: 17348548561480407615 level: 93
backup_extent_root: 5781159137873655776 gen: 3348348558872496210 level: 123
backup_fs_root: 66326293521237128 gen: 16098559310782853786 level: 157
backup_dev_root: 10010186234695580749 gen: 5427645709246451749 level: 214
backup_csum_root: 3481616510852897026 gen: 3557794445033232028 level: 233
backup_total_bytes: 14437518517144737363
backup_bytes_used: 17463569409584801738
backup_num_devices: 3997309709667846939

backup 2:
backup_tree_root: 10726132636215357139 gen: 12411364641008183307 level: 88
backup_chunk_root: 15701704192942804973 gen: 12075216484835399161 level: 115
backup_extent_root: 2480766121519302854 gen: 14058965640461957484 level: 149
backup_fs_root: 9763730962528489871 gen: 7584542795525942005 level: 178
backup_dev_root: 11165845436133270817 gen: 13967062440412348994 level: 236
backup_csum_root: 

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[evan d]

> Did you try a btrfs device scan  ?

Tried it, it returns nothing.

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[Qu Wenruo]

On 2018/10/7 上午7:23, evan d wrote:
> I have two hard drives that were never partitioned, but set up as two
> independent BRTFS filesystems.  Both drives were used in the same
> machine running Arch Linux and the drives contain(ed) largely static
> data.
> 
> I decommissioned the machine they were originally used in and on
> installing in a newer Arch build found that BRTFS reported no
> filesystem on either of the drives.

Please try "btrfs ins dump-super -fFa" on these two disks.

If it's only the primary superblock corrupted, the backup should be good.

If backup is also corrupted, either it has some offset or the whole data
is corrupted.

Thanks,
Qu

> 
> uname -a:
> Linux z87i-pro 4.18.9-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 19 21:19:17
> UTC 2018 x86_64 GNU/Linux
> 
> btrfs --version: btrfs-progs v4.17.1
> btrfs fi show: returns no data
> 
> parted -l:
> Error: /dev/sdb: unrecognised disk label
> Model: ATA WDC WD60EFRX-68M (scsi)
> Disk /dev/sdb: 6001GB
> Sector size (logical/physical): 512B/4096B
> Partition Table: unknown
> Disk Flags:
> 
> gdisk /dev/sdb - l:
> Error: /dev/sdc: unrecognised disk label
> Model: ATA WDC WD60EFRX-68M (scsi)
> Disk /dev/sdc: 6001GB
> Sector size (logical/physical): 512B/4096B
> Partition Table: unknown
> Disk Flags:
> 
> gdisk /dev/sdb -l
> GPT fdisk (gdisk) version 1.0.4
> 
> Caution: invalid main GPT header, but valid backup; regenerating main header
> from backup!
> 
> Caution! After loading partitions, the CRC doesn't check out!
> Warning: Invalid CRC on main header data; loaded backup partition table.
> Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
> on the recovery & transformation menu to examine the two tables.
> 
> Warning! One or more CRCs don't match. You should repair the disk!
> Main header: ERROR
> Backup header: OK
> Main partition table: ERROR
> Backup partition table: ERROR
> 
> Partition table scan:
>   MBR: protective
>   BSD: not present
>   APM: not present
>   GPT: damaged
> 
> 
> Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
> verification and recovery are STRONGLY recommended.
> 
> Warning! Main partition table overlaps the first partition by 33 blocks!
> You will need to delete this partition or resize it in another utility.
> Disk /dev/sdb: 11721045168 sectors, 5.5 TiB
> Model: WDC WD60EFRX-68M
> Sector size (logical/physical): 512/4096 bytes
> Disk identifier (GUID): FB26D91F-0709-11E7-B298-3464A99AF244
> Partition table holds up to 128 entries
> Main partition table begins at sector 2 and ends at sector 33
> First usable sector is 34, last usable sector is 11721045134
> Partitions will be aligned on 8-sector boundaries
> Total free space is 11721045101 sectors (5.5 TiB)
> 
> Number  Start (sector)End (sector)  Size   Code  Name
>   69   1   6   3.0 KiB   犀읭퇸䵧羒⌦盤䧔Ẑ坔
> 
> gdisk /dev/sdc -l:
> GPT fdisk (gdisk) version 1.0.4
> 
> Caution: invalid main GPT header, but valid backup; regenerating main header
> from backup!
> 
> Caution! After loading partitions, the CRC doesn't check out!
> Warning: Invalid CRC on main header data; loaded backup partition table.
> Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
> on the recovery & transformation menu to examine the two tables.
> 
> Warning! One or more CRCs don't match. You should repair the disk!
> Main header: ERROR
> Backup header: OK
> Main partition table: ERROR
> Backup partition table: ERROR
> 
> Partition table scan:
>   MBR: protective
>   BSD: not present
>   APM: not present
>   GPT: damaged
> 
> 
> Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
> verification and recovery are STRONGLY recommended.
> 
> Warning! Main partition table overlaps the first partition by 33 blocks!
> You will need to delete this partition or resize it in another utility.
> Disk /dev/sdc: 11721045168 sectors, 5.5 TiB
> Model: WDC WD60EFRX-68M
> Sector size (logical/physical): 512/4096 bytes
> Disk identifier (GUID): FC86A481-0709-11E7-B298-3464A99AF244
> Partition table holds up to 128 entries
> Main partition table begins at sector 2 and ends at sector 33
> First usable sector is 34, last usable sector is 11721045134
> Partitions will be aligned on 8-sector boundaries
> Total free space is 11721045101 sectors (5.5 TiB)
> 
> Number  Start (sector)End (sector)  Size   Code  Name
>   69   1   6   3.0 KiB   윜㺗ᣲ䌟犔熵䕭㶖Ẑ坔
> 
> 
> Any ideas what's happened here seeing as both drives appear to suffer
> the same symptoms and what I can do to attempt a recovery?
> 



signature.asc
Description: OpenPGP digital signature

Re: Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[Remi Gauvin]

On 2018-10-06 07:23 PM, evan d wrote:
> I have two hard drives that were never partitioned, but set up as two
> independent BRTFS filesystems.  Both drives were used in the same
> machine running Arch Linux and the drives contain(ed) largely static
> data.
> 
> I decommissioned the machine they were originally used in and on
> installing in a newer Arch build found that BRTFS reported no
> filesystem on either of the drives.
> 
> uname -a:
> Linux z87i-pro 4.18.9-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 19 21:19:17
> UTC 2018 x86_64 GNU/Linux
> 
> btrfs --version: btrfs-progs v4.17.1
> btrfs fi show: returns no data

Did you try a btrfs device scan  ?

(Normally, that would be done on boot, but depending on how your arch
was configured, or if the devices are available early enough in the boot
process)
<>

Two partitionless BTRFS drives no longer seen as containing BTRFS filesystem

[evan d]

I have two hard drives that were never partitioned, but set up as two
independent BRTFS filesystems.  Both drives were used in the same
machine running Arch Linux and the drives contain(ed) largely static
data.

I decommissioned the machine they were originally used in and on
installing in a newer Arch build found that BRTFS reported no
filesystem on either of the drives.

uname -a:
Linux z87i-pro 4.18.9-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 19 21:19:17
UTC 2018 x86_64 GNU/Linux

btrfs --version: btrfs-progs v4.17.1
btrfs fi show: returns no data

parted -l:
Error: /dev/sdb: unrecognised disk label
Model: ATA WDC WD60EFRX-68M (scsi)
Disk /dev/sdb: 6001GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:

gdisk /dev/sdb - l:
Error: /dev/sdc: unrecognised disk label
Model: ATA WDC WD60EFRX-68M (scsi)
Disk /dev/sdc: 6001GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:

gdisk /dev/sdb -l
GPT fdisk (gdisk) version 1.0.4

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Caution! After loading partitions, the CRC doesn't check out!
Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged


Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.

Warning! Main partition table overlaps the first partition by 33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sdb: 11721045168 sectors, 5.5 TiB
Model: WDC WD60EFRX-68M
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): FB26D91F-0709-11E7-B298-3464A99AF244
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 11721045134
Partitions will be aligned on 8-sector boundaries
Total free space is 11721045101 sectors (5.5 TiB)

Number  Start (sector)End (sector)  Size   Code  Name
  69   1   6   3.0 KiB   犀읭퇸䵧羒⌦盤䧔Ẑ坔

gdisk /dev/sdc -l:
GPT fdisk (gdisk) version 1.0.4

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Caution! After loading partitions, the CRC doesn't check out!
Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged


Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.

Warning! Main partition table overlaps the first partition by 33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sdc: 11721045168 sectors, 5.5 TiB
Model: WDC WD60EFRX-68M
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): FC86A481-0709-11E7-B298-3464A99AF244
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 11721045134
Partitions will be aligned on 8-sector boundaries
Total free space is 11721045101 sectors (5.5 TiB)

Number  Start (sector)End (sector)  Size   Code  Name
  69   1   6   3.0 KiB   윜㺗ᣲ䌟犔熵䕭㶖Ẑ坔


Any ideas what's happened here seeing as both drives appear to suffer
the same symptoms and what I can do to attempt a recovery?
[0.00] microcode: microcode updated early to revision 0x25, date = 2018-04-02
[0.00] Linux version 4.18.9-arch1-1-ARCH (builduser@heftig-19946) (gcc version 8.2.1 20180831 (GCC)) #1 SMP PREEMPT Wed Sep 19 21:19:17 UTC 2018
[0.00] Command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img root=PARTUUID=7f3a7108-c5bc-40dd-856c-dea1ae6ef2a3 rw
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Supporting XSAVE feature 

[PATCH 9/9] btrfs: Add RAID 6 recovery for a btrfs filesystem.

[Goffredo Baroncelli]

From: Goffredo Baroncelli 

Add the RAID 6 recovery, in order to use a RAID 6 filesystem even if some
disks (up to two) are missing. This code use the md RAID 6 code already
present in grub.

Signed-off-by: Goffredo Baroncelli 
---
 grub-core/fs/btrfs.c | 63 +++-
 1 file changed, 57 insertions(+), 6 deletions(-)

diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index db8df0eea..b49f714ef 100644
--- a/grub-core/fs/btrfs.c
+++ b/grub-core/fs/btrfs.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 GRUB_MOD_LICENSE ("GPLv3+");
 
@@ -702,11 +703,36 @@ rebuild_raid5 (char *dest, struct raid56_buffer *buffers,
 }
 }
 
+static grub_err_t
+raid6_recover_read_buffer (void *data, int disk_nr,
+  grub_uint64_t addr __attribute__ ((unused)),
+  void *dest, grub_size_t size)
+{
+struct raid56_buffer *buffers = data;
+
+if (!buffers[disk_nr].data_is_valid)
+   return grub_errno = GRUB_ERR_READ_ERROR;
+
+grub_memcpy(dest, buffers[disk_nr].buf, size);
+
+return grub_errno = GRUB_ERR_NONE;
+}
+
+static void
+rebuild_raid6 (struct raid56_buffer *buffers, grub_uint64_t nstripes,
+   grub_uint64_t csize, grub_uint64_t parities_pos, void *dest,
+   grub_uint64_t stripen)
+
+{
+  grub_raid6_recover_gen (buffers, nstripes, stripen, parities_pos,
+  dest, 0, csize, 0, raid6_recover_read_buffer);
+}
+
 static grub_err_t
 raid56_read_retry (struct grub_btrfs_data *data,
   struct grub_btrfs_chunk_item *chunk,
-  grub_uint64_t stripe_offset,
-  grub_uint64_t csize, void *buf)
+  grub_uint64_t stripe_offset, grub_uint64_t stripen,
+  grub_uint64_t csize, void *buf, grub_uint64_t parities_pos)
 {
   struct raid56_buffer *buffers;
   grub_uint64_t nstripes = grub_le_to_cpu16 (chunk->nstripes);
@@ -777,6 +803,15 @@ raid56_read_retry (struct grub_btrfs_data *data,
   ret = GRUB_ERR_READ_ERROR;
   goto cleanup;
 }
+  else if (failed_devices > 2 && (chunk_type & GRUB_BTRFS_CHUNK_TYPE_RAID6))
+{
+  grub_dprintf ("btrfs",
+   "not enough disks for raid6: total %" PRIuGRUB_UINT64_T
+   ", missing %" PRIuGRUB_UINT64_T "\n",
+   nstripes, failed_devices);
+  ret = GRUB_ERR_READ_ERROR;
+  goto cleanup;
+}
   else
 grub_dprintf ("btrfs",
  "enough disks for RAID 5 rebuilding: total %"
@@ -787,7 +822,7 @@ raid56_read_retry (struct grub_btrfs_data *data,
   if (chunk_type & GRUB_BTRFS_CHUNK_TYPE_RAID5)
 rebuild_raid5 (buf, buffers, nstripes, csize);
   else
-grub_dprintf ("btrfs", "called rebuild_raid6(), NOT IMPLEMENTED\n");
+rebuild_raid6 (buffers, nstripes, csize, parities_pos, buf, stripen);
 
   ret = GRUB_ERR_NONE;
  cleanup:
@@ -877,9 +912,11 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data, 
grub_disk_addr_t addr,
unsigned redundancy = 1;
unsigned i, j;
int is_raid56;
+   grub_uint64_t parities_pos = 0;
 
-   is_raid56 = !!(grub_le_to_cpu64 (chunk->type) &
-  GRUB_BTRFS_CHUNK_TYPE_RAID5);
+is_raid56 = !!(grub_le_to_cpu64 (chunk->type) &
+  (GRUB_BTRFS_CHUNK_TYPE_RAID5 |
+   GRUB_BTRFS_CHUNK_TYPE_RAID6));
 
if (grub_le_to_cpu64 (chunk->size) <= off)
  {
@@ -1011,6 +1048,9 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data, 
grub_disk_addr_t addr,
   *size if the latter is smaller.
   *  - nparities is the number of parities (1 for RAID5, 2 for
   *RAID6); used only in RAID5/6 code.
+  *size if the latter is smaller.
+  *  - parities_pos is the position of the parity in a row (
+  *2 for P1, 3 for P2...)
   */
  stripe_nr = grub_divmod64 (off, chunk_stripe_length, );
 
@@ -1029,6 +1069,17 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data, 
grub_disk_addr_t addr,
   */
  grub_divmod64 (high + stripen, nstripes, );
 
+ /*
+  * parities_pos is equal to "(high - nparities) % nstripes"
+  * (see the diagram above).
+  * However "high - nparities" might be negative (eg when high
+  * == 0) leading to an incorrect computation.
+  * Instead "high + nstripes - nparities" is always positive and
+  * in modulo nstripes is equal to "(high - nparities) % nstripes"
+  */
+ grub_divmod64 (high + nstripes - nparities, nstripes,
+_pos);
+
  stripe_offset = low + chunk_stripe_length * high;
  csize = chunk_stripe_length - low;
 
@@ -1080,7 +1131,7 @@ grub_btrfs_read_logical (struct grub_btrfs_data *data, 
grub_disk_addr_t addr,
grub_errno = 

Re: [PATCH 9/9] btrfs: Add RAID 6 recovery for a btrfs filesystem.

[Daniel Kiper]

On Wed, Sep 26, 2018 at 09:56:07PM +0200, Goffredo Baroncelli wrote:
> On 25/09/2018 21.20, Daniel Kiper wrote:
> > On Wed, Sep 19, 2018 at 08:40:40PM +0200, Goffredo Baroncelli wrote:
> >> From: Goffredo Baroncelli 
> >>
> []
> >>   *  - stripe_offset is the disk offset,
> >>   *  - csize is the "potential" data to read. It will be reduced to
> >>   *size if the latter is smaller.
> >> + *  - parities_pos is the position of the parity inside a row (
> >
> > s/inside/in/>
> >> + *2 for P1, 3 for P2...)
>
> +  *  - nparities is the number of parities (1 for RAID5, 2 for 
> RAID6);
> +  *used only in RAID5/6 code.
>
> >>   */
> >>  block_nr = grub_divmod64 (off, chunk_stripe_length, );
> >>
> >> @@ -1030,6 +1069,9 @@ grub_btrfs_read_logical (struct grub_btrfs_data 
> >> *data, grub_disk_addr_t addr,
> >>   */
> >>  grub_divmod64 (high + stripen, nstripes, );
> >>
> >> +grub_divmod64 (high + nstripes - nparities, nstripes,
> >> +   _pos);
> >
> > I think that this math requires a bit of explanation in the comment
> > before grub_divmod64(). Especially I am interested in why high +
> > nstripes - nparities works as expected.
>
>
> What about
>
> /*
>  * parities_pos is equal to "(high - nparities) % nstripes" (see the diagram 
> above).
>  * However "high - nparities" might be negative (eg when high == 0) leading 
> to an
>  * incorrect computation.
>  * Instead "high + nstripes - nparities" is always positive and in modulo 
> nstripes is
>  * equal to "(high - nparities) % nstripes
>  */

LGTM.

Daniel

Re: trouble mounting btrfs filesystem....

[Hans van Kranenburg]

On 08/14/2018 07:09 PM, Andrei Borzenkov wrote:
> 14.08.2018 18:16, Hans van Kranenburg пишет:
>> On 08/14/2018 03:00 PM, Dmitrii Tcvetkov wrote:
 Scott E. Blomquist writes:
  > Hi All,
  > 
  > [...]
>>>
>>> I'm not a dev, just user.
>>> btrfs-zero-log is for very specific case[1], not for transid errors.
>>> Transid errors mean that some metadata writes are missing, if
>>> they prevent you from mounting filesystem it's pretty much fatal. If
>>> btrfs could recover metadata from good copy it'd have done that.
>>>
>>> "wanted 2159304 found 2159295" means that some metadata is stale by 
>>> 9 commits. You could try to mount it with "ro,usebackuproot" mount
>>> options as readonly mount is less strict. If that works you can try
>>> "usebackuproot" without ro option. But 9 commits is probably too much
>>> and there isn't enough data to rollback so far.
>>
>> Keep in mind that a successful mount with usebackuproot does not mean
>> you're looking at a consistent filesystem. After each transaction
>> commit, disk space that is no longer referenced is immediately freed for
>> reuse.
>>
> 
> With all respect - in this case btrfs should not even pretend it can do
> "usebackuproot". What this option is for then?

I have no idea. As the Dutch say: "schiet mij maar in de kerstboom". The
commit that introduces it contains no explanation at all.

The only thing I can think of is when you're a developer and writing
buggy code that writes out corrupted tree root blocks, which makes the
filesystem crash in some way directly after a transaction ends while no
other new writes are done again yet, combined with getting fed up of
having to mkfs and put your testdata back all the time.

>> So, even if you can mount with usebackuproot, you have to hope that none
>> of the metadata blocks that were used back then have been overwritten
>> already, even the ones in distant corners of trees. A full check / scrub
>> / etc would be needed to find out.

-- 
Hans van Kranenburg

Re: trouble mounting btrfs filesystem....

[Roman Mamedov]

On Tue, 14 Aug 2018 16:41:11 +0300
Dmitrii Tcvetkov  wrote:

> If usebackuproot doesn't help then filesystem is beyond repair and you
> should try to refresh your backups with "btrfs restore" and restore from 
> them[1].
> 
> [1] 
> https://btrfs.wiki.kernel.org/index.php/FAQ#How_do_I_recover_from_a_.22parent_transid_verify_failed.22_error.3F

This is really the worst unfixed Btrfs issue today. This happens a lot on
unclean shutdowns or reboots, and the only advice is usually to "start over"
-- even if your FS is 40 TB and the discrepancy is just by half a dozen
transids. There needs to be a way in fsck to accept (likely minor!) FS damage
and forcefully fixup transids to what they should be -- or even nuke the
affected portions entirely.

-- 
With respect,
Roman

Re: trouble mounting btrfs filesystem....

[Andrei Borzenkov]

14.08.2018 18:16, Hans van Kranenburg пишет:
> On 08/14/2018 03:00 PM, Dmitrii Tcvetkov wrote:
>>> Scott E. Blomquist writes:
>>>  > Hi All,
>>>  > 
>>>  > [...]
>>
>> I'm not a dev, just user.
>> btrfs-zero-log is for very specific case[1], not for transid errors.
>> Transid errors mean that some metadata writes are missing, if
>> they prevent you from mounting filesystem it's pretty much fatal. If
>> btrfs could recover metadata from good copy it'd have done that.
>>
>> "wanted 2159304 found 2159295" means that some metadata is stale by 
>> 9 commits. You could try to mount it with "ro,usebackuproot" mount
>> options as readonly mount is less strict. If that works you can try
>> "usebackuproot" without ro option. But 9 commits is probably too much
>> and there isn't enough data to rollback so far.
> 
> Keep in mind that a successful mount with usebackuproot does not mean
> you're looking at a consistent filesystem. After each transaction
> commit, disk space that is no longer referenced is immediately freed for
> reuse.
> 

With all respect - in this case btrfs should not even pretend it can do
"usebackuproot". What this option is for then?

> So, even if you can mount with usebackuproot, you have to hope that none
> of the metadata blocks that were used back then have been overwritten
> already, even the ones in distant corners of trees. A full check / scrub
> / etc would be needed to find out.
> 

Re: trouble mounting btrfs filesystem....

[Hans van Kranenburg]

On 08/14/2018 03:00 PM, Dmitrii Tcvetkov wrote:
>> Scott E. Blomquist writes:
>>  > Hi All,
>>  > 
>>  > [...]
> 
> I'm not a dev, just user.
> btrfs-zero-log is for very specific case[1], not for transid errors.
> Transid errors mean that some metadata writes are missing, if
> they prevent you from mounting filesystem it's pretty much fatal. If
> btrfs could recover metadata from good copy it'd have done that.
> 
> "wanted 2159304 found 2159295" means that some metadata is stale by 
> 9 commits. You could try to mount it with "ro,usebackuproot" mount
> options as readonly mount is less strict. If that works you can try
> "usebackuproot" without ro option. But 9 commits is probably too much
> and there isn't enough data to rollback so far.

Keep in mind that a successful mount with usebackuproot does not mean
you're looking at a consistent filesystem. After each transaction
commit, disk space that is no longer referenced is immediately freed for
reuse.

So, even if you can mount with usebackuproot, you have to hope that none
of the metadata blocks that were used back then have been overwritten
already, even the ones in distant corners of trees. A full check / scrub
/ etc would be needed to find out.

-- 
Hans van Kranenburg

Re: trouble mounting btrfs filesystem....

[Hans van Kranenburg]

On 08/12/2018 09:19 PM, Scott E. Blomquist wrote:
> 
> Hi All,
> 
> Early this morning there was a power glitch that affected our system.
> 
> The second enclosure went offline but the file system stayed up for a
> bit before rebooting and recovering the 2 missing arrays sdb1 and
> sdc1.
> 
> When mounting we get
> 
> Aug 12 14:52:43 localhost kernel: [ 8536.649270] BTRFS info (device 
> sda1): has skinny extents
> Aug 12 14:54:52 localhost kernel: [ 8665.900321] BTRFS error (device 
> sda1): parent transid verify failed on 177443463479296 wanted 2159304 found 
> 2159295
> Aug 12 14:54:52 localhost kernel: [ 8665.985512] BTRFS error (device 
> sda1): parent transid verify failed on 177443463479296 wanted 2159304 found 
> 2159295
> Aug 12 14:54:52 localhost kernel: [ 8666.056845] BTRFS error (device 
> sda1): failed to read block groups: -5
> Aug 12 14:54:52 localhost kernel: [ 8666.254178] BTRFS error (device 
> sda1): open_ctree failed
> 
> We are here...
> 
> # uname -a
> Linux localhost 4.17.14-custom #1 SMP Sun Aug 12 11:54:00 EDT 2018 x86_64 
> x86_64 x86_64 GNU/Linux
> 
> # btrfs --version
> btrfs-progs v4.17.1
> 
> # btrfs filesystem show
> Label: none  uuid: 8337c837-58cb-430a-a929-7f6d2f50bdbb
> Total devices 3 FS bytes used 75.05TiB
> devid1 size 47.30TiB used 42.07TiB path /dev/sda1
> devid2 size 21.83TiB used 16.61TiB path /dev/sdb1
> devid3 size 21.83TiB used 16.61TiB path /dev/sdc1

What kind of devices are this? You say enclosure... is it a bunch of
disks doing its own RAID, with btrfs on top?

Do you have RAID1 metadata on top of that, or single?

At least if you go the mkfs route (I read the other replies) then also
find out what happened. If your storage is losing data in situations
like this while it told btrfs that the data was safe, you're running a
dangerous operation.

-- 
Hans van Kranenburg

Re: trouble mounting btrfs filesystem....

[Scott E. Blomquist]

Dmitrii Tcvetkov writes:
 > On Tue, 14 Aug 2018 09:31:56 -0400
 > "Scott E. Blomquist"  wrote:
 > 
 > > Dmitrii Tcvetkov writes:
 > >  > > Scott E. Blomquist writes:  
 > >  > >  > Hi All,
 > >  > >  > 
 > >  > >  > Early this morning there was a power glitch that affected our
 > >  > >  > system.
 > >  > >  > 
 > >  > >  > The second enclosure went offline but the file system stayed
 > >  > >  > up for a bit before rebooting and recovering the 2 missing
 > >  > >  > arrays sdb1 and sdc1.
 > >  > >  > 
 > >  > >  > When mounting we get
 > >  > >  > 
 > >  > >  > Aug 12 14:52:43 localhost kernel: [ 8536.649270] BTRFS
 > >  > >  > info (device sda1): has skinny extents Aug 12 14:54:52
 > >  > >  > localhost kernel: [ 8665.900321] BTRFS error (device sda1):
 > >  > >  > parent transid verify failed on 177443463479296 wanted
 > >  > >  > 2159304 found 2159295 Aug 12 14:54:52 localhost kernel:
 > >  > >  > [ 8665.985512] BTRFS error (device sda1): parent transid
 > >  > >  > verify failed on 177443463479296 wanted 2159304 found 2159295
 > >  > >  > Aug 12 14:54:52 localhost kernel: [ 8666.056845] BTRFS error
 > >  > >  > (device sda1): failed to read block groups: -5 Aug 12
 > >  > >  > 14:54:52 localhost kernel: [ 8666.254178] BTRFS error (device
 > >  > >  > sda1): open_ctree failed
 > >  > >  > 
 > >  > >  > We are here...
 > >  > >  > 
 > >  > >  > # uname -a
 > >  > >  > Linux localhost 4.17.14-custom #1 SMP Sun Aug 12 11:54:00
 > >  > >  > EDT 2018 x86_64 x86_64 x86_64 GNU/Linux
 > >  > >  > 
 > >  > >  > # btrfs --version
 > >  > >  > btrfs-progs v4.17.1
 > >  > >  > 
 > >  > >  > # btrfs filesystem show
 > >  > >  > Label: none  uuid: 8337c837-58cb-430a-a929-7f6d2f50bdbb
 > >  > >  > Total devices 3 FS bytes used 75.05TiB
 > >  > >  > devid1 size 47.30TiB used 42.07TiB
 > >  > >  > path /dev/sda1 devid2 size 21.83TiB used 16.61TiB
 > >  > >  > path /dev/sdb1 devid3 size 21.83TiB used 16.61TiB
 > >  > >  > path /dev/sdc1 
 > >  > >  > Thanks for any help.
 > >  > >  > 
 > >  > >  > sb. Scott Blomquist
 > >  > > Hi All,
 > >  > > 
 > >  > > Is there any more info needed here?
 > >  > > 
 > >  > > I can restore from backup if needed but that will take a bit of
 > >  > > time.
 > >  > > 
 > >  > > Checking around it looks like I could try...
 > >  > > 
 > >  > > btrfs-zero-log /dev/sda1
 > >  > > 
 > >  > > Or maybe ..
 > >  > > 
 > >  > >btrfsck --repair /dev/sda1
 > >  > > 
 > >  > > I am just not sure here and would prefer to do the right thing.
 > >  > > 
 > >  > > Any help would be much appreciated.
 > >  > > 
 > >  > > Thanks,
 > >  > > 
 > >  > > sb. Scott Blomquist
 > >  > > 
 > >  > >   
 > >  > 
 > >  > I'm not a dev, just user.
 > >  > btrfs-zero-log is for very specific case[1], not for transid
 > >  > errors. Transid errors mean that some metadata writes are missing,
 > >  > if they prevent you from mounting filesystem it's pretty much
 > >  > fatal. If btrfs could recover metadata from good copy it'd have
 > >  > done that.
 > >  > 
 > >  > "wanted 2159304 found 2159295" means that some metadata is stale
 > >  > by 9 commits. You could try to mount it with "ro,usebackuproot"
 > >  > mount options as readonly mount is less strict. If that works you
 > >  > can try "usebackuproot" without ro option. But 9 commits is
 > >  > probably too much and there isn't enough data to rollback so far.
 > >  > 
 > >  > [1] https://btrfs.wiki.kernel.org/index.php/Btrfs-zero-log  
 > > 
 > > Thank you.  So zero-log is not the right thing...
 > > 
 > > Unfortunately when mounting ro,usebackuproot I still get the same
 > > messages...
 > > 
 > > Aug 14 09:08:15 localhost kernel: [160669.100314] BTRFS info
 > > (device sda1): trying to use backup root at mount time Aug 14

Re: trouble mounting btrfs filesystem....

[Dmitrii Tcvetkov]

> Scott E. Blomquist writes:
>  > Hi All,
>  > 
>  > Early this morning there was a power glitch that affected our
>  > system.
>  > 
>  > The second enclosure went offline but the file system stayed up
>  > for a bit before rebooting and recovering the 2 missing arrays
>  > sdb1 and sdc1.
>  > 
>  > When mounting we get
>  > 
>  > Aug 12 14:52:43 localhost kernel: [ 8536.649270] BTRFS info
>  > (device sda1): has skinny extents Aug 12 14:54:52 localhost
>  > kernel: [ 8665.900321] BTRFS error (device sda1): parent transid
>  > verify failed on 177443463479296 wanted 2159304 found 2159295 Aug
>  > 12 14:54:52 localhost kernel: [ 8665.985512] BTRFS error (device
>  > sda1): parent transid verify failed on 177443463479296 wanted
>  > 2159304 found 2159295 Aug 12 14:54:52 localhost kernel:
>  > [ 8666.056845] BTRFS error (device sda1): failed to read block
>  > groups: -5 Aug 12 14:54:52 localhost kernel: [ 8666.254178] BTRFS
>  > error (device sda1): open_ctree failed
>  > 
>  > We are here...
>  > 
>  > # uname -a
>  > Linux localhost 4.17.14-custom #1 SMP Sun Aug 12 11:54:00 EDT
>  > 2018 x86_64 x86_64 x86_64 GNU/Linux
>  > 
>  > # btrfs --version
>  > btrfs-progs v4.17.1
>  > 
>  > # btrfs filesystem show
>  > Label: none  uuid: 8337c837-58cb-430a-a929-7f6d2f50bdbb
>  > Total devices 3 FS bytes used 75.05TiB
>  > devid1 size 47.30TiB used 42.07TiB path /dev/sda1
>  > devid2 size 21.83TiB used 16.61TiB path /dev/sdb1
>  > devid3 size 21.83TiB used 16.61TiB path /dev/sdc1
>  > 
>  > Thanks for any help.
>  > 
>  > sb. Scott Blomquist  
> Hi All,
> 
> Is there any more info needed here?
> 
> I can restore from backup if needed but that will take a bit of time.
> 
> Checking around it looks like I could try...
> 
> btrfs-zero-log /dev/sda1
> 
> Or maybe ..
> 
>btrfsck --repair /dev/sda1
> 
> I am just not sure here and would prefer to do the right thing.
> 
> Any help would be much appreciated.
> 
> Thanks,
> 
> sb. Scott Blomquist
> 
> 

I'm not a dev, just user.
btrfs-zero-log is for very specific case[1], not for transid errors.
Transid errors mean that some metadata writes are missing, if
they prevent you from mounting filesystem it's pretty much fatal. If
btrfs could recover metadata from good copy it'd have done that.

"wanted 2159304 found 2159295" means that some metadata is stale by 
9 commits. You could try to mount it with "ro,usebackuproot" mount
options as readonly mount is less strict. If that works you can try
"usebackuproot" without ro option. But 9 commits is probably too much
and there isn't enough data to rollback so far.

[1] https://btrfs.wiki.kernel.org/index.php/Btrfs-zero-log

Re: trouble mounting btrfs filesystem....

[Scott E. Blomquist]

Hi All,

Is there any more info needed here?

I can restore from backup if needed but that will take a bit of time.

Checking around it looks like I could try...

btrfs-zero-log /dev/sda1

Or maybe ..

   btrfsck --repair /dev/sda1

I am just not sure here and would prefer to do the right thing.

Any help would be much appreciated.

Thanks,

sb. Scott Blomquist


Scott E. Blomquist writes:
 > Hi All,
 > 
 > Early this morning there was a power glitch that affected our system.
 > 
 > The second enclosure went offline but the file system stayed up for a
 > bit before rebooting and recovering the 2 missing arrays sdb1 and
 > sdc1.
 > 
 > When mounting we get
 > 
 > Aug 12 14:52:43 localhost kernel: [ 8536.649270] BTRFS info (device 
 > sda1): has skinny extents
 > Aug 12 14:54:52 localhost kernel: [ 8665.900321] BTRFS error (device 
 > sda1): parent transid verify failed on 177443463479296 wanted 2159304 found 
 > 2159295
 > Aug 12 14:54:52 localhost kernel: [ 8665.985512] BTRFS error (device 
 > sda1): parent transid verify failed on 177443463479296 wanted 2159304 found 
 > 2159295
 > Aug 12 14:54:52 localhost kernel: [ 8666.056845] BTRFS error (device 
 > sda1): failed to read block groups: -5
 > Aug 12 14:54:52 localhost kernel: [ 8666.254178] BTRFS error (device 
 > sda1): open_ctree failed
 > 
 > We are here...
 > 
 > # uname -a
 > Linux localhost 4.17.14-custom #1 SMP Sun Aug 12 11:54:00 EDT 2018 
 > x86_64 x86_64 x86_64 GNU/Linux
 > 
 > # btrfs --version
 > btrfs-progs v4.17.1
 > 
 > # btrfs filesystem show
 > Label: none  uuid: 8337c837-58cb-430a-a929-7f6d2f50bdbb
 > Total devices 3 FS bytes used 75.05TiB
 > devid1 size 47.30TiB used 42.07TiB path /dev/sda1
 > devid2 size 21.83TiB used 16.61TiB path /dev/sdb1
 > devid3 size 21.83TiB used 16.61TiB path /dev/sdc1
 > 
 > Thanks for any help.
 > 
 > sb. Scott Blomquist

trouble mounting btrfs filesystem....

[Scott E. Blomquist]

Hi All,

Early this morning there was a power glitch that affected our system.

The second enclosure went offline but the file system stayed up for a
bit before rebooting and recovering the 2 missing arrays sdb1 and
sdc1.

When mounting we get

Aug 12 14:52:43 localhost kernel: [ 8536.649270] BTRFS info (device sda1): 
has skinny extents
Aug 12 14:54:52 localhost kernel: [ 8665.900321] BTRFS error (device sda1): 
parent transid verify failed on 177443463479296 wanted 2159304 found 2159295
Aug 12 14:54:52 localhost kernel: [ 8665.985512] BTRFS error (device sda1): 
parent transid verify failed on 177443463479296 wanted 2159304 found 2159295
Aug 12 14:54:52 localhost kernel: [ 8666.056845] BTRFS error (device sda1): 
failed to read block groups: -5
Aug 12 14:54:52 localhost kernel: [ 8666.254178] BTRFS error (device sda1): 
open_ctree failed

We are here...

# uname -a
Linux localhost 4.17.14-custom #1 SMP Sun Aug 12 11:54:00 EDT 2018 x86_64 
x86_64 x86_64 GNU/Linux

# btrfs --version
btrfs-progs v4.17.1

# btrfs filesystem show
Label: none  uuid: 8337c837-58cb-430a-a929-7f6d2f50bdbb
Total devices 3 FS bytes used 75.05TiB
devid1 size 47.30TiB used 42.07TiB path /dev/sda1
devid2 size 21.83TiB used 16.61TiB path /dev/sdb1
devid3 size 21.83TiB used 16.61TiB path /dev/sdc1

Thanks for any help.

sb. Scott Blomquist

Re: Crash when unraring large archives on btrfs-filesystem

[Stefan Malte Schumacher]

> How much RAM on the machine and how much swap available? This looks like a
> lot of dirty data has accumulated, and then also there's swapping happening.
> Both swap out and swap in.

The machine has 16GB Ram and 40GB Swap on a SSD. Its not doing much
besides being my personal file archive, so there should be plenty of
free memory for btrfs. I have remounted the filesystem with the
clear_cache option and now will apply the tweaks mentioned by Duncan.
If this does not fix the problem I will install a more current kernel
from stretch-backports. Testing currently has btrfs-progs 4.13.3-1. Is
this version safe to use and should I upgrade it along with the
kernel?
--
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: Crash when unraring large archives on btrfs-filesystem

[Nikolay Borisov]

On  7.02.2018 21:57, Stefan Malte Schumacher wrote:
> Hello,
> 
> 
> I have encountered what I think is a problem with btrfs, which causes
> my file server to become unresponsive. But let‘s start with the basic
> information:
> 
> uname -a = Linux mars 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2
> (2018-01-04) x86_64 GNU/Linux
> 
> btrfs –version = btrfs-progs v4.7.3
> 
> 
> Label: none uuid: 1609e4e1-4037-4d31-bf12-f84a691db5d8
> 
> Total devices 5 FS bytes used 7.15TiB
> 
> devid 1 size 3.64TiB used 2.90TiB path /dev/sda
> 
> devid 2 size 3.64TiB used 2.90TiB path /dev/sdb
> 
> devid 3 size 3.64TiB used 2.90TiB path /dev/sdc
> 
> devid 4 size 3.64TiB used 2.90TiB path /dev/sdd
> 
> devid 5 size 3.64TiB used 2.90TiB path /dev/sde
> 
> 
> Data, RAID1: total=7.25TiB, used=7.14TiB
> 
> System, RAID1: total=40.00MiB, used=1.02MiB
> 
> Metadata, RAID1: total=9.00GiB, used=7.75GiB
> 
> GlobalReserve, single: total=512.00MiB, used=0.00B
> 
> 
> The following entry in kern.log seems to be the point where it all
> started and which causes me to believe that the problem is related to
> btrfs. At that time the server was unraring
> 
> a large archive stored on the btrfs filesystem.
> 
> 
> Feb 5 21:22:42 mars kernel: [249979.829318] BTRFS info (device sda):
> The free space cache file (4701944807424) is invalid. skip it

This tells you that your freespace cahe is likely corrupted, this is not
that critical but it's highly recommended you rebuild it. You can do
that by mounting your file system with the 'clear_cache' mount option.
For more information check
https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)

> 
> Feb 5 21:22:42 mars kernel: [249979.829318]
> 
> Feb 5 21:25:12 mars kernel: [250090.149452] unrar: page allocation
> stalls for 12104ms, order:0, mode:0x24200ca(GFP_HIGHUSER_MOVABLE)
> 
> Feb 5 21:25:12 mars kernel: [250116.605420] [] ?
> alloc_pages_vma+0xae/0x260
> 
> Feb 5 21:25:12 mars kernel: [250116.605422] [] ?
> __read_swap_cache_async+0x118/0x1c0
> 
> Feb 5 21:25:12 mars kernel: [250116.605423] [] ?
> read_swap_cache_async+0x24/0x60
> 
> Feb 5 21:25:12 mars kernel: [250116.605425] [] ?
> swapin_readahead+0x1a9/0x210
> 
> Feb 5 21:25:12 mars kernel: [250116.605427] [] ?
> radix_tree_lookup_slot+0x1e/0x50
> 
> Feb 5 21:25:12 mars kernel: [250116.605429] [] ?
> find_get_entry+0x1b/0x100
> 
> Feb 5 21:25:12 mars kernel: [250116.605431] [] ?
> pagecache_get_page+0x30/0x2b0
> 
> Feb 5 21:25:12 mars kernel: [250116.605434] [] ?
> do_swap_page+0x2a3/0x750
> 
> Feb 5 21:25:12 mars kernel: [250116.605436] [] ?
> handle_mm_fault+0x892/0x12d0
> 
> Feb 5 21:25:12 mars kernel: [250116.605438] [] ?
> __do_page_fault+0x25c/0x500
> 
> Feb 5 21:25:12 mars kernel: [250116.605440] [] ?
> page_fault+0x28/0x30
> 
> Feb 5 21:25:12 mars kernel: [250116.605442] [] ?
> __get_user_8+0x1b/0x25
> 
> Feb 5 21:25:12 mars kernel: [250116.605445] [] ?
> exit_robust_list+0x30/0x110
> 
> Feb 5 21:25:12 mars kernel: [250116.605447] [] ?
> mm_release+0xf8/0x130
> 
> Feb 5 21:25:12 mars kernel: [250116.605449] [] ?
> do_exit+0x150/0xae0
> 
> Feb 5 21:25:12 mars kernel: [250116.605450] [] ?
> do_group_exit+0x3a/0xa0
> 
> Feb 5 21:25:12 mars kernel: [250116.605452] [] ?
> get_signal+0x297/0x640
> 
> Feb 5 21:25:12 mars kernel: [250116.605454] [] ?
> do_signal+0x36/0x6a0
> 
> Feb 5 21:25:12 mars kernel: [250116.605457] [] ?
> exit_to_usermode_loop+0x71/0xb0
> 
> Feb 5 21:25:12 mars kernel: [250116.605459] [] ?
> syscall_return_slowpath+0x54/0x60
> 
> Feb 5 21:25:12 mars kernel: [250116.605461] [] ?
> system_call_fast_compare_end+0xb5/0xb7

THis call trace essentially tells you that your server sort of run out
of memory and you began to swap in i.e. read from the disk and it took a
rather long time (12s). Here no btrfs it is involved at all.

> 
> Feb 5 21:25:12 mars kernel: [250116.605462] Mem-Info:
> 
> Feb 5 21:25:12 mars kernel: [250116.605466] active_anon:44
> inactive_anon:69 isolated_anon:0
> 
> Feb 5 21:25:12 mars kernel: [250116.605466] active_file:3557188
> inactive_file:407932 isolated_file:1024
> 
> Feb 5 21:25:12 mars kernel: [250116.605466] unevictable:0 dirty:409214
> writeback:62 unstable:0
> 
> Feb 5 21:25:12 mars kernel: [250116.605466] slab_reclaimable:37022
> slab_unreclaimable:10475
> 
> Feb 5 21:25:12 mars kernel: [250116.605466] mapped:2329 shmem:21
> pagetables:3522 bounce:0
> 
> Feb 5 21:25:12 mars kernel: [250116.605466] free:34036 free_pcp:291 free_cma:0
> 
> Feb 5 21:25:12 mars kernel: [250116.605471] Node 0 active_anon:176kB
> inactive_anon:276kB active_file:14228752kB inactive_file:1631728kB
> unev

Re: Crash when unraring large archives on btrfs-filesystem

[Chris Murphy]

Another way to test for this problem is one of the responses in that
lkml thread by Btrfs list regular Duncan, about tweaking the knobs
that handle dirty write caching. So you could try those suggested
tweaks first, rather than changing kernels.


https://lkml.org/lkml/2016/12/13/753


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: Crash when unraring large archives on btrfs-filesystem

[Chris Murphy]

On Wed, Feb 7, 2018 at 12:57 PM, Stefan Malte Schumacher <
s.schumac...@netcologne.de> wrote:

>
>
> Feb 5 21:25:12 mars kernel: [250116.605471] Node 0 active_anon:176kB
> inactive_anon:276kB active_file:14228752kB inactive_file:1631728kB
> unevictable:0kB isolated(anon):0kB isolated(file):4096kB mapped:9316kB
> dirty:1636856kB writeback:248kB shmem:84kB shmem_thp: 0kB
> shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB
> pages_scanned:13631918 all_unreclaimable? no
>

How much RAM on the machine and how much swap available? This looks like a
lot of dirty data has accumulated, and then also there's swapping
happening. Both swap out and swap in.

>4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux

I don't know if this bears any relation to the upstream longterm 4.9.65,
but there are definitely many memory and btrfs changes between 4.9.66 and
4.9.80, including a deadlock when writing out freespace cache fix. I don't
know that this is related to your particular problem, there might be more
than one thing going on. But the easiest thing to until someone who
actually knows for sure (a developer with time to respond) is to just
upgrade the kernel and see if the problem goes away.

I did also find a similar problem related to the first problem, unclear if
it's the instigator, page allocation stalls for 12104ms, order:0,
mode:0x24200ca(GFP_HIGHUSER_MOVABLE), happening along with Btrfs. That
thread:

https://lkml.org/lkml/2016/12/13/529


---
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

Crash when unraring large archives on btrfs-filesystem

[Stefan Malte Schumacher]

Hello,


I have encountered what I think is a problem with btrfs, which causes
my file server to become unresponsive. But let‘s start with the basic
information:

uname -a = Linux mars 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2
(2018-01-04) x86_64 GNU/Linux

btrfs –version = btrfs-progs v4.7.3


Label: none uuid: 1609e4e1-4037-4d31-bf12-f84a691db5d8

Total devices 5 FS bytes used 7.15TiB

devid 1 size 3.64TiB used 2.90TiB path /dev/sda

devid 2 size 3.64TiB used 2.90TiB path /dev/sdb

devid 3 size 3.64TiB used 2.90TiB path /dev/sdc

devid 4 size 3.64TiB used 2.90TiB path /dev/sdd

devid 5 size 3.64TiB used 2.90TiB path /dev/sde


Data, RAID1: total=7.25TiB, used=7.14TiB

System, RAID1: total=40.00MiB, used=1.02MiB

Metadata, RAID1: total=9.00GiB, used=7.75GiB

GlobalReserve, single: total=512.00MiB, used=0.00B


The following entry in kern.log seems to be the point where it all
started and which causes me to believe that the problem is related to
btrfs. At that time the server was unraring

a large archive stored on the btrfs filesystem.


Feb 5 21:22:42 mars kernel: [249979.829318] BTRFS info (device sda):
The free space cache file (4701944807424) is invalid. skip it

Feb 5 21:22:42 mars kernel: [249979.829318]

Feb 5 21:25:12 mars kernel: [250090.149452] unrar: page allocation
stalls for 12104ms, order:0, mode:0x24200ca(GFP_HIGHUSER_MOVABLE)

Feb 5 21:25:12 mars kernel: [250116.605420] [] ?
alloc_pages_vma+0xae/0x260

Feb 5 21:25:12 mars kernel: [250116.605422] [] ?
__read_swap_cache_async+0x118/0x1c0

Feb 5 21:25:12 mars kernel: [250116.605423] [] ?
read_swap_cache_async+0x24/0x60

Feb 5 21:25:12 mars kernel: [250116.605425] [] ?
swapin_readahead+0x1a9/0x210

Feb 5 21:25:12 mars kernel: [250116.605427] [] ?
radix_tree_lookup_slot+0x1e/0x50

Feb 5 21:25:12 mars kernel: [250116.605429] [] ?
find_get_entry+0x1b/0x100

Feb 5 21:25:12 mars kernel: [250116.605431] [] ?
pagecache_get_page+0x30/0x2b0

Feb 5 21:25:12 mars kernel: [250116.605434] [] ?
do_swap_page+0x2a3/0x750

Feb 5 21:25:12 mars kernel: [250116.605436] [] ?
handle_mm_fault+0x892/0x12d0

Feb 5 21:25:12 mars kernel: [250116.605438] [] ?
__do_page_fault+0x25c/0x500

Feb 5 21:25:12 mars kernel: [250116.605440] [] ?
page_fault+0x28/0x30

Feb 5 21:25:12 mars kernel: [250116.605442] [] ?
__get_user_8+0x1b/0x25

Feb 5 21:25:12 mars kernel: [250116.605445] [] ?
exit_robust_list+0x30/0x110

Feb 5 21:25:12 mars kernel: [250116.605447] [] ?
mm_release+0xf8/0x130

Feb 5 21:25:12 mars kernel: [250116.605449] [] ?
do_exit+0x150/0xae0

Feb 5 21:25:12 mars kernel: [250116.605450] [] ?
do_group_exit+0x3a/0xa0

Feb 5 21:25:12 mars kernel: [250116.605452] [] ?
get_signal+0x297/0x640

Feb 5 21:25:12 mars kernel: [250116.605454] [] ?
do_signal+0x36/0x6a0

Feb 5 21:25:12 mars kernel: [250116.605457] [] ?
exit_to_usermode_loop+0x71/0xb0

Feb 5 21:25:12 mars kernel: [250116.605459] [] ?
syscall_return_slowpath+0x54/0x60

Feb 5 21:25:12 mars kernel: [250116.605461] [] ?
system_call_fast_compare_end+0xb5/0xb7

Feb 5 21:25:12 mars kernel: [250116.605462] Mem-Info:

Feb 5 21:25:12 mars kernel: [250116.605466] active_anon:44
inactive_anon:69 isolated_anon:0

Feb 5 21:25:12 mars kernel: [250116.605466] active_file:3557188
inactive_file:407932 isolated_file:1024

Feb 5 21:25:12 mars kernel: [250116.605466] unevictable:0 dirty:409214
writeback:62 unstable:0

Feb 5 21:25:12 mars kernel: [250116.605466] slab_reclaimable:37022
slab_unreclaimable:10475

Feb 5 21:25:12 mars kernel: [250116.605466] mapped:2329 shmem:21
pagetables:3522 bounce:0

Feb 5 21:25:12 mars kernel: [250116.605466] free:34036 free_pcp:291 free_cma:0

Feb 5 21:25:12 mars kernel: [250116.605471] Node 0 active_anon:176kB
inactive_anon:276kB active_file:14228752kB inactive_file:1631728kB
unevictable:0kB isolated(anon):0kB isolated(file):4096kB mapped:9316kB
dirty:1636856kB writeback:248kB shmem:84kB shmem_thp: 0kB
shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB
pages_scanned:13631918 all_unreclaimable? no


Searching for "btrfs" in kern.log shows a lot of entries for kern.log
and kern.log.1 but but none before that point of time. I think that
there is a relation between upgrading to kernel 4.9.0.5 and the start
of these problems. What follows is the output of of "zless kern.log |
grep btrfs".

Feb  5 21:25:21 mars kernel: [250128.490899] Workqueue: writeback
wb_workfn (flush-btrfs-1)

Feb  5 21:25:21 mars kernel: [250128.490940]  [] ?
io_ctl_prepare_pages+0x4c/0x180 [btrfs]

Feb  5 21:25:21 mars kernel: [250128.490953]  [] ?
__load_free_space_cache+0x1eb/0x6d0 [btrfs]

Feb  5 21:25:21 mars kernel: [250128.490966]  [] ?
load_free_space_cache+0xe9/0x190 [btrfs]

Feb  5 21:25:21 mars kernel: [250128.490975]  [] ?
cache_block_group+0x1c2/0x3c0 [btrfs]

Feb  5 21:25:21 mars kernel: [250128.490989]  [] ?
find_free_extent+0x66d/0x10d0 [btrfs]

Feb  5 21:25:21 mars kernel: [250128.490999]  [] ?
btrfs_reserve_extent+0xa1/0x210 [btrfs]

Feb  5 21:25:21 mars ke

Re: broken btrfs filesystem

[Austin S. Hemmelgarn]

On 2017-12-12 11:24, Hugo Mills wrote:

On Tue, Dec 12, 2017 at 04:18:09PM +, Neal Becker wrote:

Is it possible to check while it is mounted?


Certainly not while mounted read-write. While mounted read-only --
I'm not certain. Possibly.
In theory, it is possible, but I think that the safety measures in 
`btrfs check` don't distinguish between the two cases, so in practice it 
may not be possible.


Hugo.


On Tue, Dec 12, 2017 at 9:52 AM Hugo Mills  wrote:


On Tue, Dec 12, 2017 at 09:02:56AM -0500, Neal Becker wrote:

sudo ls -la ~/
[sudo] password for nbecker:
ls: cannot access '/home/nbecker/.bash_history': No such file or

directory

ls: cannot access '/home/nbecker/.bash_history': No such file or

directory

ls: cannot access '/home/nbecker/.bash_history': No such file or

directory

ls: cannot access '/home/nbecker/.bash_history': No such file or

directory

ls: cannot access '/home/nbecker/.bash_history': No such file or

directory

ls: cannot access '/home/nbecker/.bash_history': No such file or

directory

total 11652
drwxr-xr-x. 1 nbecker nbecker 5826 Dec 12 08:48  .
drwxr-xr-x. 1 rootroot  48 Aug  2 19:32  ..
[...]
-rwxrwxr-x. 1 nbecker nbecker  207 Dec  3  2015  BACKUP.sh
-?? ? ?   ?  ??  .bash_history
-?? ? ?   ?  ??  .bash_history
-?? ? ?   ?  ??  .bash_history
-?? ? ?   ?  ??  .bash_history
-?? ? ?   ?  ??  .bash_history
-?? ? ?   ?  ??  .bash_history
-rw-r--r--. 1 nbecker nbecker   18 Oct  8  2014  .bash_logout
[...]


Could you show the result of btrfs check --readonly on this FS? The
rest, below, doesn't show up anything unusual to me.

Hugo.


uname -a
Linux nbecker2 4.14.3-300.fc27.x86_64 #1 SMP Mon Dec 4 17:18:27 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux

  btrfs --version
btrfs-progs v4.11.1

sudo btrfs fi show
Label: 'fedora'  uuid: 93c586fa-6d86-4148-a528-e61e644db0c8
Total devices 1 FS bytes used 80.96GiB
devid1 size 230.00GiB used 230.00GiB path /dev/sda3

sudo btrfs fi df /home
Data, single: total=226.99GiB, used=78.89GiB
System, single: total=4.00MiB, used=48.00KiB
Metadata, single: total=3.01GiB, used=2.07GiB
GlobalReserve, single: total=222.36MiB, used=0.00B

dmesg.log is here:
https://nbecker.fedorapeople.org/dmesg.txt

mount | grep btrfs
/dev/sda3 on / type btrfs
(rw,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/root)
/dev/sda3 on /home type btrfs
(rw,relatime,seclabel,ssd,space_cache,subvolid=318,subvol=/home)







--
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: broken btrfs filesystem

[Hugo Mills]

On Tue, Dec 12, 2017 at 04:18:09PM +, Neal Becker wrote:
> Is it possible to check while it is mounted?

   Certainly not while mounted read-write. While mounted read-only --
I'm not certain. Possibly.

   Hugo.

> On Tue, Dec 12, 2017 at 9:52 AM Hugo Mills  wrote:
> 
> > On Tue, Dec 12, 2017 at 09:02:56AM -0500, Neal Becker wrote:
> > > sudo ls -la ~/
> > > [sudo] password for nbecker:
> > > ls: cannot access '/home/nbecker/.bash_history': No such file or
> > directory
> > > ls: cannot access '/home/nbecker/.bash_history': No such file or
> > directory
> > > ls: cannot access '/home/nbecker/.bash_history': No such file or
> > directory
> > > ls: cannot access '/home/nbecker/.bash_history': No such file or
> > directory
> > > ls: cannot access '/home/nbecker/.bash_history': No such file or
> > directory
> > > ls: cannot access '/home/nbecker/.bash_history': No such file or
> > directory
> > > total 11652
> > > drwxr-xr-x. 1 nbecker nbecker 5826 Dec 12 08:48  .
> > > drwxr-xr-x. 1 rootroot  48 Aug  2 19:32  ..
> > > [...]
> > > -rwxrwxr-x. 1 nbecker nbecker  207 Dec  3  2015  BACKUP.sh
> > > -?? ? ?   ?  ??  .bash_history
> > > -?? ? ?   ?  ??  .bash_history
> > > -?? ? ?   ?  ??  .bash_history
> > > -?? ? ?   ?  ??  .bash_history
> > > -?? ? ?   ?  ??  .bash_history
> > > -?? ? ?   ?  ??  .bash_history
> > > -rw-r--r--. 1 nbecker nbecker   18 Oct  8  2014  .bash_logout
> > > [...]
> >
> >Could you show the result of btrfs check --readonly on this FS? The
> > rest, below, doesn't show up anything unusual to me.
> >
> >Hugo.
> >
> > > uname -a
> > > Linux nbecker2 4.14.3-300.fc27.x86_64 #1 SMP Mon Dec 4 17:18:27 UTC
> > > 2017 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > >  btrfs --version
> > > btrfs-progs v4.11.1
> > >
> > > sudo btrfs fi show
> > > Label: 'fedora'  uuid: 93c586fa-6d86-4148-a528-e61e644db0c8
> > > Total devices 1 FS bytes used 80.96GiB
> > > devid1 size 230.00GiB used 230.00GiB path /dev/sda3
> > >
> > > sudo btrfs fi df /home
> > > Data, single: total=226.99GiB, used=78.89GiB
> > > System, single: total=4.00MiB, used=48.00KiB
> > > Metadata, single: total=3.01GiB, used=2.07GiB
> > > GlobalReserve, single: total=222.36MiB, used=0.00B
> > >
> > > dmesg.log is here:
> > > https://nbecker.fedorapeople.org/dmesg.txt
> > >
> > > mount | grep btrfs
> > > /dev/sda3 on / type btrfs
> > > (rw,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/root)
> > > /dev/sda3 on /home type btrfs
> > > (rw,relatime,seclabel,ssd,space_cache,subvolid=318,subvol=/home)
> > >
> >

-- 
Hugo Mills | Let me past! There's been a major scientific
hugo@... carfax.org.uk | break-in!
http://carfax.org.uk/  | Through! Break-through!
PGP: E2AB1DE4  |  Ford Prefect


signature.asc
Description: Digital signature

Re: broken btrfs filesystem

[Hugo Mills]

On Tue, Dec 12, 2017 at 09:02:56AM -0500, Neal Becker wrote:
> sudo ls -la ~/
> [sudo] password for nbecker:
> ls: cannot access '/home/nbecker/.bash_history': No such file or directory
> ls: cannot access '/home/nbecker/.bash_history': No such file or directory
> ls: cannot access '/home/nbecker/.bash_history': No such file or directory
> ls: cannot access '/home/nbecker/.bash_history': No such file or directory
> ls: cannot access '/home/nbecker/.bash_history': No such file or directory
> ls: cannot access '/home/nbecker/.bash_history': No such file or directory
> total 11652
> drwxr-xr-x. 1 nbecker nbecker 5826 Dec 12 08:48  .
> drwxr-xr-x. 1 rootroot  48 Aug  2 19:32  ..
> [...]
> -rwxrwxr-x. 1 nbecker nbecker  207 Dec  3  2015  BACKUP.sh
> -?? ? ?   ?  ??  .bash_history
> -?? ? ?   ?  ??  .bash_history
> -?? ? ?   ?  ??  .bash_history
> -?? ? ?   ?  ??  .bash_history
> -?? ? ?   ?  ??  .bash_history
> -?? ? ?   ?  ??  .bash_history
> -rw-r--r--. 1 nbecker nbecker   18 Oct  8  2014  .bash_logout
> [...]

   Could you show the result of btrfs check --readonly on this FS? The
rest, below, doesn't show up anything unusual to me.

   Hugo.

> uname -a
> Linux nbecker2 4.14.3-300.fc27.x86_64 #1 SMP Mon Dec 4 17:18:27 UTC
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> 
>  btrfs --version
> btrfs-progs v4.11.1
> 
> sudo btrfs fi show
> Label: 'fedora'  uuid: 93c586fa-6d86-4148-a528-e61e644db0c8
> Total devices 1 FS bytes used 80.96GiB
> devid1 size 230.00GiB used 230.00GiB path /dev/sda3
> 
> sudo btrfs fi df /home
> Data, single: total=226.99GiB, used=78.89GiB
> System, single: total=4.00MiB, used=48.00KiB
> Metadata, single: total=3.01GiB, used=2.07GiB
> GlobalReserve, single: total=222.36MiB, used=0.00B
> 
> dmesg.log is here:
> https://nbecker.fedorapeople.org/dmesg.txt
> 
> mount | grep btrfs
> /dev/sda3 on / type btrfs
> (rw,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/root)
> /dev/sda3 on /home type btrfs
> (rw,relatime,seclabel,ssd,space_cache,subvolid=318,subvol=/home)
> 

-- 
Hugo Mills | Hey, Virtual Memory! Now I can have a *really big*
hugo@... carfax.org.uk | ramdisk!
http://carfax.org.uk/  |
PGP: E2AB1DE4  |


signature.asc
Description: Digital signature

A kernel warning will be triggered,during copy a big file into zstd compressed btrfs filesystem

[guoxuenan]

Hi all,

I have found a kernel warning of btrfs ,during run my  shell script in 
qemu qemu virtual machine.


Linux mainline version Linux 4.15-rc2 (ae64f9bd)


The script try to copy a big file(15G) into btrfs filesystem,when I 
login virtual machine,then run the script,A kernel warning will be 
triggered  within about ten file copies.

=
#!/bin/sh
function btrfs_test()
{
umount /mnt/vdb
mkfs.btrfs -f /dev/vdb
mount -o compress=$1 /dev/vdb /mnt/vdb
cp ../data.tar  /mnt/vdb
sleep 10
btrfs filesystem sync /mnt/vdb
}

function loop_test()
{

for k in $( seq 1 100 )
do
btrfs_test zstd
done
}
loop_test
==

Kernl Warning content:

[  291.809047] 
[  291.809981] WARNING: possible recursive locking detected
[  291.810913] 4.15.0-rc2-327.58.59.16.x86_64.debug+ #8 Not tainted
[  291.811908] 
[  291.812792] khugepaged/65 is trying to acquire lock:
[  291.813614]  (fs_reclaim){+.+.}, at: [<9263bd20>] 
fs_reclaim_acquire+0x12/0x40

[  291.814972]
[  291.814972] but task is already holding lock:
[  291.815912]  (fs_reclaim){+.+.}, at: [<9263bd20>] 
fs_reclaim_acquire+0x12/0x40

[  291.817263]
[  291.817263] other info that might help us debug this:
[  291.818355]  Possible unsafe locking scenario:
[  291.818355]
[  291.819348]CPU0
[  291.819743]
[  291.820121]   lock(fs_reclaim);
[  291.820689]   lock(fs_reclaim);
[  291.821223]
[  291.821223]  *** DEADLOCK ***
[  291.821223]
[  291.84]  May be due to missing lock nesting notation
[  291.84]
[  291.823411] 1 lock held by khugepaged/65:
[  291.824048]  #0:  (fs_reclaim){+.+.}, at: [<9263bd20>] 
fs_reclaim_acquire+0x12/0x40

[  291.825480]
[  291.825480] stack backtrace:
[  291.826155] CPU: 4 PID: 65 Comm: khugepaged Not tainted 
4.15.0-rc2-327.58.59.16.x86_64.debug+ #8
[  291.827696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
BIOS 1.9.3-1.fc25 04/01/2014

[  291.829111] Call Trace:
[  291.829560]  dump_stack+0x7c/0xbf
[  291.830072]  __lock_acquire+0x8d6/0x1220
[  291.830837]  lock_acquire+0xc9/0x220
[  291.831425]  ? fs_reclaim_acquire+0x12/0x40
[  291.832110]  ? alloc_extent_state+0x21/0x1c0
[  291.832824]  fs_reclaim_acquire+0x35/0x40
[  291.833476]  ? fs_reclaim_acquire+0x12/0x40
[  291.834114]  kmem_cache_alloc+0x29/0x320
[  291.834777]  alloc_extent_state+0x21/0x1c0
[  291.835390]  __clear_extent_bit+0x2a5/0x3b0
[  291.836079]  try_release_extent_mapping+0x17c/0x200
[  291.836868]  __btrfs_releasepage+0x30/0x90
[  291.837519]  shrink_page_list+0x80d/0xf20
[  291.838158]  shrink_inactive_list+0x250/0x710
[  291.838875]  ? rcu_read_lock_sched_held+0x9b/0xb0
[  291.839666]  shrink_node_memcg+0x358/0x790
[  291.840282]  ? mem_cgroup_iter+0x98/0x530
[  291.840872]  shrink_node+0xe5/0x310
[  291.841387]  do_try_to_free_pages+0xe8/0x390
[  291.842013]  try_to_free_pages+0x146/0x3d0
[  291.842620]  __alloc_pages_slowpath+0x3d1/0xce1
[  291.843290]  __alloc_pages_nodemask+0x411/0x450
[  291.843989]  khugepaged_alloc_page+0x39/0x80
[  291.844626]  collapse_huge_page+0x78/0x9a0
[  291.845381]  ? khugepaged_scan_mm_slot+0x932/0xfa0
[  291.846113]  khugepaged_scan_mm_slot+0x953/0xfa0
[  291.846838]  ? khugepaged+0x130/0x5a0
[  291.847388]  khugepaged+0x2e0/0x5a0
[  291.848019]  ? remove_wait_queue+0x60/0x60
[  291.848678]  kthread+0x141/0x180
[  291.849239]  ? khugepaged_scan_mm_slot+0xfa0/0xfa0
[  291.849938]  ? kthread_stop+0x300/0x300
[  291.850514]  ret_from_fork+0x24/0x30



--
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: interrupt btrfs filesystem defragment -r /

[Hugo Mills]

On Sat, Jul 08, 2017 at 01:34:44PM +0200, David Arendt wrote:
> Hi,
> 
> Is it safe to interrupt a btrfs filesystem defrag -r / by using ctrl-c
> or should it be avoided ?

   Yes, it's safe.

   Hugo.

-- 
Hugo Mills | Klytus, I'm bored. What plaything can you offer me
hugo@... carfax.org.uk | today?
http://carfax.org.uk/  |
PGP: E2AB1DE4  |  Ming the Merciless, Flash Gordon


signature.asc
Description: Digital signature

Re: include linux kernel headers for btrfs filesystem

[Alex Lyakas]

Ilan,

On Mon, Mar 20, 2017 at 10:33 AM, Ilan Schwarts  wrote:
> I need to cast struct inode to struct btrfs_inode.
> in order to do it, i looked at implementation of btrfs_getattr.
>
> the code is simple:
> struct btrfs_inode *btrfsInode;
> btrfsInode = BTRFS_I(inode);
>
> in order to compile i must add the headers on top of the function:
> #include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/ctree.h"
> #include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/btrfs_inode.h"
>
> What is the problem ?
> I must manually download and include ctree.h and btrfs_inode.h, they
> are not provided in the kernel-headers package.
> On every platform I compile my driver, I have specific VM for the
> distro/kernel version, so on every VM I usually download package
> kernel-headers and everything compiles perfectly.
>
> btrfs was introduced in kernel 3.0 above.
> Arent the btrfs headers should be there ? do they exist in another
> package ? maybe fs-headers or something like that ?

Try using the below simple Makefile[1] to compile btrfs loadable
module. You need to have the kernel-headers package installed.
You can place the makefile anywhere you want, and compile via:
# make -f 

Thanks,
Alex.


[1]
obj-m += btrfs.o

# or substitute with hard-coded kernel version
KVERSION = $(shell uname -r)

SRC_DIR=/fs/btrfs
BTRFS_KO=btrfs.ko

# or specify any other output directory
OUT_DIR=/lib/modules/$(KVERSION)/kernel/fs/btrfs

all: $(OUT_DIR)/$(BTRFS_KO)

$(OUT_DIR)/$(BTRFS_KO): $(SRC_DIR)/$(BTRFS_KO)
cp $(SRC_DIR)/$(BTRFS_KO) $(OUT_DIR)/

$(SRC_DIR)/$(BTRFS_KO): $(SRC_DIR)/*.c $(SRC_DIR)/*.h
$(MAKE) -C /lib/modules/$(KVERSION)/build M=$(SRC_DIR) modules

clean:
$(MAKE) -C /lib/modules/$(KVERSION)/build M=$(SRC_DIR) clean
test -f $(OUT_DIR)/$(BTRFS_KO) && rm $(OUT_DIR)/$(BTRFS_KO)|| true


> --
> 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

include linux kernel headers for btrfs filesystem

[Ilan Schwarts]

I need to cast struct inode to struct btrfs_inode.
in order to do it, i looked at implementation of btrfs_getattr.

the code is simple:
struct btrfs_inode *btrfsInode;
btrfsInode = BTRFS_I(inode);

in order to compile i must add the headers on top of the function:
#include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/ctree.h"
#include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/btrfs_inode.h"

What is the problem ?
I must manually download and include ctree.h and btrfs_inode.h, they
are not provided in the kernel-headers package.
On every platform I compile my driver, I have specific VM for the
distro/kernel version, so on every VM I usually download package
kernel-headers and everything compiles perfectly.

btrfs was introduced in kernel 3.0 above.
Arent the btrfs headers should be there ? do they exist in another
package ? maybe fs-headers or something like that ?
--
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: "not a btrfs filesystem"

[Chris Murphy]

On Sat, Jan 21, 2017 at 11:36 AM, Marc Haber
 wrote:
> On Sat, Jan 21, 2017 at 03:52:19PM +0100, Hans van Kranenburg wrote:
>> You have to point balance to the mount point of the banana, not to the
>> block device. (balance does its work while the file system is mounted)
>
> Idiot me. I always forget that.
>

Well, in your defense the error message is misleading.


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: "not a btrfs filesystem"

[Marc Haber]

On Sat, Jan 21, 2017 at 03:52:19PM +0100, Hans van Kranenburg wrote:
> You have to point balance to the mount point of the banana, not to the
> block device. (balance does its work while the file system is mounted)

Idiot me. I always forget that.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
--
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: "not a btrfs filesystem"

[Hans van Kranenburg]

Hi,

On 01/21/2017 03:16 PM, Marc Haber wrote:
> I have a file system that I can show, check, but not rebalance:
> 
> 1 [4/3420]mh@fan:~ $ sudo btrfs fi show /dev/mapper/banana-root
> Label: none  uuid: b2906231-70a9-46d9-9830-38a13cb73171
> Total devices 1 FS bytes used 1.82GiB
> devid1 size 6.00GiB used 3.69GiB path /dev/mapper/banana-root
> 
> 1 [10/3426]mh@fan:~ $ sudo btrfs check /dev/mapper/banana-root
> Checking filesystem on /dev/mapper/banana-root
> UUID: b2906231-70a9-46d9-9830-38a13cb73171
> checking extents
> checking free space cache
> checking fs roots
> checking csums
> checking root refs
> found 1954635785 bytes used err is 0
> total csum bytes: 1833964
> total tree bytes: 75907072
> total fs tree bytes: 64241664
> total extent tree bytes: 7843840
> btree space waste bytes: 21224578
> file data blocks allocated: 2168119296
>  referenced 2088648704
> [11/3427]mh@fan:~ $ sudo btrfs balance /dev/mapper/banana-root
> ERROR: not a btrfs filesystem: /dev/mapper/banana-root
> 1 [12/3428]mh@fan:~ $

You have to point balance to the mount point of the banana, not to the
block device. (balance does its work while the file system is mounted)

> 
> The filesystem is on a logical volume which is on a PV which is in a
> loop device that is on a disk file:
> 
> [12/3428]mh@fan:~ $ sudo lvs
>   LV  VG Attr   LSize
>   rootbanana -wi-a---p-   6,00g
> [13/3429]mh@fan:~ $ sudo vgs
>   VG #PV #LV #SN Attr   VSize   VFree  
>   banana   1   2   0 wz-pn-   7,16g 164,00m
> [14/3430]mh@fan:~ $ sudo pvs
>   PV VG Fmt  Attr PSize   PFree  
>   [unknown]  banana lvm2 a-m7,16g 164,00m
> (no idea why this says "unknown" here, it is
> [15/3431]mh@fan:~ $ ls -al /dev/mapper/loop0p2
> lrwxrwxrwx 1 root root 8 Jan 21 14:40 /dev/mapper/loop0p2 -> ../dm-39
> [16/3432]mh@fan:~ $ ls -al /dev/dm-39
> brw-rw 1 root disk 254, 39 Jan 21 14:40 /dev/dm-39
> [24/3440]mh@fan:~ $ sudo kpartx -l banana.sdcard
> loop0p1 : 0 497664 /dev/loop0 2048
> loop0p2 : 0 15024128 /dev/loop0 499712
> [25/3441]mh@fan:~ $ sudo losetup --list
> NAME   SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE  DIO
> /dev/loop0 0  0 0  0 /home/mh/banana.sdcard   0
> [26/3442]mh@fan:~ $
> 
> Can a btrfs be so broken that btrfs balance doesn't recognize it any
> more? What is going on with this file system?


-- 
Hans van Kranenburg
--
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

"not a btrfs filesystem"

[Marc Haber]

I have a file system that I can show, check, but not rebalance:

1 [4/3420]mh@fan:~ $ sudo btrfs fi show /dev/mapper/banana-root
Label: none  uuid: b2906231-70a9-46d9-9830-38a13cb73171
Total devices 1 FS bytes used 1.82GiB
devid1 size 6.00GiB used 3.69GiB path /dev/mapper/banana-root

1 [10/3426]mh@fan:~ $ sudo btrfs check /dev/mapper/banana-root
Checking filesystem on /dev/mapper/banana-root
UUID: b2906231-70a9-46d9-9830-38a13cb73171
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 1954635785 bytes used err is 0
total csum bytes: 1833964
total tree bytes: 75907072
total fs tree bytes: 64241664
total extent tree bytes: 7843840
btree space waste bytes: 21224578
file data blocks allocated: 2168119296
 referenced 2088648704
[11/3427]mh@fan:~ $ sudo btrfs balance /dev/mapper/banana-root
ERROR: not a btrfs filesystem: /dev/mapper/banana-root
1 [12/3428]mh@fan:~ $

The filesystem is on a logical volume which is on a PV which is in a
loop device that is on a disk file:

[12/3428]mh@fan:~ $ sudo lvs
  LV  VG Attr   LSize
  rootbanana -wi-a---p-   6,00g
[13/3429]mh@fan:~ $ sudo vgs
  VG #PV #LV #SN Attr   VSize   VFree  
  banana   1   2   0 wz-pn-   7,16g 164,00m
[14/3430]mh@fan:~ $ sudo pvs
  PV VG Fmt  Attr PSize   PFree  
  [unknown]  banana lvm2 a-m7,16g 164,00m
(no idea why this says "unknown" here, it is
[15/3431]mh@fan:~ $ ls -al /dev/mapper/loop0p2
lrwxrwxrwx 1 root root 8 Jan 21 14:40 /dev/mapper/loop0p2 -> ../dm-39
[16/3432]mh@fan:~ $ ls -al /dev/dm-39
brw-rw 1 root disk 254, 39 Jan 21 14:40 /dev/dm-39
[24/3440]mh@fan:~ $ sudo kpartx -l banana.sdcard
loop0p1 : 0 497664 /dev/loop0 2048
loop0p2 : 0 15024128 /dev/loop0 499712
[25/3441]mh@fan:~ $ sudo losetup --list
NAME   SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE  DIO
/dev/loop0 0  0 0  0 /home/mh/banana.sdcard   0
[26/3442]mh@fan:~ $

Can a btrfs be so broken that btrfs balance doesn't recognize it any
more? What is going on with this file system?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
--
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

System freeze mounting USB BTRFS filesystem

[Steven Haigh]

Hi all,

I'm running Fedora 25 with kernel 4.8.15 (also tested 4.8.14), and when
I go to mount my USB BTRFS filesystem, the PC freezes completely.

I have managed to get a kernel crash once out of the number of freezes -
and I have attached that log. I have also posted a copy here:
https://paste.fedoraproject.org/520173/36148521/raw/

I don't believe there is anything physically wrong with the USB drive,
as I can read at least the first 120Gb with dd via:
dd if=/dev/sdc1 of=/dev/null bs=1M

I can successfully run btrfsck - and no read errors or messages are logged:
$ btrfsck /dev/sdc1
Checking filesystem on /dev/sdc1
UUID: dba49c2d-5362-47ae-b25a-3c3e3aa1b66f
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 161932349440 bytes used err is 0
total csum bytes: 156784812
total tree bytes: 1338654720
total fs tree bytes: 1091043328
total extent tree bytes: 76120064
btree space waste bytes: 219938988
file data blocks allocated: 160593731584
 referenced 160593694720

Even though the tool mentions the 'repair is considered dangerous', I
ran it anyway, and got the following:
$ btrfsck --repair -p /dev/sdc1
enabling repair mode
Checking filesystem on /dev/sdc1
UUID: dba49c2d-5362-47ae-b25a-3c3e3aa1b66f
checking extents [O]
Fixed 0 roots.
cache and super generation don't match, space cache will be invalidated
checking fs roots [.]
checking csums
checking root refs
found 161932349440 bytes used err is 0
total csum bytes: 156784812
total tree bytes: 1338654720
total fs tree bytes: 1091043328
total extent tree bytes: 76120064
btree space waste bytes: 219938988
file data blocks allocated: 160593731584
 referenced 160593694720

I tried to mount the filesystem again - and while the system doesn't
hard freeze, I get the following crash:

 kernel: BTRFS info (device sdc1): disk space caching is enabled


 kernel: BTRFS info (device sdc1): has skinny extents


 kernel: BUG: unable to handle kernel NULL pointer dereference at
035c

 kernel: IP: [] flush_space+0x2ed/0x620 [btrfs]
 kernel: PGD 0
 kernel: Oops:  [#1] SMP
 kernel: Modules linked in: btrfs xor raid6_pq uas usb_storage rfcomm
ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink
ebtable_nat ebtable_broute bridge stp llc ip6table_raw ip6table_security
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle iptable_raw iptable_security iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_mangle ebtable_filter ebtables ip6table_filter ip6_tables bnep
hwmon_vid snd_hda_codec_hdmi intel_powerclamp coretemp kvm_intel kvm
irqbypass nvidia_drm(POE) ir_lirc_codec intel_cstate nvidia_modeset(POE)
lirc_dev intel_uncore iTCO_wdt nvidia(POE) iTCO_vendor_support
snd_hda_codec_realtek r820t snd_hda_codec_generic rtl2832 i2c_mux
snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq btusb btrtl
 kernel:  snd_seq_device btbcm btintel snd_pcm bluetooth
dvb_usb_rtl28xxu r8169 dvb_usb_v2 joydev drm_kms_helper dvb_core
i2c_i801 rc_core rfkill drm i2c_smbus snd_timer mii lpc_ich snd
soundcore i7core_edac i5500_temp edac_core acpi_cpufreq tpm_tis
tpm_tis_core asus_atk0110 shpchp tpm nfsd auth_rpcgss nfs_acl lockd
grace sunrpc xfs libcrc32c mxm_wmi crc32c_intel serio_raw hid_microsoft
fjes wmi
 kernel: CPU: 6 PID: 2910 Comm: mount Tainted: P  IOE
4.8.15-300.fc25.x86_64 #1
 kernel: Hardware name: System manufacturer System Product
Name/P6X58D-E, BIOS 080308/06/2012
 kernel: task: a2456d639d40 task.stack: a245afd28000
 kernel: RIP: 0010:[]  []
flush_space+0x2ed/0x620 [btrfs]
 kernel: RSP: 0018:a245afd2b760  EFLAGS: 00010246
 kernel: RAX: 0001 RBX:  RCX: 0002
 kernel: RDX: 0002 RSI: a24584e9f800 RDI: 
 kernel: RBP: a245afd2b818 R08: 0001 R09: 
 kernel: R10: ffe4 R11: 0100 R12: 
 kernel: R13: 0002 R14: 0001 R15: 0002
 kernel: FS:  7f1f55eaf340() GS:a245f938()
knlGS:
 kernel: CS:  0010 DS:  ES:  CR0: 80050033
 kernel: CR2: 035c CR3: 000124578000 CR4: 06e0
 kernel: Stack:
 kernel:  a24561c09cc0  
a24561c09b40
 kernel:  a24584e9f800 e2c595b9 a245afd2b7f8
a24561c09cb8
 kernel:  0007 a245afd2b7d0 0002
0002
 kernel: Call Trace:
 kernel:  [] ? can_overcommit.part.70+0x6a/0x100 [btrfs]
 kernel:  [] reserve_metadata_bytes+0x1c4/0xb60 [btrfs]
 kernel:  [] btrfs_block_rsv_refill+0x75/0xa0 [btrfs]
 kernel:  [] btrfs_evict_inode+0x3e8/0x5c0 [btrfs]
 kernel:  [] ? wake_atomic_t_function+0x60/0x60
 kernel:  [] evict+0xb3/0x180
 kernel:  [] iput+0x1b0/0x230
 kernel:  [] btrfs_orphan_cleanup+0x1f2/0x430 [btrfs]
 kernel:  [] btrfs_recover_relocation+0x351/0x460 [btrfs]
 kernel

Re: problems with btrfs filesystem loading

[Michał Zegan]

That seems to do the trick, thanks

W dniu 29.12.2016 o 17:53, Roman Mamedov pisze:
> On Thu, 29 Dec 2016 16:42:09 +0100
> Michał Zegan  wrote:
> 
>> I have odroid c2, processor architecture aarch64, linux kernel from
>> master as of today from http://github.com/torwalds/linux.git.
>> It seems that the btrfs module cannot be loaded. The only thing that
>> happens is that after modprobe i see:
>> modprobe: can't load module btrfs (kernel/fs/btrfs/btrfs.ko.gz): unknown
>> symbol in module, or unknown parameter
>> No errors in dmesg, like I have ignore_loglevel in kernel cmdline and no
>> logs in console appear except logs for loading dependencies like xor
>> module, but that is probably not important.
>> The kernel has been recompiled few minutes ago from scratch, the only
>> thing left was .config file. What is that? other modules load correctly
>> from what I can see.
> 
> In the past there's been some trouble with crc32 dependencies:
> https://www.spinics.net/lists/linux-btrfs/msg32104.html
> Not sure if that's relevant anymore, but in any case, check if you have
> crc32-related stuff either built-in or compiled as modules, if latter, try
> loading those before btrfs (/lib/modules/*/kernel/crypto/crc32*)
> 



signature.asc
Description: OpenPGP digital signature

Re: problems with btrfs filesystem loading

[Roman Mamedov]

On Thu, 29 Dec 2016 16:42:09 +0100
Michał Zegan  wrote:

> I have odroid c2, processor architecture aarch64, linux kernel from
> master as of today from http://github.com/torwalds/linux.git.
> It seems that the btrfs module cannot be loaded. The only thing that
> happens is that after modprobe i see:
> modprobe: can't load module btrfs (kernel/fs/btrfs/btrfs.ko.gz): unknown
> symbol in module, or unknown parameter
> No errors in dmesg, like I have ignore_loglevel in kernel cmdline and no
> logs in console appear except logs for loading dependencies like xor
> module, but that is probably not important.
> The kernel has been recompiled few minutes ago from scratch, the only
> thing left was .config file. What is that? other modules load correctly
> from what I can see.

In the past there's been some trouble with crc32 dependencies:
https://www.spinics.net/lists/linux-btrfs/msg32104.html
Not sure if that's relevant anymore, but in any case, check if you have
crc32-related stuff either built-in or compiled as modules, if latter, try
loading those before btrfs (/lib/modules/*/kernel/crypto/crc32*)

-- 
With respect,
Roman
--
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

Fwd: problems with btrfs filesystem loading

[Michał Zegan]

Resending to btrfs list



--- Treść przekazanej wiadomości ---
To: linux-fsde...@vger.kernel.org
From: Michał Zegan <webczat_...@poczta.onet.pl>
Subject: problems with btrfs filesystem loading
Message-ID: <05893a24-2bf7-d485-1f9c-b10650419...@poczta.onet.pl>
Date: Thu, 29 Dec 2016 16:24:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="mQjxlXhkhghUxUDee2dbaL9BkEvBHD9kN"
X-ONET_PL-MDA-Received: ppn20v.m5r2.onet 23374

Hello.

I have odroid c2, processor architecture aarch64, linux kernel from
master as of today from http://github.com/torwalds/linux.git.
It seems that the btrfs module cannot be loaded. The only thing that
happens is that after modprobe i see:
modprobe: can't load module btrfs (kernel/fs/btrfs/btrfs.ko.gz): unknown
symbol in module, or unknown parameter
No errors in dmesg, like I have ignore_loglevel in kernel cmdline and no
logs in console appear except logs for loading dependencies like xor
module, but that is probably not important.
The kernel has been recompiled few minutes ago from scratch, the only
thing left was .config file. What is that? other modules load correctly
from what I can see.





signature.asc
Description: OpenPGP digital signature

Re: Server hangs when mount BTRFS filesystem.

[Xin Zhou]

Hi Кравцов,

>From the log message, it seems dm-22 has been running out space, probably some 
>checksum did not get committed to disk.
And when trying to repair, it reports checksum missing.


merge_reloc_roots:2426: errno=-28 No space left
Dec 15 00:05:47 OraCI2 kernel: BTRFS warning (device dm-22): Skipping
commit of aborted transaction.
Dec 15 00:05:47 OraCI2 kernel: BTRFS: error (device dm-22) in
cleanup_transaction:1854: errno=-28 No space left
Dec 15 00:05:57 OraCI2 kernel: pending csums is 34287616

...
ERROR: errors found in extent allocation tree or chunk allocation
Fixed 0 roots.
checking free space cache [.]
root 5 inode 28350 errors 1000, some csum missing
root 5 inode 28351 errors 1000, some csum missing

Thanks,
Xin
 
 

Sent: Thursday, December 15, 2016 at 12:58 AM
From: "Кравцов Роман Владимирович" <r.kravt...@sigma-it.ru>
To: linux-btrfs@vger.kernel.org
Subject: Server hangs when mount BTRFS filesystem.
Hello.

First, server is hangs when btrfs balance working (see logs below).
After server reset can't mount filesystem.

When trying to execute command

# mount -t btrfs /dev/OraCI2/pes.isuse_bp.stands
/var/lib/docker/db/pes.isuse_bp.stands/pes.isuse_bp.standby.base/

server hangs without any messages and log records.


# btrfs --version
btrfs-progs v4.8.3

# btrfs fi show /dev/mapper/OraCI2-pes.isuse_bp.stands
Label: 'pes.isuse_bp.stands' uuid: ada5d777-565b-48e7-87dc-c58c8ad13466
Total devices 1 FS bytes used 2.24TiB
devid 1 size 3.49TiB used 2.35TiB path
/dev/mapper/OraCI2-pes.isuse_bp.stands



# btrfsck --repair -p /dev/OraCI2/pes.isuse_bp.stands
enabling repair mode
Checking filesystem on /dev/OraCI2/pes.isuse_bp.stands
UUID: ada5d777-565b-48e7-87dc-c58c8ad13466
parent transid verify failed on 2651226128384 wanted 136007 found 136176
parent transid verify failed on 2651226128384 wanted 136007 found 136176
Ignoring transid failure
leaf parent key incorrect 2651226128384
bad block 2651226128384

ERROR: errors found in extent allocation tree or chunk allocation
Fixed 0 roots.
checking free space cache [.]
root 5 inode 28350 errors 1000, some csum missing
root 5 inode 28351 errors 1000, some csum missing
root 5 inode 28354 errors 1000, some csum missing
root 5 inode 28358 errors 1000, some csum missing
root 5 inode 28360 errors 1000, some csum missing
root 5 inode 28361 errors 1000, some csum missing
root 5 inode 28368 errors 1000, some csum missing
root 5 inode 28369 errors 1000, some csum missing
root 5 inode 28370 errors 1000, some csum missing
root 5 inode 28371 errors 1000, some csum missing
root 5 inode 28372 errors 1000, some csum missing
root 5 inode 28373 errors 1000, some csum missing
root 5 inode 28376 errors 1000, some csum missing
root 5 inode 28377 errors 1000, some csum missing
root 5 inode 28378 errors 1000, some csum missing
root 5 inode 28379 errors 1000, some csum missing
root 5 inode 28380 errors 1000, some csum missing
root 5 inode 28381 errors 1000, some csum missing
root 5 inode 28382 errors 1000, some csum missing
root 5 inode 28383 errors 1000, some csum missing
root 5 inode 28384 errors 1000, some csum missing
root 5 inode 28385 errors 1000, some csum missing
root 5 inode 28386 errors 1000, some csum missing
root 5 inode 28387 errors 1000, some csum missing
root 5 inode 28388 errors 1000, some csum missing
root 5 inode 28389 errors 1000, some csum missing
root 5 inode 28390 errors 1000, some csum missing
root 5 inode 28391 errors 1000, some csum missing
root 5 inode 28392 errors 1000, some csum missing
root 5 inode 28393 errors 1000, some csum missing
root 5 inode 28394 errors 1000, some csum missing
root 5 inode 28395 errors 1000, some csum missing
root 5 inode 28396 errors 1000, some csum missing
root 5 inode 55108 errors 1000, some csum missing
root 5 inode 55313 errors 1000, some csum missing
root 5 inode 55314 errors 1000, some csum missing
root 5 inode 55315 errors 1000, some csum missing
root 5 inode 55316 errors 1000, some csum missing
root 5 inode 55317 errors 1000, some csum missing
root 5 inode 55318 errors 1000, some csum missing

checking csums
checking root refs
Recowing metadata block 2651226128384
found 2462630760448 bytes used err is 0
total csum bytes: 2398866488
total tree bytes: 5910593536
total fs tree bytes: 1679392768
total extent tree bytes: 1436450816
btree space waste bytes: 887715010
file data blocks allocated: 459312458981376
referenced 2199769403392
extent buffer leak: start 2651226128384 len 16384


# cat /var/log/messages | grep 'Dec 15 00'
Dec 15 00:02:35 OraCI2 kernel: BTRFS info (device dm-22): found 41156
extents
Dec 15 00:02:35 OraCI2 kernel: BTRFS info (device dm-22): relocating
block group 2568411414528 flags 1
Dec 15 00:02:37 OraCI2 kernel: BTRFS info (device dm-22): found 34939
extents
Dec 15 00:05:47 OraCI2 kernel: use_block_rsv: 20 callbacks suppressed
Dec 15 00:05:47 OraCI2 kernel: [ cut here ]
Dec 15 00:05:47 OraCI2 kernel: WARNING: CPU: 35 PID: 30215 at
fs/bt

Server hangs when mount BTRFS filesystem.

[Кравцов Роман Владимирович]

Hello.

First, server is hangs when btrfs balance working (see logs below).
After server reset can't mount filesystem.

When trying to execute command

# mount -t btrfs /dev/OraCI2/pes.isuse_bp.stands 
/var/lib/docker/db/pes.isuse_bp.stands/pes.isuse_bp.standby.base/


server hangs without any messages and log records.


# btrfs --version
btrfs-progs v4.8.3

# btrfs fi show /dev/mapper/OraCI2-pes.isuse_bp.stands
Label: 'pes.isuse_bp.stands'  uuid: ada5d777-565b-48e7-87dc-c58c8ad13466
Total devices 1 FS bytes used 2.24TiB
	devid1 size 3.49TiB used 2.35TiB path 
/dev/mapper/OraCI2-pes.isuse_bp.stands




# btrfsck --repair -p /dev/OraCI2/pes.isuse_bp.stands
enabling repair mode
Checking filesystem on /dev/OraCI2/pes.isuse_bp.stands
UUID: ada5d777-565b-48e7-87dc-c58c8ad13466
parent transid verify failed on 2651226128384 wanted 136007 found 136176
parent transid verify failed on 2651226128384 wanted 136007 found 136176
Ignoring transid failure
leaf parent key incorrect 2651226128384
bad block 2651226128384

ERROR: errors found in extent allocation tree or chunk allocation
Fixed 0 roots.
checking free space cache [.]
root 5 inode 28350 errors 1000, some csum missing
root 5 inode 28351 errors 1000, some csum missing
root 5 inode 28354 errors 1000, some csum missing
root 5 inode 28358 errors 1000, some csum missing
root 5 inode 28360 errors 1000, some csum missing
root 5 inode 28361 errors 1000, some csum missing
root 5 inode 28368 errors 1000, some csum missing
root 5 inode 28369 errors 1000, some csum missing
root 5 inode 28370 errors 1000, some csum missing
root 5 inode 28371 errors 1000, some csum missing
root 5 inode 28372 errors 1000, some csum missing
root 5 inode 28373 errors 1000, some csum missing
root 5 inode 28376 errors 1000, some csum missing
root 5 inode 28377 errors 1000, some csum missing
root 5 inode 28378 errors 1000, some csum missing
root 5 inode 28379 errors 1000, some csum missing
root 5 inode 28380 errors 1000, some csum missing
root 5 inode 28381 errors 1000, some csum missing
root 5 inode 28382 errors 1000, some csum missing
root 5 inode 28383 errors 1000, some csum missing
root 5 inode 28384 errors 1000, some csum missing
root 5 inode 28385 errors 1000, some csum missing
root 5 inode 28386 errors 1000, some csum missing
root 5 inode 28387 errors 1000, some csum missing
root 5 inode 28388 errors 1000, some csum missing
root 5 inode 28389 errors 1000, some csum missing
root 5 inode 28390 errors 1000, some csum missing
root 5 inode 28391 errors 1000, some csum missing
root 5 inode 28392 errors 1000, some csum missing
root 5 inode 28393 errors 1000, some csum missing
root 5 inode 28394 errors 1000, some csum missing
root 5 inode 28395 errors 1000, some csum missing
root 5 inode 28396 errors 1000, some csum missing
root 5 inode 55108 errors 1000, some csum missing
root 5 inode 55313 errors 1000, some csum missing
root 5 inode 55314 errors 1000, some csum missing
root 5 inode 55315 errors 1000, some csum missing
root 5 inode 55316 errors 1000, some csum missing
root 5 inode 55317 errors 1000, some csum missing
root 5 inode 55318 errors 1000, some csum missing

checking csums
checking root refs
Recowing metadata block 2651226128384
found 2462630760448 bytes used err is 0
total csum bytes: 2398866488
total tree bytes: 5910593536
total fs tree bytes: 1679392768
total extent tree bytes: 1436450816
btree space waste bytes: 887715010
file data blocks allocated: 459312458981376
 referenced 2199769403392
extent buffer leak: start 2651226128384 len 16384


# cat /var/log/messages | grep 'Dec 15 00'
Dec 15 00:02:35 OraCI2 kernel: BTRFS info (device dm-22): found 41156 
extents
Dec 15 00:02:35 OraCI2 kernel: BTRFS info (device dm-22): relocating 
block group 2568411414528 flags 1
Dec 15 00:02:37 OraCI2 kernel: BTRFS info (device dm-22): found 34939 
extents

Dec 15 00:05:47 OraCI2 kernel: use_block_rsv: 20 callbacks suppressed
Dec 15 00:05:47 OraCI2 kernel: [ cut here ]
Dec 15 00:05:47 OraCI2 kernel: WARNING: CPU: 35 PID: 30215 at 
fs/btrfs/extent-tree.c:8321 btrfs_alloc_tree_block+0x3b1/0x4c0 [btrfs]
Dec 15 00:05:47 OraCI2 kernel: Modules linked in: xt_nat veth 
binfmt_misc dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag 
xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter 
nf_nat nf_conntrack bonding sb_edac edac_core x86_pkg_temp_thermal 
coretemp kvm_intel kvm dm_thin_pool irqbypass dm_persistent_data 
dm_bio_prison dm_bufio crct10dif_pclmul crc32_pclmul btrfs 
ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper 
cryptd intel_cstate intel_rapl_perf xor ses enclosure joydev mei_me 
ipmi_devintf scsi_transport_sas iTCO_wdt pcspkr mxm_wmi 
iTCO_vendor_support input_leds mei sg raid6_pq i2c_i801 lpc_ich 
i2c_smbus mfd_core ipmi_si ipmi_msghandler shpchp ioatdma wmi acpi_pad 
acpi_power_meter ip_tables xfs libcrc32c sd_mod
Dec 15 00:05:47 OraCI2 kernel: 

Re: Bug in 'btrfs filesystem du' ?

[Andrei Borzenkov]

28.06.2016 20:20, Andrei Borzenkov пишет:
> 28.06.2016 19:55, Henk Slager пишет:
>> On Tue, Jun 28, 2016 at 2:56 PM, M G Berberich <bt...@oss.m-berberich.de> 
>> wrote:
>>> Hello,
>>>
>>> Am Montag, den 27. Juni schrieb Henk Slager:
>>>> On Mon, Jun 27, 2016 at 3:33 PM, M G Berberich <bt...@oss.m-berberich.de> 
>>>> wrote:
>>>>> Am Montag, den 27. Juni schrieb M G Berberich:
>>>>>> after a balance ‘btrfs filesystem du’ probably shows false data about
>>>>>> shared data.
>>>>>
>>>>> Oh, I forgot: I have btrfs-progs v4.5.2 and kernel 4.6.2.
>>>>
>>>> With  btrfs-progs v4.6.1 and kernel 4.7-rc5, the numbers are correct
>>>> about shared data.
>>>
>>> I tested with kernels 4.6.3 and 4.7-rc5 and with btrfs-progs 4.5.2 and
>>> 4.61.
>> Also with kernel 4.6.2-1-default and btrfs-progs v4.5.3+20160516
>> (current stock opensuse tumbleweed) I cannot reproduce the problem.
>>
> 
> I confirm the same behavior on openSUSE Tumbleweed with kernel 4.6.2-1.2
> and btrfsprogs 4.5.3-1.2 using provided script.
> 

I realized that it sounded ambiguous. I do see the reported bug on
openSUSE Tumbleweed using the same versions as you. After rebalance
shared data disappears completely in du output.

--
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: Bug in 'btrfs filesystem du' ?

[Andrei Borzenkov]

28.06.2016 19:55, Henk Slager пишет:
> On Tue, Jun 28, 2016 at 2:56 PM, M G Berberich <bt...@oss.m-berberich.de> 
> wrote:
>> Hello,
>>
>> Am Montag, den 27. Juni schrieb Henk Slager:
>>> On Mon, Jun 27, 2016 at 3:33 PM, M G Berberich <bt...@oss.m-berberich.de> 
>>> wrote:
>>>> Am Montag, den 27. Juni schrieb M G Berberich:
>>>>> after a balance ‘btrfs filesystem du’ probably shows false data about
>>>>> shared data.
>>>>
>>>> Oh, I forgot: I have btrfs-progs v4.5.2 and kernel 4.6.2.
>>>
>>> With  btrfs-progs v4.6.1 and kernel 4.7-rc5, the numbers are correct
>>> about shared data.
>>
>> I tested with kernels 4.6.3 and 4.7-rc5 and with btrfs-progs 4.5.2 and
>> 4.61.
> Also with kernel 4.6.2-1-default and btrfs-progs v4.5.3+20160516
> (current stock opensuse tumbleweed) I cannot reproduce the problem.
> 

I confirm the same behavior on openSUSE Tumbleweed with kernel 4.6.2-1.2
and btrfsprogs 4.5.3-1.2 using provided script.

>  The later kernel with two patches to make the kernel work:
>> https://lkml.org/lkml/2016/6/1/310 https://lkml.org/lkml/2016/6/1/311 .
> ... so these seem to cause the problem
> 
> 
>> You can see the script¹ I used (do-btrfs-du-test) and the logs at
>> http://m-berberich.de/btrfs/
>>
>> In all four cases, ‘btrfs fi du -s .’ reports
>>
>>  Total   Exclusive  Set shared  Filename
>>   59.38MiB   0.00B29.69MiB  .
>>
>> befor balance and
>>
>>  Total   Exclusive  Set shared  Filename
>>   59.38MiB59.38MiB   0.00B  .
>>
>> after balance.
>>
>> Disclaimer: The script works for me, no guaranty at all.
>>
>> MfG
>> bmg
>> __
>> ¹ Disclaimer: The script works for me, no guaranty at all.
>> --
>> „Des is völlig wurscht, was heut beschlos- | M G Berberich
>>  sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
>> (SPD-Stadtrat Kurt Schindler; Regensburg)  |
>> --
>> 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
> 

--
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: Bug in 'btrfs filesystem du' ?

[Henk Slager]

On Tue, Jun 28, 2016 at 2:56 PM, M G Berberich <bt...@oss.m-berberich.de> wrote:
> Hello,
>
> Am Montag, den 27. Juni schrieb Henk Slager:
>> On Mon, Jun 27, 2016 at 3:33 PM, M G Berberich <bt...@oss.m-berberich.de> 
>> wrote:
>> > Am Montag, den 27. Juni schrieb M G Berberich:
>> >> after a balance ‘btrfs filesystem du’ probably shows false data about
>> >> shared data.
>> >
>> > Oh, I forgot: I have btrfs-progs v4.5.2 and kernel 4.6.2.
>>
>> With  btrfs-progs v4.6.1 and kernel 4.7-rc5, the numbers are correct
>> about shared data.
>
> I tested with kernels 4.6.3 and 4.7-rc5 and with btrfs-progs 4.5.2 and
> 4.61.
Also with kernel 4.6.2-1-default and btrfs-progs v4.5.3+20160516
(current stock opensuse tumbleweed) I cannot reproduce the problem.

 The later kernel with two patches to make the kernel work:
> https://lkml.org/lkml/2016/6/1/310 https://lkml.org/lkml/2016/6/1/311 .
... so these seem to cause the problem


> You can see the script¹ I used (do-btrfs-du-test) and the logs at
> http://m-berberich.de/btrfs/
>
> In all four cases, ‘btrfs fi du -s .’ reports
>
>  Total   Exclusive  Set shared  Filename
>   59.38MiB   0.00B29.69MiB  .
>
> befor balance and
>
>  Total   Exclusive  Set shared  Filename
>   59.38MiB59.38MiB   0.00B  .
>
> after balance.
>
> Disclaimer: The script works for me, no guaranty at all.
>
> MfG
> bmg
> __
> ¹ Disclaimer: The script works for me, no guaranty at all.
> --
> „Des is völlig wurscht, was heut beschlos- | M G Berberich
>  sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
> (SPD-Stadtrat Kurt Schindler; Regensburg)  |
> --
> 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: Bug in 'btrfs filesystem du' ?

[M G Berberich]

Hello,

Am Montag, den 27. Juni schrieb Henk Slager:
> On Mon, Jun 27, 2016 at 3:33 PM, M G Berberich <bt...@oss.m-berberich.de> 
> wrote:
> > Am Montag, den 27. Juni schrieb M G Berberich:
> >> after a balance ‘btrfs filesystem du’ probably shows false data about
> >> shared data.
> >
> > Oh, I forgot: I have btrfs-progs v4.5.2 and kernel 4.6.2.
> 
> With  btrfs-progs v4.6.1 and kernel 4.7-rc5, the numbers are correct
> about shared data.

I tested with kernels 4.6.3 and 4.7-rc5 and with btrfs-progs 4.5.2 and
4.61. The later kernel with two patches to make the kernel work:
https://lkml.org/lkml/2016/6/1/310 https://lkml.org/lkml/2016/6/1/311 .

You can see the script¹ I used (do-btrfs-du-test) and the logs at
http://m-berberich.de/btrfs/

In all four cases, ‘btrfs fi du -s .’ reports

 Total   Exclusive  Set shared  Filename
  59.38MiB   0.00B29.69MiB  .

befor balance and

 Total   Exclusive  Set shared  Filename
  59.38MiB59.38MiB   0.00B  .

after balance.

Disclaimer: The script works for me, no guaranty at all.

MfG
bmg
__
¹ Disclaimer: The script works for me, no guaranty at all.
-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 
--
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: Bug in 'btrfs filesystem du' ?

[Henk Slager]

On Mon, Jun 27, 2016 at 3:33 PM, M G Berberich <bt...@oss.m-berberich.de> wrote:
> Am Montag, den 27. Juni schrieb M G Berberich:
>> after a balance ‘btrfs filesystem du’ probably shows false data about
>> shared data.
>
> Oh, I forgot: I have btrfs-progs v4.5.2 and kernel 4.6.2.

With  btrfs-progs v4.6.1 and kernel 4.7-rc5, the numbers are correct
about shared data.
--
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: Bug in 'btrfs filesystem du' ?

[M G Berberich]

Am Montag, den 27. Juni schrieb M G Berberich:
> after a balance ‘btrfs filesystem du’ probably shows false data about
> shared data.

Oh, I forgot: I have btrfs-progs v4.5.2 and kernel 4.6.2.

MfG
bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | m...@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 
--
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

Bug in 'btrfs filesystem du' ?

[M G Berberich]

Hello,

after a balance ‘btrfs filesystem du’ probably shows false data about
shared data.

To reproduce, create a (smal) btrfs-filesystem, copy some data in a
directory, then ‘cp -a --reflink’ the data. Now all data is shared and
‘btrfs fi du’ shows it correct. In my case:

 Total   Exclusive  Set shared  Filename
  59.38MiB29.69MiB29.69MiB  .

after a balance ‘btrfs fi du’ shows no shared data any more, but all
data as exclusive. In my case:

 Total   Exclusive  Set shared  Filename
  59.38MiB59.38MiB   0.00B  .

As ‘btrfs fi df’ still shows used=29.69MiB, the problem probabaly is
in btrfs-tools.

Test-session log:

# dd if=/dev/urandom of=dev-btrfs bs=4K count=10
10+0 Datensätze ein
10+0 Datensätze aus
40960 bytes (410 MB, 391 MiB) copied, 24.7574 s, 16.5 MB/s

# mkfs.btrfs dev-btrfs
btrfs-progs v4.5.2
See http://btrfs.wiki.kernel.org for more information.
 
Label:  (null)
UUID:   698a2755-8ecb-468d-9577-9a48947361ea
Node size:  16384
Sector size:4096
Filesystem size:390.62MiB
Block group profiles:
  Data: single8.00MiB
  Metadata: DUP  40.00MiB
  System:   DUP  12.00MiB
SSD detected:   no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   IDSIZE  PATH
1   390.62MiB  dev-btrfs
 

# mount /tmp/dev-btrfs /mnt/

# cd /mnt/

# btrfs fi du -s .
 Total   Exclusive  Set shared  Filename
 0.00B   0.00B   0.00B  .

# cp -a /scratch/kernel/linux-4.6/drivers/usb .

# btrfs fi du -s .
 Total   Exclusive  Set shared  Filename
  28.96MiB28.96MiB   0.00B  .

# btrfs fi df .
Data, single: total=56.00MiB, used=3.61MiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=32.00MiB, used=192.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B

# btrfs fi usage .
Overall:
Device size: 390.62MiB
Device allocated:136.00MiB
Device unallocated:  254.62MiB
Device missing:  0.00B
Used: 32.06MiB
Free (estimated):280.94MiB  (min: 153.62MiB)
Data ratio:   1.00
Metadata ratio:   2.00
Global reserve:   16.00MiB  (used: 0.00B)
 
Data,single: Size:56.00MiB, Used:29.69MiB
   /dev/loop0 56.00MiB
 
Metadata,DUP: Size:32.00MiB, Used:1.17MiB
   /dev/loop0 64.00MiB
 
System,DUP: Size:8.00MiB, Used:16.00KiB
   /dev/loop0 16.00MiB
 
Unallocated:
   /dev/loop0254.62MiB

# cp -a --reflink usb usb2

# btrfs fi du -s .
 Total   Exclusive  Set shared  Filename
  59.38MiB29.69MiB29.69MiB  .

# btrfs fi df .
Data, single: total=56.00MiB, used=29.69MiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=32.00MiB, used=1.17MiB
GlobalReserve, single: total=16.00MiB, used=0.00B

# btrfs fi usage .
Overall:
Device size: 390.62MiB
Device allocated:136.00MiB
Device unallocated:  254.62MiB
Device missing:  0.00B
Used: 32.06MiB
Free (estimated):280.94MiB  (min: 153.62MiB)
Data ratio:   1.00
Metadata ratio:   2.00
Global reserve:   16.00MiB  (used: 0.00B)
 
Data,single: Size:56.00MiB, Used:29.69MiB
   /dev/loop0 56.00MiB
 
Metadata,DUP: Size:32.00MiB, Used:1.17MiB
   /dev/loop0 64.00MiB
 
System,DUP: Size:8.00MiB, Used:16.00KiB
   /dev/loop0 16.00MiB
 
Unallocated:
   /dev/loop0254.62MiB

# btrfs balance start .
WARNING:
 
Full balance without filters requested. This operation is very
intense and takes potentially very long. It is recommended to
use the balance filters to narrow down the balanced data.
Use 'btrfs balance start --full-balance' option to skip this
warning. The operation will start in 10 seconds.
Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting balance without any filters.
Done, had to relocate 4 out of 4 chunks

# btrfs fi du -s .
 Total   Exclusive  Set shared  Filename
  59.38MiB59.38MiB   0.00B  .

# btrfs fi df .
Data, single: total=48.00MiB, used=29.69MiB
System, DUP: total=24.00MiB, used=16.00KiB
Metadata, DUP: total=24.00MiB, used=2.08MiB
GlobalReserve, single: total=16.00MiB, used=0.00B

# btrfs fi usage .
Overall:
Device size: 390.62MiB
Device allocated:144.00MiB
Device unallocated:  246.62MiB
Device missing:  0.00B
Used: 33.88MiB
Free (estimated):264.94MiB  (min: 141.62MiB)
Data ratio:   1.00
Metadata ratio:   2.00
Global reserve:   16.00MiB  (used: 0.00B)
 
Data,single: Size:48.00MiB, Used:29.69MiB
   /dev/loop0 48.00MiB
 
Metadata,DUP: Size:24.00MiB, Used

Re: [PATCH 3/4] btrfs-progs: Fix a regression that btrfs filesystem label doesn't work

[David Sterba]

On Mon, Mar 14, 2016 at 09:15:42AM +0900, Satoru Takeuchi wrote:
> The number of arguments which is allowed to pass became wrong
> from the following commit.
> 
> commit 176aeca9a148c5e29de0 ("btrfs-progs: add getopt stubs where needed")
> 
> * actual result
> 
>   ===
>   # ./btrfs prop get /btrfs label
>   label=foo
>   # ./btrfs fi label /btrfs
>   btrfs filesystem label: too few arguments
>   usage: btrfs filesystem label [|] []
> 
>   Get or change the label of a filesystem
> 
>   With one argument, get the label of filesystem on .
>   If  is passed, set the filesystem label to .
> 
>   # ./btrfs fi label /btrfs bar
>   foo
>   # ./btrfs prop get /btrfs label
>   label=foo
>   ===
> 
> * expected result
> 
>   ===
>   # ./btrfs prop get /btrfs label
>   label=foo
>   # ./btrfs fi label /btrfs
>   foo
>   # ./btrfs fi label /btrfs bar
>   # ./btrfs prop get /btrfs label
>   label=bar
>   ===
> 
> Signed-off-by: Satoru Takeuchi <takeuchi_sat...@jp.fujitsu.com>

Applied, thanks.
--
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: Progress indicator when (slowly) mounting a btrfs filesystem?

[Christian Rohmann]

Hey Chris,

On 01/28/2016 12:47 AM, Chris Murphy wrote:
> Might be a bug, but more likely might be a lack of optimization. If it
> eventually mounts without errors that's a pretty good plus. Lots of
> file systems can't handle power failures well at all.

So what and how should I go about profiling such a long running mount in
order to help finding point where optimization is needed the most then?

Just as a side note: I don't think it's your own expectation to be like
all those other file systems ;-)


Regards

Christian
--
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: Progress indicator when (slowly) mounting a btrfs filesystem?

[Austin S. Hemmelgarn]

On 2016-02-01 09:03, Christian Rohmann wrote:

Hey Chris,

On 01/28/2016 12:47 AM, Chris Murphy wrote:

Might be a bug, but more likely might be a lack of optimization. If it
eventually mounts without errors that's a pretty good plus. Lots of
file systems can't handle power failures well at all.


So what and how should I go about profiling such a long running mount in
order to help finding point where optimization is needed the most then?
It would probably require some work with perf and ftrace, which means 
you likely need to build a special kernel just for testing, and then 
generate an ideally clean-room like environment (whatever hosting, plus 
userspace, plus a consistent filesystem image that you can reuse for 
each test, etc).


Kernel profiling is a decidedly non-trivial task, and is not something I 
would recommend somebody try unless both:
a) They already have a working knowledge of kernel internals, or are 
willing to learn.

b) They have the time and resources to do it right in a reproducible manner.
--
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

How to change BTRFS filesystem UUID

[Jiri Kanicky]

Hi,

I cloned several machines from the same disk and they all have same 
BTRFS filesystem UUID. I need to recovery one disk from failure, but if 
I attach two disks to the same machine, both disks have the same ID.


This seem to confuse UDEV, because /dev/disk/by-uuid seem to show just 
one link, not two links to two disks.


Is there a way to change the BTRFS ID (generate new one) that I can 
differentiate between the two disks on one host?


Thank you
Jiri

--
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: How to change BTRFS filesystem UUID

[Hugo Mills]

On Mon, Dec 28, 2015 at 01:31:26AM +1100, Jiri Kanicky wrote:
> Hi,
> 
> I cloned several machines from the same disk and they all have same
> BTRFS filesystem UUID. I need to recovery one disk from failure, but
> if I attach two disks to the same machine, both disks have the same
> ID.
> 
> This seem to confuse UDEV, because /dev/disk/by-uuid seem to show
> just one link, not two links to two disks.
> 
> Is there a way to change the BTRFS ID (generate new one) that I can
> differentiate between the two disks on one host?

   btrfstune, with -u or -U

   Hugo.

-- 
Hugo Mills | I think that everything darkling says is actually a
hugo@... carfax.org.uk | joke. It's just that we haven't worked out most of
http://carfax.org.uk/  | them yet.
PGP: E2AB1DE4  |Vashka


signature.asc
Description: Digital signature

Re: How to change BTRFS filesystem UUID

[Holger Hoffstätte]

On 12/27/15 15:31, Jiri Kanicky wrote:
> Is there a way to change the BTRFS ID (generate new one) that I can
> differentiate between the two disks on one host?

btrfstune:

-u
   Change fsid to a randomly generated UUID or continue previous
   fsid change operation in case it was interrupted.

should do what you need.

-h
--
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: How to change BTRFS filesystem UUID

[Jiri Kanicky]

Hi,

Thanks for the reply. Looks like I will have o use some newer distro. 
Debian Jessie rescue CD does not seem to have this. Anyway, i will play 
with this.


Thank you Jiri

On 28/12/2015 1:45 AM, Hugo Mills wrote:

On Mon, Dec 28, 2015 at 01:31:26AM +1100, Jiri Kanicky wrote:

Hi,

I cloned several machines from the same disk and they all have same
BTRFS filesystem UUID. I need to recovery one disk from failure, but
if I attach two disks to the same machine, both disks have the same
ID.

This seem to confuse UDEV, because /dev/disk/by-uuid seem to show
just one link, not two links to two disks.

Is there a way to change the BTRFS ID (generate new one) that I can
differentiate between the two disks on one host?

btrfstune, with -u or -U

Hugo.



--
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: How to change BTRFS filesystem UUID

[Duncan]

Jiri Kanicky posted on Mon, 28 Dec 2015 13:13:24 +1100 as excerpted:

> VM with BTRFS filesystem running on XenServer. The VM disk is a VHD
> stored on NFS storage. NFS storage ran out of space, and I found the
> BTRFS in RO mode. I could not remount it as RW after increasing the
> storage space. I rebooted the VM and the VM was not able to boot
> anymore. There were many lines during boot reporting "btrfs open_ctree
> failed" and the boot ended up in dracut mode.
> 
> I booted from CD and find out that I can mount the BTRFS filesystem and
> all data are there.

You did well. =:^)

Just in case you ever get into a situation where the btrfs will /not/ 
mount, however, there's an additional tool you can try to hopefully at 
least recover the data off of it, copying it to a new (possibly non-
btrfs) location from the unmounted filesystem.

btrfs restore

In addition to the btrfs-restore manpage, there's even a wiki page on it 
that has some "extraordinary measures" you can try if restore won't work 
by itself, using btrfs-find-root to hopefully find a usable previous root 
to feed to restore's -t option.  However, once you get to this level 
you're basically trying to reconstruct at least enough of a filesystem 
from historical bits and pieces as they may still be found on the device 
to be able to restore from, and it does get quite technical, so many 
people need help, and only some end up being able to restore most or all 
of their data, as often it's simply too damaged.

So the ideal is obviously to have backups if the data is important enough 
to you that you'd be jumping thru these hoops if you had to, and once you 
have backups, then restore becomes a tool to be used to possibly get a 
newer copy than your backup had, but no big deal if it fails as you /do/ 
have backups.  And at that point, you don't need to worry too much about 
the "extraordinary measures" stuff, because if it doesn't work with 
normal measures, then you just use the backup.

What's nice about btrfs-restore is that it works in read-only mode on the 
unmounted filesystem in question and thus won't cause any more damage.  
As a result, it's a good tool to use to try to get a current backup with 
if you don't have one, before trying seriously invasive procedures that 
if they don't fix the problem, could damage the filesystem further, 
rendering it impossible to get anything useful out of it.

Anyway, just pointing out the btrfs restore tool, as it's a very useful 
tool to have in your toolbox if a btrfs won't mount.  You will want to 
use a recent version of btrfs-progs, however, as btrfs restore has 
notably improved over time, with the last fix to it in 4.2.3, an off-by-
one fix to the symlink restoration code added in 4.0.1, and 4.0 added 
metadata (time/mode/uid/gid) restoration, where before that files were 
restored with the ownership (root) and umask of the btrfs restore process 
and had to be manually corrected.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
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: How to change BTRFS filesystem UUID

[Hugo Mills]

On Mon, Dec 28, 2015 at 12:01:39AM +0100, Christoph Anton Mitterer wrote:
> On Mon, 2015-12-28 at 02:27 +1100, Jiri Kanicky wrote:
> > Thanks for the reply. Looks like I will have o use some newer
> > distro. 
> As it was already said... btrfs may even corrupt your filesystem if
> colliding UUIDs are "seen".
> 
> At least to me it's currently unclear what "seen" exactly means...
> actually trying a mount, or already when just a device with colliding
> IDs appear.

   The damage happens on (or after) mount. Until that point there's no
danger.

   The OS (usually udev) will run btfs dev scan when a new block
device is detected, and it tells the kernel that there's a btrfs
filesystem with a particular UUID on a particular block device.

   The kernel uses this information to decide which devices to include
when it assembles a filesystem. If you have two devices where there
should be only one (particularly if the data on the two was similar
but has now diverged), then the kernel can end up writing to one or
other device arbitrarily, possibly having read state from the other
one, and things screw up rather fast.

   Hugo.

> So whenever you do your recovery works, make sure that there's never a
> moment where more than one btrfs block device appears with the same
> UUID.
> Even when it's just for some seconds it may already cause corruption.
> 
> 
> Cheers,
> Chris.



-- 
Hugo Mills | emacs: Eats Memory and Crashes.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4  |


signature.asc
Description: Digital signature

Re: How to change BTRFS filesystem UUID

[Duncan]

Hugo Mills posted on Sun, 27 Dec 2015 23:13:03 + as excerpted:

> On Mon, Dec 28, 2015 at 12:01:39AM +0100, Christoph Anton Mitterer
> wrote:
>> On Mon, 2015-12-28 at 02:27 +1100, Jiri Kanicky wrote:
>> > Thanks for the reply. Looks like I will have o use some newer distro.
>> As it was already said... btrfs may even corrupt your filesystem if
>> colliding UUIDs are "seen".
>> 
>> At least to me it's currently unclear what "seen" exactly means...
>> actually trying a mount, or already when just a device with colliding
>> IDs appear.
> 
>The damage happens on (or after) mount. Until that point there's no
> danger.
> 
>The OS (usually udev) will run btfs dev scan when a new block
> device is detected, and it tells the kernel that there's a btrfs
> filesystem with a particular UUID on a particular block device.
> 
>The kernel uses this information to decide which devices to include
> when it assembles a filesystem. If you have two devices where there
> should be only one (particularly if the data on the two was similar but
> has now diverged), then the kernel can end up writing to one or other
> device arbitrarily, possibly having read state from the other one, and
> things screw up rather fast.

This.  (Mostly repeating the above in different words to I'd like 
knowledgeable confirmation on activator 2 below, which is my own.  This 
sort of other-words repetition can help in reinforcing or understanding 
the concepts for some readers, while simply being annoying for others.  
YMMV.)

Two major triggers and an activator.

Triggers:

1) Btrfs device scan is the primary trigger.  Without this, btrfs will 
only know about either the device fed to it the mount command itself, or 
the devices listed in fstab, either in the device field, or as device= 
options.

2) The secondary trigger is often udev, which will normally run btrfs 
device scan automatically (due to udev rules often dropped into place by 
the btrfs-progs package, tho they may be included in the udev package 
itself or generic udev-rules packages in some distros), when the device 
is detected.

As a result of this secondary trigger, the btrfs will often know about 
the device at boot or as soon as it is attached, and it then becomes 
unsafe to have that UUID mounted.  This is where the "seen" comes in, 
with an assumption that a filesystem using that UUID is already mounted, 
and may be damaged as soon as udev triggers btrfs device scan and btrfs 
learns about the newly added device with the same filesystem UUID.

Activator(s):

1) Mount is the usual and primary activator.  Under normal circumstances, 
despite the triggers above if a btrfs with that UUID isn't mounted, no 
damage occurs as btrfs won't be writing to any of the devices containing 
a filesystem with that UUID.

2) Unsure on this one but I _believe_ various other btrfs userspace 
(btrfs-progs) commands that write to the unmounted filesystem either use 
the data provided by btrfs device scan or otherwise do similar scans as 
well.  In particular, btrfs check with --repair or --init-* will have to 
know about the multiple devices in the filesystem to properly do its 
work.  How it actually gets the list of devices is, however, unclear to 
me, tho my own experience with it seems to indicate that it's unnecessary 
to feed all the devices on the commandline and indeed, the manpage shows 
a single device, with no indication that feeding multiple devices on the 
commandline is even supported.  However, these sorts of commands only 
tend to be run very deliberately and under very specific circumstances, 
and thus are unlikely to be run when one is working with multiple images 
of a device that shouldn't be combined into the same filesystem.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
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: How to change BTRFS filesystem UUID

[Jiri Kanicky]

Hi,

Thanks for the detailed information. The data were not corrupted, so I 
could copy them to a new BTRFS partition.


Here is what happened exactly.

VM with BTRFS filesystem running on XenServer. The VM disk is a VHD 
stored on NFS storage. NFS storage ran out of space, and I found the 
BTRFS in RO mode. I could not remount it as RW after increasing the 
storage space. I rebooted the VM and the VM was not able to boot 
anymore. There were many lines during boot reporting "btrfs open_ctree 
failed" and the boot ended up in dracut mode.


I booted from CD and find out that I can mount the BTRFS filesystem and 
all data are there.


I created a new disk with BTRFS filesystem, copied all the data on it, 
and that new disk booted fine. (I actually used a disk from my template, 
so that is where the same BTRFS UUID comes from. But this was not the 
real issue. I copied the data on EXT4 disk first and then to the new 
disk to avoid having same BTRFS UUIDs. I will try changing the UUIDs as 
suggested later.)


In summary, I think that BTRFS was not able to recover from the scenario 
explained above. VMs with EXT4 could boot normally.


Regards,
Jiri


On 28/12/2015 10:13 AM, Hugo Mills wrote:

On Mon, Dec 28, 2015 at 12:01:39AM +0100, Christoph Anton Mitterer wrote:

On Mon, 2015-12-28 at 02:27 +1100, Jiri Kanicky wrote:

Thanks for the reply. Looks like I will have o use some newer
distro.

As it was already said... btrfs may even corrupt your filesystem if
colliding UUIDs are "seen".

At least to me it's currently unclear what "seen" exactly means...
actually trying a mount, or already when just a device with colliding
IDs appear.

The damage happens on (or after) mount. Until that point there's no
danger.

The OS (usually udev) will run btfs dev scan when a new block
device is detected, and it tells the kernel that there's a btrfs
filesystem with a particular UUID on a particular block device.

The kernel uses this information to decide which devices to include
when it assembles a filesystem. If you have two devices where there
should be only one (particularly if the data on the two was similar
but has now diverged), then the kernel can end up writing to one or
other device arbitrarily, possibly having read state from the other
one, and things screw up rather fast.

Hugo.


So whenever you do your recovery works, make sure that there's never a
moment where more than one btrfs block device appears with the same
UUID.
Even when it's just for some seconds it may already cause corruption.


Cheers,
Chris.





--
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: How to change BTRFS filesystem UUID

[Christoph Anton Mitterer]

On Mon, 2015-12-28 at 02:27 +1100, Jiri Kanicky wrote:
> Thanks for the reply. Looks like I will have o use some newer
> distro. 
As it was already said... btrfs may even corrupt your filesystem if
colliding UUIDs are "seen".

At least to me it's currently unclear what "seen" exactly means...
actually trying a mount, or already when just a device with colliding
IDs appear.

So whenever you do your recovery works, make sure that there's never a
moment where more than one btrfs block device appears with the same
UUID.
Even when it's just for some seconds it may already cause corruption.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

[Marc Haber]

On Mon, Nov 30, 2015 at 05:44:23AM +, Duncan wrote:
> Yes, you can get dup metadata back, but because data and metadata
> are now combined in the same blockgroups (aka chunks), they must
> both be the same replication type.

Thanks for this explanation, it's perfectly clear to me now.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
--
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: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

[Marc Haber]

Hi Hugo,

On Sun, Nov 29, 2015 at 02:18:06PM +, Hugo Mills wrote:
> On Sun, Nov 29, 2015 at 02:07:54PM +0100, Marc Haber wrote:
> > However, the FAQ
> > https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21
> > suggests that for small filesystems (<16 GB), the best solution would
> > be to upgrade to at least 2.6.37 and recreate the filesystem. 2.6.37
> > is ancient, from 2011, so I am pretty sure that the filesystem _was_
> > created at least with a kernel more recent than that.
> 
>You missed the most important thing from that paragraph: Use mixed
> block groups. That's "mkfs.btrfs --mixed ..." (which I realise is
> missing from the text, and I'll be adding it after I send this email).

Yes, that was the important bit of missing information. My filesystem
now reads:

[26/512]mh@fan:/mnt/tempdisk$ df -h .
Filesystem   Size  Used Avail Use% Mounted on
/dev/mapper/banana-root  6,0G  836M  5,2G  14% /mnt/tempdisk
[27/513]mh@fan:/mnt/tempdisk$ sudo btrfs fi show .
Label: none  uuid: b2906231-70a9-46d9-9830-38a13cb73171
Total devices 1 FS bytes used 861.29MiB
devid1 size 6.00GiB used 6.00GiB path /dev/mapper/banana-root

btrfs-progs v4.3
[28/514]mh@fan:/mnt/tempdisk$ sudo btrfs fi df .
System, single: total=4.00MiB, used=4.00KiB
Data+Metadata, single: total=6.00GiB, used=861.29MiB
GlobalReserve, single: total=20.00MiB, used=0.00B
[29/515]mh@fan:/mnt/tempdisk$

Can I somehow get duplicate metadata back? Or is that unnecessary?

> > My normal way to recover from this situation is to btrfs add a new
> > device, btrfs balance, btrfs --convert=single --force balance, btfs
> > device remove, btr balance start -mconvert=dup --force and finally
> > balance start again.
> > 
> > Is there any solution to solve this more elegantly?
> 
>Recreate the FS with --mixed, and that should deal with it.

Done. Thanks!

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
--
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: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

[Hugo Mills]

On Sun, Nov 29, 2015 at 02:07:54PM +0100, Marc Haber wrote:
> Hi,
> 
> I have a banana pi with a btrfs filesystem of 5 GB in size, which
> frequently runs out of space (lots of snapshots). This is currently
> again the case:
> 
> [27/524]mh@banana:~$ sudo btrfs balance start /
> ERROR: error during balancing '/' - No space left on device
> There may be more info in syslog - try dmesg | tail
> [28/525]mh@banana:~$ sudo btrfs balance start / -dlimit=3
> [sudo] password for mh on banana:
> ERROR: error during balancing '/' - No space left on device
> There may be more info in syslog - try dmesg | tail
> [29/526]mh@banana:~$ sudo btrfs balance start / -dlimit=3
> ERROR: error during balancing '/' - No space left on device
> There may be more info in syslog - try dmesg | tail
> [30/526]mh@banana:~$ sudo btrfs balance start / -dusage=0
> Done, had to relocate 0 out of 8 chunks
> [31/527]mh@banana:~$ sudo btrfs balance start / -dlimit=3
> ERROR: error during balancing '/' - No space left on device
> There may be more info in syslog - try dmesg | tail
> [32/528]mh@banana:~$ sudo btrfs fi show /
> Label: none  uuid: ada6b7f5-98d6-4fee-a3a3-b73bd152ff6c
> Total devices 1 FS bytes used 3.37GiB
> devid1 size 6.89GiB used 4.22GiB path /dev/mapper/banana-root
> 
> btrfs-progs v4.3
> [33/529]mh@banana:~$ sudo btrfs fi df /
> Data, single: total=3.41GiB, used=3.25GiB
> System, DUP: total=32.00MiB, used=16.00KiB
> Metadata, DUP: total=384.00MiB, used=121.75MiB
> GlobalReserve, single: total=48.00MiB, used=0.00B
> [34/530]mh@banana:~$ uname -a
> Linux banana 4.3.0-zgbpi-armmp-lpae+ #2 SMP Sat Nov 7 13:07:34 UTC 2015 
> armv7l GNU/Linux
> [36/532]mh@banana:~$ df -h /
> Filesystem   Size  Used Avail Use% Mounted on
> /dev/mapper/banana-root  6.9G  3.6G  2.9G  56% /
> [37/533]mh@banana:~$
> 
> The first kernel that was ever booted on the device was 4.1, I am
> therefore reasonably sure that the filesystem was also created with a
> recent kernel. Is there any possibility to find out about the kernel
> version that a filesystem was created with?
> 
> However, the FAQ
> https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21
> suggests that for small filesystems (<16 GB), the best solution would
> be to upgrade to at least 2.6.37 and recreate the filesystem. 2.6.37
> is ancient, from 2011, so I am pretty sure that the filesystem _was_
> created at least with a kernel more recent than that.

   You missed the most important thing from that paragraph: Use mixed
block groups. That's "mkfs.btrfs --mixed ..." (which I realise is
missing from the text, and I'll be adding it after I send this email).

> My normal way to recover from this situation is to btrfs add a new
> device, btrfs balance, btrfs --convert=single --force balance, btfs
> device remove, btr balance start -mconvert=dup --force and finally
> balance start again.
> 
> Is there any solution to solve this more elegantly?

   Recreate the FS with --mixed, and that should deal with it.

   Hugo.

-- 
Hugo Mills | There isn't a noun that can't be verbed.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4  |


signature.asc
Description: Digital signature

"disk full" on a 5 GB btrfs filesystem, FAQ outdated?

[Marc Haber]

Hi,

I have a banana pi with a btrfs filesystem of 5 GB in size, which
frequently runs out of space (lots of snapshots). This is currently
again the case:

[27/524]mh@banana:~$ sudo btrfs balance start /
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
[28/525]mh@banana:~$ sudo btrfs balance start / -dlimit=3
[sudo] password for mh on banana:
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
[29/526]mh@banana:~$ sudo btrfs balance start / -dlimit=3
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
[30/526]mh@banana:~$ sudo btrfs balance start / -dusage=0
Done, had to relocate 0 out of 8 chunks
[31/527]mh@banana:~$ sudo btrfs balance start / -dlimit=3
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
[32/528]mh@banana:~$ sudo btrfs fi show /
Label: none  uuid: ada6b7f5-98d6-4fee-a3a3-b73bd152ff6c
Total devices 1 FS bytes used 3.37GiB
devid1 size 6.89GiB used 4.22GiB path /dev/mapper/banana-root

btrfs-progs v4.3
[33/529]mh@banana:~$ sudo btrfs fi df /
Data, single: total=3.41GiB, used=3.25GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=384.00MiB, used=121.75MiB
GlobalReserve, single: total=48.00MiB, used=0.00B
[34/530]mh@banana:~$ uname -a
Linux banana 4.3.0-zgbpi-armmp-lpae+ #2 SMP Sat Nov 7 13:07:34 UTC 2015 armv7l 
GNU/Linux
[36/532]mh@banana:~$ df -h /
Filesystem   Size  Used Avail Use% Mounted on
/dev/mapper/banana-root  6.9G  3.6G  2.9G  56% /
[37/533]mh@banana:~$

The first kernel that was ever booted on the device was 4.1, I am
therefore reasonably sure that the filesystem was also created with a
recent kernel. Is there any possibility to find out about the kernel
version that a filesystem was created with?

However, the FAQ
https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21
suggests that for small filesystems (<16 GB), the best solution would
be to upgrade to at least 2.6.37 and recreate the filesystem. 2.6.37
is ancient, from 2011, so I am pretty sure that the filesystem _was_
created at least with a kernel more recent than that.

My normal way to recover from this situation is to btrfs add a new
device, btrfs balance, btrfs --convert=single --force balance, btfs
device remove, btr balance start -mconvert=dup --force and finally
balance start again.

Is there any solution to solve this more elegantly?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
--
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: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

[Duncan]

Marc Haber posted on Sun, 29 Nov 2015 19:06:29 +0100 as excerpted:

> Hi Hugo,
> 
> On Sun, Nov 29, 2015 at 02:18:06PM +, Hugo Mills wrote:
>> On Sun, Nov 29, 2015 at 02:07:54PM +0100, Marc Haber wrote:

>>> However, the FAQ
>>> https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21
>>> suggests that for small filesystems (<16 GB), the best solution [...]
>> 
>> You missed the most important thing from that paragraph: Use mixed
>> block groups. That's "mkfs.btrfs --mixed ..." [...]
> 
> Yes, that was the important bit of missing information. My filesystem
> now reads:
> 
> $ df -h .
> Filesystem   Size  Used Avail Use% Mounted on
> /dev/mapper/banana-root  6,0G  836M  5,2G  14% /mnt/tempdisk
> [27/513]mh@fan:/mnt/tempdisk$ sudo btrfs fi show .
> Label: none  uuid: b2906231-70a9-46d9-9830-38a13cb73171
> Total devices 1 FS bytes used 861.29MiB
> devid  1 size 6.00GiB used 6.00GiB path /dev/mapper/banana-root
> 
> btrfs-progs v4.3
> $ sudo btrfs fi df .
> System, single: total=4.00MiB, used=4.00KiB
> Data+Metadata, single: total=6.00GiB, used=861.29MiB
> GlobalReserve, single: total=20.00MiB, used=0.00B
> $
> 
> Can I somehow get duplicate metadata back? Or is that unnecessary?

Define "necessary"...

Yes, you can get dup metadata back, but because data and metadata
are now combined in the same blockgroups (aka chunks), they must
both be the same replication type.

So with --mixed, if you go dup, you get dup data and metadata both,
which means halving the data you can actually store, since it's
stored twice.

Which means... 6 GiB btrfs... less than 3 GiB data storage if you go
mixed dup mode.  If say 2.5 GiB (you'll probably get a bit more but...)
is enough room to do what you need to do with it, I'd say go for
dup, as it /should/ be incrementally more reliable for you.  Obviously,
if it's not going to be enough room, you better stay single data,
which means either staying mixed and single metadata as well, or
switching back to unmixed so you can do dup metadata and still do
single data.

Dup, when it works /as/ dup, gives you two copies.  That's useful
if one copy goes bad while the other is still good, but it's
obviously not as reliable as raid1, two copies, each on different
devices, would be.  Meanwhile, various ssds do firmware level
deduplication and turn your two copies back into only one on the
physical device.  That shouldn't waste space as the device
shouldn't actually take space for deduped copies, but it will
then uselessly spend time processing that second copy, to no
benefit since the firmware second guessed you and deduped, and
if that now one copy goes bad, it's bad no matter which of the
two filesystem level pointers to it you try to read.

So dup /should/ be incrementally more reliable, /provided/ you're
actually getting dup, without the firmware or some other level
second-guessing you.

But tho I'm not personally familiar with the banana-pie, I'd guess
that the storage is emmc or the like, and likely doesn't have
firmware with that level of sophistication, so you're likely
to still have dup.

Meanwhile, in theory you could use the compress-force=zlib
mount option to squeeze a bit more space out of that dup,
letting you store somewhat more than 3 GiB of data, depending
on how zlib-compressible it is.  But I'd guess the CPU does
better on cost and performance per watt than on raw performance,
and compression, particularly zlib, is likely to slow things
down sufficiently badly that it's not going to be tolerable.
Still, you could try it, and if you're close on the data size
and performance does end up being tolerable, that just might
let you do dup, where you couldn't, otherwise.

Of course you can also try compress-force(=lzo the default
compression so the =spec isn't required), which should give
you slightly better performance than zlib, but also a bit
less efficient compression in terms of size saved.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
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: "disk full" on a 5 GB btrfs filesystem, FAQ outdated?

[Imran Geriskovan]

On 11/30/15, Duncan <1i5t5.dun...@cox.net> wrote:
> Of course you can also try compress-force(=lzo the default
> compression so the =spec isn't required), which should give
> you slightly better performance than zlib, but also a bit
> less efficient compression in terms of size saved.

lzo perf relative to zlib (A very very rough comparison)

Compress/Decompress times: 1/3 - 1/2 (which is significant)
Output Size: %10-20 larger
--
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

[PATCH 02/11] btrfs-progs: filesystem: use btrfs_open_dir for btrfs filesystem command

[Zhao Lei]

We can use btrfs_open_dir() to check whether target dir is
in btrfs's mount point before open, instead of checking it in
kernel space of ioctl, and return fuzzy error message.

Before patch:
  # (/mnt/tmp is not btrfs mountpoint)
  #
  # btrfs filesystem df /mnt/tmp
  ERROR: couldn't get space info - Inappropriate ioctl for device
  ERROR: get_df failed Inappropriate ioctl for device
  #

After patch:
  # ./btrfs filesystem df /mnt/tmp
  ERROR: not btrfs filesystem: /mnt/tmp
  #

Signed-off-by: Zhao Lei <zhao...@cn.fujitsu.com>
---
 cmds-fi-usage.c   |  4 +---
 cmds-filesystem.c | 19 +++
 2 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/cmds-fi-usage.c b/cmds-fi-usage.c
index 50d6333..5fefed4 100644
--- a/cmds-fi-usage.c
+++ b/cmds-fi-usage.c
@@ -901,10 +901,8 @@ int cmd_filesystem_usage(int argc, char **argv)
int chunkcount = 0;
int devcount = 0;
 
-   fd = open_file_or_dir(argv[i], );
+   fd = btrfs_open_dir(argv[i], , 1);
if (fd < 0) {
-   fprintf(stderr, "ERROR: can't access '%s'\n",
-   argv[i]);
ret = 1;
goto out;
}
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 3663734..91bf1fa 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -205,11 +205,10 @@ static int cmd_filesystem_df(int argc, char **argv)
 
path = argv[1];
 
-   fd = open_file_or_dir(path, );
-   if (fd < 0) {
-   fprintf(stderr, "ERROR: can't access '%s'\n", path);
+   fd = btrfs_open_dir(path, , 1);
+   if (fd < 0)
return 1;
-   }
+
ret = get_df(fd, );
 
if (ret == 0) {
@@ -939,11 +938,9 @@ static int cmd_filesystem_sync(int argc, char **argv)
 
path = argv[1];
 
-   fd = open_file_or_dir(path, );
-   if (fd < 0) {
-   fprintf(stderr, "ERROR: can't access '%s'\n", path);
+   fd = btrfs_open_dir(path, , 1);
+   if (fd < 0)
return 1;
-   }
 
printf("FSSync '%s'\n", path);
res = ioctl(fd, BTRFS_IOC_SYNC);
@@ -1229,11 +1226,9 @@ static int cmd_filesystem_resize(int argc, char **argv)
return 1;
}
 
-   fd = open_file_or_dir(path, );
-   if (fd < 0) {
-   fprintf(stderr, "ERROR: can't access '%s'\n", path);
+   fd = btrfs_open_dir(path, , 1);
+   if (fd < 0)
return 1;
-   }
 
printf("Resize '%s' of '%s'\n", path, amount);
memset(, 0, sizeof(args));
-- 
1.8.5.1

--
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

[PATCH v3 0/2] btrfs-progs: Use common unit parser for btrfs filesystem command

[Zhao Lei]

Changelog v2->v3:
 Fix lacking of -T option in v2, pointed out by:
 David Sterba <dste...@suse.cz>

Changelog v1->v2:
 Keep short options for 'fi df' command, to keeps option compatibility
 with the standalone 'df' commmand, suggested-by:
 David Sterba <dste...@suse.cz>

Signed-off-by: Zhao Lei <zhao...@cn.fujitsu.com>

Zhao Lei (2):
  btrfs-progs: Use common unit parser for btrfs filesystem command
  btrfs-progs: Update manual for new unit arguments

 Documentation/btrfs-device.asciidoc |  14 ++--
 Documentation/btrfs-filesystem.asciidoc |  14 ++--
 cmds-fi-usage.c |  63 +++--
 cmds-filesystem.c   | 121 
 4 files changed, 32 insertions(+), 180 deletions(-)

-- 
1.8.5.1

--
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: [PATCH v3 1/2] btrfs-progs: Use common unit parser for btrfs filesystem command

[David Sterba]

On Tue, Sep 01, 2015 at 03:12:06PM +0800, Zhao Lei wrote:
> Move to use get_unit_mode_from_arg() for cmds-filesystem.c,
> to make "btrfs filesystem df/show/usage"'s unit argument same.
> 
> Also have cleanup effect: 19 insertions(+), 181 deletions(-)
> 
> Signed-off-by: Zhao Lei <zhao...@cn.fujitsu.com>

Applied, thanks.

> ---
>  cmds-fi-usage.c   |  63 
>  cmds-filesystem.c | 121 
> ++
>  2 files changed, 20 insertions(+), 164 deletions(-)
> 
> diff --git a/cmds-fi-usage.c b/cmds-fi-usage.c
> index adf1c27..ea967d1 100644
> --- a/cmds-fi-usage.c
> +++ b/cmds-fi-usage.c
> @@ -859,76 +859,29 @@ out:
>  const char * const cmd_filesystem_usage_usage[] = {
>   "btrfs filesystem usage [options]  [..]",
>   "Show detailed information about internal filesystem usage .",
> - "-b|--raw   raw numbers in bytes",
> - "-h|--human-readable",
> - "   human friendly numbers, base 1024 (default)",
> - "-H human friendly numbers, base 1000",
> - "--iec  use 1024 as a base (KiB, MiB, GiB, TiB)",
> - "--si   use 1000 as a base (kB, MB, GB, TB)",
> - "-k|--kbytesshow sizes in KiB, or kB with --si",
> - "-m|--mbytesshow sizes in MiB, or MB with --si",
> - "-g|--gbytesshow sizes in GiB, or GB with --si",
> - "-t|--tbytesshow sizes in TiB, or TB with --si",
> + HELPINFO_OUTPUT_UNIT,

HELPINFO_OUTPUT_UNIT_DF
--
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