Btrfs hangs 3.19-10

Btrfs hangs 3.19-10

[Timofey Titovets]

I've get it several times, after rebooting or unclean shutdown system.

This is very strange bug, because if i reboot, and mount it from live
cd, all that okay, and after reboot in system, system successful mount
all and working good.
i did try to found any previous issues on it, and found nothing.


[  240.100043] INFO: task mount:485 blocked for more than 120 seconds.
[  240.100156]       Not tainted 3.19.0-10-generic #10-Ubuntu
[  240.100244] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  240.100359] mount           D ffff88009e907818     0   485      1 0x00000004
[  240.100364]  ffff88009e907818 ffff8804473ac4b0 0000000000014200
ffff88009e907fd8
[  240.100368]  0000000000014200 ffff88044ae3f5c0 ffff8804473ac4b0
ffff88009e907828
[  240.100371]  ffff88045d073c70 ffff88045d073cd8 ffff88045d073cf0
ffff88009e907858
[  240.100374] Call Trace:
[  240.100386]  [<ffffffff817c38e9>] schedule+0x29/0x70
[  240.100427]  [<ffffffffc050a7e5>] btrfs_tree_lock+0x55/0x1f0 [btrfs]
[  240.100432]  [<ffffffff810b6200>] ? wait_woken+0x90/0x90
[  240.100444]  [<ffffffffc04acc69>] btrfs_search_slot+0x709/0xa60 [btrfs]
[  240.100457]  [<ffffffffc04ae8ad>] btrfs_insert_empty_items+0x7d/0xd0 [btrfs]
[  240.100469]  [<ffffffffc04a78aa>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
[  240.100487]  [<ffffffffc050aab8>] btrfs_insert_orphan_item+0x58/0x80 [btrfs]
[  240.100509]  [<ffffffffc050c04e>] insert_orphan_item+0x5e/0x90 [btrfs]
[  240.100529]  [<ffffffffc0510d11>] replay_one_buffer+0x351/0x370 [btrfs]
[  240.100547]  [<ffffffffc050b991>] walk_up_log_tree+0xd1/0x240 [btrfs]
[  240.100558]  [<ffffffffc04a78aa>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
[  240.100577]  [<ffffffffc050bb9b>] walk_log_tree+0x9b/0x1a0 [btrfs]
[  240.100596]  [<ffffffffc0513214>] btrfs_recover_log_trees+0x1d4/0x470 [btrfs]
[  240.100614]  [<ffffffffc05109c0>] ? replay_one_extent+0x6b0/0x6b0 [btrfs]
[  240.100630]  [<ffffffffc04ceb23>] open_ctree+0x1813/0x2090 [btrfs]
[  240.100642]  [<ffffffffc04a4b00>] btrfs_mount+0x850/0x920 [btrfs]
[  240.100649]  [<ffffffff811f7208>] mount_fs+0x38/0x1c0
[  240.100653]  [<ffffffff8119b5e5>] ? __alloc_percpu+0x15/0x20
[  240.100658]  [<ffffffff812138fb>] vfs_kern_mount+0x6b/0x120
[  240.100662]  [<ffffffff81216754>] do_mount+0x204/0xb20
[  240.100665]  [<ffffffff8121738b>] SyS_mount+0x8b/0xd0
[  240.100669]  [<ffffffff817c824d>] system_call_fastpath+0x16/0x1b
[  240.100676] INFO: task btrfs-transacti:506 blocked for more than 120 seconds.
[  240.100780]       Not tainted 3.19.0-10-generic #10-Ubuntu
[  240.100869] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  240.100982] btrfs-transacti D ffff8804474abdc8     0   506      2 0x00000000
[  240.100986]  ffff8804474abdc8 ffff88009ef83ae0 0000000000014200
ffff8804474abfd8
[  240.100989]  0000000000014200 ffffffff81c1a580 ffff88009ef83ae0
ffff8804474abdd8
[  240.100992]  ffff880448695000 ffff88045d396000 ffff88045d33afc0
ffff8804474abe00
[  240.100995] Call Trace:
[  240.100998]  [<ffffffff817c38e9>] schedule+0x29/0x70
[  240.101018]  [<ffffffffc04d14c5>]
btrfs_commit_transaction+0x375/0xa40 [btrfs]
[  240.101021]  [<ffffffff810b6200>] ? wait_woken+0x90/0x90
[  240.101037]  [<ffffffffc04ccf5d>] transaction_kthread+0x1dd/0x250 [btrfs]
[  240.101052]  [<ffffffffc04ccd80>] ?
btrfs_cleanup_transaction+0x550/0x550 [btrfs]
[  240.101057]  [<ffffffff81094679>] kthread+0xc9/0xe0
[  240.101061]  [<ffffffff810945b0>] ? kthread_create_on_node+0x1c0/0x1c0
[  240.101064]  [<ffffffff817c8198>] ret_from_fork+0x58/0x90
[  240.101067]  [<ffffffff810945b0>] ? kthread_create_on_node+0x1c0/0x1c0

-- 
Have a nice day,
Timofey.

Re: Btrfs hangs 3.19-10

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 4189 bytes --]

On Thu, Apr 02, 2015 at 02:38:24PM +0300, Timofey Titovets wrote:
> I've get it several times, after rebooting or unclean shutdown system.
> 
> This is very strange bug, because if i reboot, and mount it from live
> cd, all that okay, and after reboot in system, system successful mount
> all and working good.
> i did try to found any previous issues on it, and found nothing.

   Try 4.0-rc6, which should have the fix for the problem in it. This
was introduced in the stable series, and is now fixed in mainline. It
should also be fixed in the next stable release, I believe.

   Hugo.

> [  240.100043] INFO: task mount:485 blocked for more than 120 seconds.
> [  240.100156]       Not tainted 3.19.0-10-generic #10-Ubuntu
> [  240.100244] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  240.100359] mount           D ffff88009e907818     0   485      1 0x00000004
> [  240.100364]  ffff88009e907818 ffff8804473ac4b0 0000000000014200
> ffff88009e907fd8
> [  240.100368]  0000000000014200 ffff88044ae3f5c0 ffff8804473ac4b0
> ffff88009e907828
> [  240.100371]  ffff88045d073c70 ffff88045d073cd8 ffff88045d073cf0
> ffff88009e907858
> [  240.100374] Call Trace:
> [  240.100386]  [<ffffffff817c38e9>] schedule+0x29/0x70
> [  240.100427]  [<ffffffffc050a7e5>] btrfs_tree_lock+0x55/0x1f0 [btrfs]
> [  240.100432]  [<ffffffff810b6200>] ? wait_woken+0x90/0x90
> [  240.100444]  [<ffffffffc04acc69>] btrfs_search_slot+0x709/0xa60 [btrfs]
> [  240.100457]  [<ffffffffc04ae8ad>] btrfs_insert_empty_items+0x7d/0xd0 [btrfs]
> [  240.100469]  [<ffffffffc04a78aa>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
> [  240.100487]  [<ffffffffc050aab8>] btrfs_insert_orphan_item+0x58/0x80 [btrfs]
> [  240.100509]  [<ffffffffc050c04e>] insert_orphan_item+0x5e/0x90 [btrfs]
> [  240.100529]  [<ffffffffc0510d11>] replay_one_buffer+0x351/0x370 [btrfs]
> [  240.100547]  [<ffffffffc050b991>] walk_up_log_tree+0xd1/0x240 [btrfs]
> [  240.100558]  [<ffffffffc04a78aa>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
> [  240.100577]  [<ffffffffc050bb9b>] walk_log_tree+0x9b/0x1a0 [btrfs]
> [  240.100596]  [<ffffffffc0513214>] btrfs_recover_log_trees+0x1d4/0x470 [btrfs]
> [  240.100614]  [<ffffffffc05109c0>] ? replay_one_extent+0x6b0/0x6b0 [btrfs]
> [  240.100630]  [<ffffffffc04ceb23>] open_ctree+0x1813/0x2090 [btrfs]
> [  240.100642]  [<ffffffffc04a4b00>] btrfs_mount+0x850/0x920 [btrfs]
> [  240.100649]  [<ffffffff811f7208>] mount_fs+0x38/0x1c0
> [  240.100653]  [<ffffffff8119b5e5>] ? __alloc_percpu+0x15/0x20
> [  240.100658]  [<ffffffff812138fb>] vfs_kern_mount+0x6b/0x120
> [  240.100662]  [<ffffffff81216754>] do_mount+0x204/0xb20
> [  240.100665]  [<ffffffff8121738b>] SyS_mount+0x8b/0xd0
> [  240.100669]  [<ffffffff817c824d>] system_call_fastpath+0x16/0x1b
> [  240.100676] INFO: task btrfs-transacti:506 blocked for more than 120 seconds.
> [  240.100780]       Not tainted 3.19.0-10-generic #10-Ubuntu
> [  240.100869] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  240.100982] btrfs-transacti D ffff8804474abdc8     0   506      2 0x00000000
> [  240.100986]  ffff8804474abdc8 ffff88009ef83ae0 0000000000014200
> ffff8804474abfd8
> [  240.100989]  0000000000014200 ffffffff81c1a580 ffff88009ef83ae0
> ffff8804474abdd8
> [  240.100992]  ffff880448695000 ffff88045d396000 ffff88045d33afc0
> ffff8804474abe00
> [  240.100995] Call Trace:
> [  240.100998]  [<ffffffff817c38e9>] schedule+0x29/0x70
> [  240.101018]  [<ffffffffc04d14c5>]
> btrfs_commit_transaction+0x375/0xa40 [btrfs]
> [  240.101021]  [<ffffffff810b6200>] ? wait_woken+0x90/0x90
> [  240.101037]  [<ffffffffc04ccf5d>] transaction_kthread+0x1dd/0x250 [btrfs]
> [  240.101052]  [<ffffffffc04ccd80>] ?
> btrfs_cleanup_transaction+0x550/0x550 [btrfs]
> [  240.101057]  [<ffffffff81094679>] kthread+0xc9/0xe0
> [  240.101061]  [<ffffffff810945b0>] ? kthread_create_on_node+0x1c0/0x1c0
> [  240.101064]  [<ffffffff817c8198>] ret_from_fork+0x58/0x90
> [  240.101067]  [<ffffffff810945b0>] ? kthread_create_on_node+0x1c0/0x1c0
> 

-- 
Hugo Mills             | Great oxymorons of the world, no. 10:
hugo@... carfax.org.uk | Business Ethics
http://carfax.org.uk/  |
PGP: 65E74AC0          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Btrfs hangs 3.19-10

[Timofey Titovets]

So cool, thanks Hugo :)

2015-04-02 14:46 GMT+03:00 Hugo Mills <hugo@carfax.org.uk>:
> On Thu, Apr 02, 2015 at 02:38:24PM +0300, Timofey Titovets wrote:
>> I've get it several times, after rebooting or unclean shutdown system.
>>
>> This is very strange bug, because if i reboot, and mount it from live
>> cd, all that okay, and after reboot in system, system successful mount
>> all and working good.
>> i did try to found any previous issues on it, and found nothing.
>
>    Try 4.0-rc6, which should have the fix for the problem in it. This
> was introduced in the stable series, and is now fixed in mainline. It
> should also be fixed in the next stable release, I believe.
>
>    Hugo.
>
>> [  240.100043] INFO: task mount:485 blocked for more than 120 seconds.
>> [  240.100156]       Not tainted 3.19.0-10-generic #10-Ubuntu
>> [  240.100244] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [  240.100359] mount           D ffff88009e907818     0   485      1 0x00000004
>> [  240.100364]  ffff88009e907818 ffff8804473ac4b0 0000000000014200
>> ffff88009e907fd8
>> [  240.100368]  0000000000014200 ffff88044ae3f5c0 ffff8804473ac4b0
>> ffff88009e907828
>> [  240.100371]  ffff88045d073c70 ffff88045d073cd8 ffff88045d073cf0
>> ffff88009e907858
>> [  240.100374] Call Trace:
>> [  240.100386]  [<ffffffff817c38e9>] schedule+0x29/0x70
>> [  240.100427]  [<ffffffffc050a7e5>] btrfs_tree_lock+0x55/0x1f0 [btrfs]
>> [  240.100432]  [<ffffffff810b6200>] ? wait_woken+0x90/0x90
>> [  240.100444]  [<ffffffffc04acc69>] btrfs_search_slot+0x709/0xa60 [btrfs]
>> [  240.100457]  [<ffffffffc04ae8ad>] btrfs_insert_empty_items+0x7d/0xd0 [btrfs]
>> [  240.100469]  [<ffffffffc04a78aa>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
>> [  240.100487]  [<ffffffffc050aab8>] btrfs_insert_orphan_item+0x58/0x80 [btrfs]
>> [  240.100509]  [<ffffffffc050c04e>] insert_orphan_item+0x5e/0x90 [btrfs]
>> [  240.100529]  [<ffffffffc0510d11>] replay_one_buffer+0x351/0x370 [btrfs]
>> [  240.100547]  [<ffffffffc050b991>] walk_up_log_tree+0xd1/0x240 [btrfs]
>> [  240.100558]  [<ffffffffc04a78aa>] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
>> [  240.100577]  [<ffffffffc050bb9b>] walk_log_tree+0x9b/0x1a0 [btrfs]
>> [  240.100596]  [<ffffffffc0513214>] btrfs_recover_log_trees+0x1d4/0x470 [btrfs]
>> [  240.100614]  [<ffffffffc05109c0>] ? replay_one_extent+0x6b0/0x6b0 [btrfs]
>> [  240.100630]  [<ffffffffc04ceb23>] open_ctree+0x1813/0x2090 [btrfs]
>> [  240.100642]  [<ffffffffc04a4b00>] btrfs_mount+0x850/0x920 [btrfs]
>> [  240.100649]  [<ffffffff811f7208>] mount_fs+0x38/0x1c0
>> [  240.100653]  [<ffffffff8119b5e5>] ? __alloc_percpu+0x15/0x20
>> [  240.100658]  [<ffffffff812138fb>] vfs_kern_mount+0x6b/0x120
>> [  240.100662]  [<ffffffff81216754>] do_mount+0x204/0xb20
>> [  240.100665]  [<ffffffff8121738b>] SyS_mount+0x8b/0xd0
>> [  240.100669]  [<ffffffff817c824d>] system_call_fastpath+0x16/0x1b
>> [  240.100676] INFO: task btrfs-transacti:506 blocked for more than 120 seconds.
>> [  240.100780]       Not tainted 3.19.0-10-generic #10-Ubuntu
>> [  240.100869] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [  240.100982] btrfs-transacti D ffff8804474abdc8     0   506      2 0x00000000
>> [  240.100986]  ffff8804474abdc8 ffff88009ef83ae0 0000000000014200
>> ffff8804474abfd8
>> [  240.100989]  0000000000014200 ffffffff81c1a580 ffff88009ef83ae0
>> ffff8804474abdd8
>> [  240.100992]  ffff880448695000 ffff88045d396000 ffff88045d33afc0
>> ffff8804474abe00
>> [  240.100995] Call Trace:
>> [  240.100998]  [<ffffffff817c38e9>] schedule+0x29/0x70
>> [  240.101018]  [<ffffffffc04d14c5>]
>> btrfs_commit_transaction+0x375/0xa40 [btrfs]
>> [  240.101021]  [<ffffffff810b6200>] ? wait_woken+0x90/0x90
>> [  240.101037]  [<ffffffffc04ccf5d>] transaction_kthread+0x1dd/0x250 [btrfs]
>> [  240.101052]  [<ffffffffc04ccd80>] ?
>> btrfs_cleanup_transaction+0x550/0x550 [btrfs]
>> [  240.101057]  [<ffffffff81094679>] kthread+0xc9/0xe0
>> [  240.101061]  [<ffffffff810945b0>] ? kthread_create_on_node+0x1c0/0x1c0
>> [  240.101064]  [<ffffffff817c8198>] ret_from_fork+0x58/0x90
>> [  240.101067]  [<ffffffff810945b0>] ? kthread_create_on_node+0x1c0/0x1c0
>>
>
> --
> Hugo Mills             | Great oxymorons of the world, no. 10:
> hugo@... carfax.org.uk | Business Ethics
> http://carfax.org.uk/  |
> PGP: 65E74AC0          |



-- 
Have a nice day,
Timofey.

Re: Btrfs hangs 3.19-10

[Roman Mamedov]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Thu, 2 Apr 2015 11:46:08 +0000
Hugo Mills <hugo@carfax.org.uk> wrote:

> On Thu, Apr 02, 2015 at 02:38:24PM +0300, Timofey Titovets wrote:
> > I've get it several times, after rebooting or unclean shutdown system.
> > 
> > This is very strange bug, because if i reboot, and mount it from live
> > cd, all that okay, and after reboot in system, system successful mount
> > all and working good.
> > i did try to found any previous issues on it, and found nothing.
> 
>    Try 4.0-rc6, which should have the fix for the problem in it. This
> was introduced in the stable series, and is now fixed in mainline. It
> should also be fixed in the next stable release, I believe.

Yeah I believe I just hit that in 3.14.37, system unbootable (locks up at
"Scanning for Btrfs filesystems"), resulted in a many hour downtime as it was
a remote system w/o IPMI. Fine after a reboot to 3.14.34. Too bad that even
staying on the "stable" series kernel can back-stab you like that from time to
time.

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Btrfs hangs 3.19-10

[Duncan]

Roman Mamedov posted on Thu, 02 Apr 2015 19:13:12 +0500 as excerpted:

> Yeah I believe I just hit that in 3.14.37, system unbootable (locks up
> at "Scanning for Btrfs filesystems"), resulted in a many hour downtime
> as it was a remote system w/o IPMI. Fine after a reboot to 3.14.34. Too
> bad that even staying on the "stable" series kernel can back-stab you
> like that from time to time.

Well, btrfs itself isn't really stable yet...  Stable series should be 
stable at least to the extent that whatever you're using in them is, but 
with btrfs itself not yet entirely stable...  

If your goal is full stability, something that has been demonstrated 
mature, stable, and problem free for some period (say six months if 
you're edgy, a year if you're moderate, at least two years if you're 
conservative), is still a far better choice.  Given existing problems 
even now, even if 4.0 btrfs proves entirely stable, btrfs won't have that 
demonstrated history at least until the end of whatever length of period 
you consider appropriate, because that couldn't start until 4.0's 
release, which is still in the future.

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

Re: Btrfs hangs 3.19-10

[Russell Coker]

On Fri, 3 Apr 2015 05:14:12 AM Duncan wrote:
> Well, btrfs itself isn't really stable yet...  Stable series should be 
> stable at least to the extent that whatever you're using in them is, but 
> with btrfs itself not yet entirely stable... 

Also for stable operation you want both forward and backward compatability.  
You could make an Ext3 filesystem and expect that any random ancient Linux box 
you are likely to encounter can read it.  Even Ext4 has been supported for a 
long time and most systems you are likely to encounter won't have any problems 
with it.

I recently made a BTRFS filesystem on a Debian/Jessie system (kernel 3.16.7) 
with default options and discovered that Debian/Wheezy (kernel 3.2.65) can't 
read it.  I think that one criteria for "stable" in a filesystem is that 
kernels from a couple of previous releases can mount it.  By that criteria 
BTRFS won't be "stable" for use in Debian for about 4 years.

As an aside are there options to mkfs.btrfs that would make a filesystem 
mountable by kernel 3.2.65?  If so I'll file a Debian/Jessie bug report 
requesting that a specific mention be added to the man page.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: Btrfs hangs 3.19-10

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

On Sat, Apr 04, 2015 at 12:55:08PM +0000, Russell Coker wrote:
> On Fri, 3 Apr 2015 05:14:12 AM Duncan wrote:
> > Well, btrfs itself isn't really stable yet...  Stable series should be 
> > stable at least to the extent that whatever you're using in them is, but 
> > with btrfs itself not yet entirely stable... 
> 
> Also for stable operation you want both forward and backward compatability.  
> You could make an Ext3 filesystem and expect that any random ancient Linux box 
> you are likely to encounter can read it.  Even Ext4 has been supported for a 
> long time and most systems you are likely to encounter won't have any problems 
> with it.
> 
> I recently made a BTRFS filesystem on a Debian/Jessie system (kernel 3.16.7) 
> with default options and discovered that Debian/Wheezy (kernel 3.2.65) can't 
> read it.  I think that one criteria for "stable" in a filesystem is that 
> kernels from a couple of previous releases can mount it.  By that criteria 
> BTRFS won't be "stable" for use in Debian for about 4 years.
> 
> As an aside are there options to mkfs.btrfs that would make a filesystem 
> mountable by kernel 3.2.65?  If so I'll file a Debian/Jessie bug report 
> requesting that a specific mention be added to the man page.

   Yes, there are. It's probably -O^extref, but if you can show the
dmesg output from the 3.2 kernel on the failed mount (so that it shows
what the actual failure was), we should be able to give you a more
precise answer.

   Hugo.

-- 
Hugo Mills             | Welcome to Hollywood, a land just off the coast of
hugo@... carfax.org.uk | Planet Earth
http://carfax.org.uk/  |
PGP: 65E74AC0          |                                        The Cat's Meow

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Btrfs hangs 3.19-10

[Duncan]

Hugo Mills posted on Sat, 04 Apr 2015 13:00:47 +0000 as excerpted:

> On Sat, Apr 04, 2015 at 12:55:08PM +0000, Russell Coker wrote:
> 
>> As an aside are there options to mkfs.btrfs that would make a
>> filesystem mountable by kernel 3.2.65?  If so I'll file a Debian/Jessie
>> bug report requesting that a specific mention be added to the man page.
> 
> Yes, there are. It's probably -O^extref, but if you can show the
> dmesg output from the 3.2 kernel on the failed mount (so that it shows
> what the actual failure was), we should be able to give you a more
> precise answer.

So I was thinking about this, and the several other earlier options where 
support wasn't added until kernel X, and had an idea...

How easy and useful might it be to add to mkfs.btrfs appropriate option-
group aliases such that if one knew the oldest kernel one was likely to 
deal with, all one would need to do for the mkfs would be to set for 
example, -O3.2, or even simply --3.2 (or maybe even --32), and have 
mkfs.btrfs automatically set/unset the appropriate options so it would 
"just work" with that kernel and anything newer?

I imagine that could be a very useful feature for some, and I can't 
imagine it being too hard to setup the aliases since after all that 
should be all that's necessary, so what's left is to decide if it'd 
actually be useful enough to enough people to bother implementing and 
documenting...

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

Re: Btrfs hangs 3.19-10

[Russell Coker]

On Sun, 5 Apr 2015 03:16:21 AM Duncan wrote:
> Hugo Mills posted on Sat, 04 Apr 2015 13:00:47 +0000 as excerpted:
> > On Sat, Apr 04, 2015 at 12:55:08PM +0000, Russell Coker wrote:
> >> As an aside are there options to mkfs.btrfs that would make a
> >> filesystem mountable by kernel 3.2.65?  If so I'll file a Debian/Jessie
> >> bug report requesting that a specific mention be added to the man page.
> > 
> > Yes, there are. It's probably -O^extref, but if you can show the
> > dmesg output from the 3.2 kernel on the failed mount (so that it shows
> > what the actual failure was), we should be able to give you a more
> > precise answer.

[698190.987065] Btrfs loaded
[698190.999992] device fsid 118e2c64-6ce1-4f21-85e2-2d6aea8f0fa5 devid 1 
transid 426 /dev/sdf1
[698191.000981] btrfs: disk space caching is enabled
[698191.000986] BTRFS: couldn't mount because of unsupported optional features 
(60).
[698191.018176] btrfs: open_ctree failed

> So I was thinking about this, and the several other earlier options where
> support wasn't added until kernel X, and had an idea...
> 
> How easy and useful might it be to add to mkfs.btrfs appropriate option-
> group aliases such that if one knew the oldest kernel one was likely to
> deal with, all one would need to do for the mkfs would be to set for
> example, -O3.2, or even simply --3.2 (or maybe even --32), and have
> mkfs.btrfs automatically set/unset the appropriate options so it would
> "just work" with that kernel and anything newer?

That would be really useful.  Also it would be good if the code structure 
allowed adding extra aliases, so for Debian we could add an option -Owheezy.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: Btrfs hangs 3.19-10

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

On Sun, Apr 05, 2015 at 03:30:47AM +0000, Russell Coker wrote:
> On Sun, 5 Apr 2015 03:16:21 AM Duncan wrote:
> > Hugo Mills posted on Sat, 04 Apr 2015 13:00:47 +0000 as excerpted:
> > > On Sat, Apr 04, 2015 at 12:55:08PM +0000, Russell Coker wrote:
> > >> As an aside are there options to mkfs.btrfs that would make a
> > >> filesystem mountable by kernel 3.2.65?  If so I'll file a Debian/Jessie
> > >> bug report requesting that a specific mention be added to the man page.
> > > 
> > > Yes, there are. It's probably -O^extref, but if you can show the
> > > dmesg output from the 3.2 kernel on the failed mount (so that it shows
> > > what the actual failure was), we should be able to give you a more
> > > precise answer.
> 
> [698190.987065] Btrfs loaded
> [698190.999992] device fsid 118e2c64-6ce1-4f21-85e2-2d6aea8f0fa5 devid 1 
> transid 426 /dev/sdf1
> [698191.000981] btrfs: disk space caching is enabled
> [698191.000986] BTRFS: couldn't mount because of unsupported optional features 
> (60).

   That's these, I think:

#define BTRFS_FEATURE_INCOMPAT_BIG_METADATA     (1ULL << 5)
#define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF    (1ULL << 6)

so it's definitely -O^extref. I don't see where big_metadata comes
from, though. That's not a -O option. Try with -O^extref and see where
that gets you. (Also, don't mount the FS on a newer kernel -- it may
be setting big metadata automatically, although it probably shouldn't
do).

   Hugo.

> [698191.018176] btrfs: open_ctree failed
> 
> > So I was thinking about this, and the several other earlier options where
> > support wasn't added until kernel X, and had an idea...
> > 
> > How easy and useful might it be to add to mkfs.btrfs appropriate option-
> > group aliases such that if one knew the oldest kernel one was likely to
> > deal with, all one would need to do for the mkfs would be to set for
> > example, -O3.2, or even simply --3.2 (or maybe even --32), and have
> > mkfs.btrfs automatically set/unset the appropriate options so it would
> > "just work" with that kernel and anything newer?
> 
> That would be really useful.  Also it would be good if the code structure 
> allowed adding extra aliases, so for Debian we could add an option -Owheezy.
> 

-- 
Hugo Mills             | Nostalgia isn't what it used to be.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Btrfs hangs 3.19-10

[Duncan]

Hugo Mills posted on Sun, 05 Apr 2015 10:04:17 +0000 as excerpted:

> On Sun, Apr 05, 2015 at 03:30:47AM +0000, Russell Coker wrote:
>> On Sun, 5 Apr 2015 03:16:21 AM Duncan wrote:
>> > Hugo Mills posted on Sat, 04 Apr 2015 13:00:47 +0000 as excerpted:
>> > > On Sat, Apr 04, 2015 at 12:55:08PM +0000, Russell Coker wrote:
>> > >> As an aside are there options to mkfs.btrfs that would make a
>> > >> filesystem mountable by kernel 3.2.65?  If so I'll file a
>> > >> Debian/Jessie bug report requesting that a specific mention be
>> > >> added to the man page.
>> > > 
>> > > Yes, there are. It's probably -O^extref, but if you can show the
>> > > dmesg output from the 3.2 kernel on the failed mount (so that it
>> > > shows what the actual failure was), we should be able to give you a
>> > > more precise answer.
>> 
>> [698190.987065] Btrfs loaded
>> [698190.999992] device fsid [...] devid 1 transid 426 /dev/sdf1
>> [698191.000981] btrfs: disk space caching is enabled
>> [698191.000986] BTRFS: couldn't mount because of unsupported
>> optional features (60).
> 
> That's these, I think:
> 
> #define BTRFS_FEATURE_INCOMPAT_BIG_METADATA     (1ULL << 5)
> #define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF    (1ULL << 6)
> 
> so it's definitely -O^extref. I don't see where big_metadata comes from,
> though. That's not a -O option.

Kernel-side, BTRFS_FEATURE_INCOMPAT_BIG_METADATA was added in 3.4.  It 
came with this code comment (retained thru 3.19 at least)

/*
 * older kernels tried to do bigger metadata blocks, but the
 * code was pretty buggy.  Lets not let them try anymore.
 */
#define BTRFS_FEATURE_INCOMPAT_BIG_METADATA     (1ULL << 5)


Git blame says commit 727011e0, which has this commit message:

commit 727011e07cbdf87772fcc1999cccd15cc915eb62
Author: Chris Mason <chris.mason@oracle.com>
Date:   Fri Aug 6 13:21:20 2010 -0400

    Btrfs: allow metadata blocks larger than the page size

    A few years ago the btrfs code to support blocks lager than
    the page size was disabled to fix a few corner cases in the
    page cache handling.  This fixes the code to properly support
    large metadata blocks again.

    Since current kernels will crash early and often with larger
    metadata blocks, this adds an incompat bit so that older kernels
    can't mount it.

    This also does away with different blocksizes for nodes and leaves.
    You get a single block size for all tree blocks.

    Signed-off-by: Chris Mason <chris.mason@oracle.com>


So...

3.2 would have had large metadata blocks disabled.  When they were 
enabled again in 3.4, the big-metadata incompat flag was added, to keep 
older kernels from even trying to mount them as they'd crash "early and 
often" if they did.

Back in the kernel 3.2 era, mkfs.btrfs had node and leaf size options, 
but the warning was not to attempt setting that manually unless you were 
creating a filesystem actually to be used on other hardware with a 
different page size, in which case, set that.

So metadata blocks were effectively forced to the 4096-byte page size.

Somewhere after the kernel was able to handle the larger metadata blocks 
again (I could look it up as I did the kernel code above, but meh...), 
the mkfs.btrfs default was upped to 16K, that being found to be much more 
efficient thru testing.

So... for 3.2 compatibility, extref must not be enabled (tho it's now the 
default and AFAIK there's no way to actually disable it, only enable, so 
an old btrfs-tools would have to be used that doesn't enable it by 
default), AND the nodesize must be set to page size, 4096 bytes for x86.

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

Re: Btrfs hangs 3.19-10

[Pavel Volkov]

On Sunday, April 5, 2015 1:04:17 PM MSK, Hugo Mills wrote:
>    That's these, I think:
>
> #define BTRFS_FEATURE_INCOMPAT_BIG_METADATA     (1ULL << 5)
> #define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF    (1ULL << 6)
>
> so it's definitely -O^extref. I don't see where big_metadata comes
> from, though. That's not a -O option. Try with -O^extref and see where
> that gets you. (Also, don't mount the FS on a newer kernel -- it may
> be setting big metadata automatically, although it probably shouldn't
> do).

By the way, is there any way to see which options are enabled on a local 
filesystem without having to try mounting it with old kernel and checking 
dmesg?

Re: Btrfs hangs 3.19-10

[Russell Coker]

On Mon, 6 Apr 2015 07:40:03 AM Pavel Volkov wrote:
> On Sunday, April 5, 2015 1:04:17 PM MSK, Hugo Mills wrote:
> >    That's these, I think:
> > #define BTRFS_FEATURE_INCOMPAT_BIG_METADATA     (1ULL << 5)
> > #define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF    (1ULL << 6)
> > 
> > so it's definitely -O^extref. I don't see where big_metadata comes
> > from, though. That's not a -O option. Try with -O^extref and see where
> > that gets you. (Also, don't mount the FS on a newer kernel -- it may
> > be setting big metadata automatically, although it probably shouldn't
> > do).
> 
> By the way, is there any way to see which options are enabled on a local
> filesystem without having to try mounting it with old kernel and checking
> dmesg?

# file -s /dev/dm-0 
/dev/dm-0: BTRFS Filesystem sectorsize 4096, nodesize 4096, leafsize 4096, 
UUID=97d70558-ddea-493e-874c-ff74be9ce099, 92390113280/171796594688 bytes used, 
1 devices

Above is what file(1) reports on my laptop which has been running BTRFS since 
3.2 days.  It gives the node size etc but not the feature flags.  Some time ago 
I submitted a patch to the Debian package that covered everything I could 
figure out, I'm sure that they would accept a patch for feature flags if anyone 
can work out how to do it.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: Btrfs hangs 3.19-10

[Russell Coker]

On Mon, 6 Apr 2015 03:21:18 AM Duncan wrote:
> So... for 3.2 compatibility, extref must not be enabled (tho it's now the 
> default and AFAIK there's no way to actually disable it, only enable, so 
> an old btrfs-tools would have to be used that doesn't enable it by 
> default), AND the nodesize must be set to page size, 4096 bytes for x86.

So basically we have to have an old version of mkfs.btrfs to make a filesystem 
that can be mounted on kernel 3.2.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: Btrfs hangs 3.19-10

[Duncan]

Pavel Volkov posted on Mon, 06 Apr 2015 10:40:03 +0300 as excerpted:

> On Sunday, April 5, 2015 1:04:17 PM MSK, Hugo Mills wrote:
>>    That's these, I think:
>>
>> #define BTRFS_FEATURE_INCOMPAT_BIG_METADATA     (1ULL << 5)
>> #define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF    (1ULL << 6)
>>
>> so it's definitely -O^extref. I don't see where big_metadata comes
>> from, though. That's not a -O option. Try with -O^extref and see where
>> that gets you. (Also, don't mount the FS on a newer kernel -- it may be
>> setting big metadata automatically, although it probably shouldn't do).
> 
> By the way, is there any way to see which options are enabled on a local
> filesystem without having to try mounting it with old kernel and
> checking dmesg?

btrfs-show-super shows what flags are enabled, both numerically and 
symbolically.

At least for btrfs-progs 3.19.1, which I have installed.  I'm not sure 
how far that goes back, but I don't believe it's new functionality, so 
I'd guess 3.14 at least, but likely not back all the way to 0.19, as that 
was a very long time ago in btrfs terms.

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

Re: Btrfs hangs 3.19-10

[Duncan]

Duncan posted on Mon, 06 Apr 2015 09:20:12 +0000 as excerpted:

> Pavel Volkov posted on Mon, 06 Apr 2015 10:40:03 +0300 as excerpted:
>> 
>> By the way, is there any way to see which options are enabled on a
>> local filesystem without having to try mounting it with old kernel and
>> checking dmesg?
> 
> btrfs-show-super shows what flags are enabled, both numerically and
> symbolically.

Also see (since kernel 3.14 according to the wiki) 
/sys/fs/btrfs/<UUID>/features/* .

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

Re: Btrfs hangs 3.19-10

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

On Mon, Apr 06, 2015 at 10:40:03AM +0300, Pavel Volkov wrote:
> On Sunday, April 5, 2015 1:04:17 PM MSK, Hugo Mills wrote:
> >   That's these, I think:
> >
> >#define BTRFS_FEATURE_INCOMPAT_BIG_METADATA     (1ULL << 5)
> >#define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF    (1ULL << 6)
> >
> >so it's definitely -O^extref. I don't see where big_metadata comes
> >from, though. That's not a -O option. Try with -O^extref and see where
> >that gets you. (Also, don't mount the FS on a newer kernel -- it may
> >be setting big metadata automatically, although it probably shouldn't
> >do).
> 
> By the way, is there any way to see which options are enabled on a
> local filesystem without having to try mounting it with old kernel
> and checking dmesg?

   btrfs-show-super is the tool for that.

   Hugo.

-- 
Hugo Mills             | Great oxymorons of the world, no. 4:
hugo@... carfax.org.uk | Future Perfect
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]