Marc MERLIN | 22 Aug 17:50 2014

Unclean shutdowns cause google-chrome profile to be corrupted in various ways

Someone just told me yesterday they had the same problem, so I filed a

Fairly often (over 20 times for me so far with various kernel versions),
when I reboot after a crash, my google-chrome profile is damaged in one
of 2 ways:
1) open tabs don't reopen
2) google-chrome says that my profile is corrupted.

In both cases rsyncing ~/.config/google-chrome from the last hourly
snapshot has fixed the problem every time.

Given that, I would say that google-chrome does not have a bug of half
unclean states since the state present in a snapshot has always worked
for me, but that's anecdotal, not proof.

But if my kernel hangs due to a bug that isn't btrfs' fault and I need
to power off and back on, after reboot my google-chrome profile is
almost always broken in some way.
This with a samsung evo 840 SSD which I believe does reasonable enough
things on power shutdowns, although I can't prove that.

File formats are some kind of raw data and sqlite 3.x
~/.config/google-chrome-beta/Profile 1:
Last Session:                     data
Last Tabs:                        data
Login Data:                       SQLite 3.x database

(Continue reading)

Shriramana Sharma | 22 Aug 13:59 2014

Distro vs latest kernel for BTRFS?

Hello. I've seen repeated advices to use the latest kernel. While
hearing of the recent compression bug affecting recent kernels does
somewhat warn one off the previous advice, I would like to know what
people who are running regular distros do to get the latest kernel.

Personally I'm on Kubuntu, which provides mainline kernels till a
particular point but not beyond that.

Do people here always compile the latest kernel themselves just to get
the latest BTRFS stability fixes (and  improvements, though as a
second priority)?


Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at>
More majordomo info at

Qu Wenruo | 22 Aug 05:42 2014

[PATCH] btrfs-progs: corrupt-block: fix a delete and use bug corrupting extent tree.

When corrupting extent tree, corrupt-block will iterate each child
node/leaf of a node.
However, when a node's child is leaf, btrfs_corrupt_extent_leaf() may
delete some item in the leaf, which may cause the children number of the
parent node decrease.

Before this patch, corrupt-block will read out the nritems only *ONCE*
and iterate the 'nritems' times.
When btrfs_corrupt_extent_leaf() deletes enough item, causing the
nritems of btrfs_header decreased, the last few iteration will access
non-existed node, which will cause the delete and use bug like
the following:
\# ./btrfs-corrupt-block -E /dev/vdc
deleting extent record: key 40714240 168 16384
Couldn't map the block 3459802452797161472
btrfs-corrupt-block: volumes.c:1137: btrfs_num_copies: Assertion
`!(!ce)' failed.

This patch will update the nritmes in each iteration to avoid the bug.

Signed-off-by: Qu Wenruo <quwenruo <at>>
 btrfs-corrupt-block.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/btrfs-corrupt-block.c b/btrfs-corrupt-block.c
index 6ecbe47..486ea19 100644
(Continue reading)

Chris Murphy | 22 Aug 02:11 2014

mkfs.btrfs vs fstrim on an SD Card (not SSD)

Short version:
When I mkfs.btrfs either an SD Card or an SSD, I get a response back to the effect the whole device specified is
trimmed. However, when I use fstrim on an SD Card, I get an error that trim isn't supported. So I'm wondering
if anyone knows the difference between how fstrim is trimming, and how mkfs.btrfs is trimming. 

Long version:
It does seem like the mkfs.btrfs one has worked because using dd to read an LBA with known information
returns zeros after mkfs.

And then I found the SD Card association has their own formatting tool for Windows and OS X, with the warning
"Using generic formatting utilities may result in less than optimal performance for your memory cards."

So I downloaded the Physical Layer Simplified Specification Version 4.10 spec, and on page 38 it describes
an erase command.

4.3.5 Erase
It is desirable to erase many write blocks simultaneously in order to enhance the data throughput.
Identification of these write blocks is accomplished with the ERASE_WR_BLK_START (CMD32),
ERASE_WR_BLK_END (CMD33) commands.
The host should adhere to the following command sequence: ERASE_WR_BLK_START, ERASE_WR_BLK_END and

So I'm going to guess that mkfs.btrfs is leveraging something that ends up using these SD Card specific
commands on SD Cards, but mkfs.btfs itself isn't aware of this distinction. Whereas fstrim is maybe using
something else?

Chris Murphy--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at>
(Continue reading)

Zach Brown | 21 Aug 23:24 2014

[PATCH] btrfs-progs: fix unaligned loads in receive

A user reported corruption after receiving subvolumes.  Turning up the
logging during the receive showed that the commands and string
attributes were being received correctly but the u64 attrbutes were
sometimes corrupted by having variable number of low order bytes

It turned out they were on a platform that corrupts unaligned userspace
loads.  Loading the u64s from the unaligned pointers into the received
command stream with get_unaligned() fixed the problem.

Reported-By: Klaus Holler <kho <at>>
Tested-By: Klaus Holler <kho <at>>
Signed-off-by: Zach Brown <zab <at>>
 send-stream.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/send-stream.c b/send-stream.c
index 88e18e2..4f8dd83 100644
--- a/send-stream.c
+++ b/send-stream.c
 <at>  <at>  -204,7 +204,7  <at>  <at>  out:
 		int __len; \
 		TLV_GET(s, attr, (void**)&__tmp, &__len); \
 		TLV_CHECK_LEN(sizeof(*__tmp), __len); \
-		*v = le##bits##_to_cpu(*__tmp); \
+		*v = get_unaligned_le##bits(__tmp); \
 	} while (0)

 #define TLV_GET_U8(s, attr, v) TLV_GET_INT(s, attr, 8, v)
(Continue reading)

Naohiro Aota | 21 Aug 14:07 2014

[PATCH] btrfs-progs: Do not free dirty extent buffer

free_some_buffer() should not free dirty extent buffers. They should be
left for later commit.

Signed-off-by: Naohiro Aota <naota <at>>
 extent_io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/extent_io.c b/extent_io.c
index a127e54..8a668be 100644
--- a/extent_io.c
+++ b/extent_io.c
 <at>  <at>  -552,7 +552,7  <at>  <at>  static int free_some_buffers(struct extent_io_tree *tree)

 	list_for_each_safe(node, next, &tree->lru) {
 		eb = list_entry(node, struct extent_buffer, lru);
-		if (eb->refs == 1) {
+		if (eb->refs == 1 && !(eb->flags && EXTENT_DIRTY)) {
 			if (tree->cache_size < cache_hard_max)

To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at>
More majordomo info at

Naohiro Aota | 21 Aug 14:04 2014

[PATCH RFC] btrfs-progs: Show backtrace on BUGs

"btrfs check" is still under heavy development and so there are some
BUGs beging hit. "btrfs check" can be run on limited environment which
lacks gdb to debug the abort in detail. If we could see backtrace, it
will be easier to find a root cause of the BUG.

Following is my "btrfs check" output with and without the patch.

without patch:

ref mismatch on [1437411180544 16384] extent item 3, found 2
btrfs: extent_io.c:612: free_extent_buffer: Assertion `!(eb->flags & 1)' failed.
enabling repair mode
Checking filesystem on /dev/sdb2
UUID: a53121ee-679f-4241-bb44-ceb5a1a7beb7

with patch:

ref mismatch on [1437411180544 16384] extent item 3, found 2
btrfs check(free_extent_buffer+0xa3)[0x808ff89]
btrfs check[0x8090222]
btrfs check(alloc_extent_buffer+0xa7)[0x80903d0]
btrfs check(btrfs_find_create_tree_block+0x2e)[0x807edef]
btrfs check(btrfs_alloc_free_block+0x299)[0x808a3c4]
btrfs check(__btrfs_cow_block+0x1d4)[0x8078896]
btrfs check(btrfs_cow_block+0x150)[0x807934d]
btrfs check(btrfs_search_slot+0x136)[0x807c041]
btrfs check[0x8065a6b]
btrfs check[0x806bc0f]
btrfs check(cmd_check+0xc8f)[0x806d03a]
btrfs check(main+0x167)[0x804f5ec]
(Continue reading)

Mihail Zaporozhets | 21 Aug 07:52 2014

btrfs restore

I'm create btrfs multi-device volume: (2TB * 5disks)
1. one device was converted from ext3, 
then delete sub-volume 'ext2'; 
2. 'btrfs device add /dev/sd* /mnt/sdc1'; 
and some times again,  Every disk adds by one, then move data from other
disks. 2 times was running 'btrfs fi defrag -r -v -t 700K /mnt/sdc1; btrfs
balance start /mnt/sdc1; btrfs scrub start /mnt/sdc1'. Finally I have FS at
5 devices.

After, go to reboot pc, and I seen that 1 drive have no any partition. I'm
full of sadness. I think that device was not correctly unmounted and one
disk fail.
mount -t btrfs -o degreded,ro,recovery,nospace_cache ...
mount -t btrfs -o recovery,nospace_cache ...
btrfs-find-root, btrfs-zero-log .. 

btrfs restore -t 10404875644928 -v -i /dev/sda1 /mnt/uh1/eric/ - 
Success! but some directory is absent; 3.4 TB restored, but 4 (available
disks)*1.82 Tb = 7.28 TB; and 7.28-3.4 = about 3.8 TB which is missing .
Where is it ? How can i get it back? 

How can i try to restore more data? 

Please advice.

mount -t btrfs -o degraded,ro,recovery,nospace_cache /dev/sda1 /mnt/tmp3;
dmesg | tail
(Continue reading)

Gui Hecheng | 21 Aug 05:35 2014

[PATCH] btrfs-progs: init uninitialized output buf for btrfs-restore

A memory problem reported by valgrind as follows:
	=== Syscall param pwrite64(buf) points to uninitialised byte(s)
When running:
	# valgrind --leak-check=yes btrfs restore /dev/sda9 /mnt/backup

Because the output buf size is alloced with malloc, but the length of
output data is shorter than the sizeof(buf), so valgrind report
uninitialised byte(s).
We could use calloc to repalce malloc and clear this WARNING away.

Reported-by: Marc Dietrich <marvin24 <at>>
Signed-off-by: Gui Hecheng <guihc.fnst <at>>
 cmds-restore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cmds-restore.c b/cmds-restore.c
index cbda6bb..bb72311 100644
--- a/cmds-restore.c
+++ b/cmds-restore.c
 <at>  <at>  -251,7 +251,7  <at>  <at>  static int copy_one_inline(int fd, struct btrfs_path *path, u64 pos)

 	ram_size = btrfs_file_extent_ram_bytes(leaf, fi);
-	outbuf = malloc(ram_size);
+	outbuf = calloc(1, ram_size);
 	if (!outbuf) {
 		fprintf(stderr, "No memory\n");
 		return -ENOMEM;
 <at>  <at>  -320,7 +320,7  <at>  <at>  static int copy_one_extent(struct btrfs_root *root, int fd,
(Continue reading)

Shriramana Sharma | 21 Aug 05:22 2014

Significance of high number of mails on this list?

Hello. People on this list have been kind enough to reply to my
technical questions. However, seeing the high number of mails on this
list, esp with the title PATCH, I have a question about the
development itself:

Is this just an indication of a vibrant user/devel community [*] and
healthy development of many new nice features to eventually come out
in stable form later, or are we still at the fixing rough edges stage?
IOW what is the proportion of commits adding new features to those
stabilising/fixing features?

[* Since there is no separate btrfs-users vs brtfs-dev I'm not able to
gauge this difference either. i.e. if there were a dedicated -dev list
I might not be alarmed by a high number of mails indicating fast

Mostly I have read like "BTRFS is mostly stable but there might be a
few corner cases as yet unknown since this is a totally new generation
of FSs". But still given the volume of mails here I wanted to ask...
I'm sorry I realize I'm being a bit vague but I'm not sure how to
exactly express what I'm feeling about BTRFS right now...


Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at>
More majordomo info at

(Continue reading)

Gui Hecheng | 21 Aug 04:56 2014

[PATCH 1/2] btrfs-progs: cleanup duplicate assignment of variable leaf for btrfs-restore

The value of variable leaf in while loop don't have to be set
for every round. Just move it outside.

Signed-off-by: Gui Hecheng <guihc.fnst <at>>
 cmds-restore.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cmds-restore.c b/cmds-restore.c
index a6f535c..f417e0b 100644
--- a/cmds-restore.c
+++ b/cmds-restore.c
 <at>  <at>  -962,8 +962,9  <at>  <at>  static int do_list_roots(struct btrfs_root *root)
 		return -1;

+	leaf = path->nodes[0];
 	while (1) {
-		leaf = path->nodes[0];
 		slot = path->slots[0];
 		if (slot >= btrfs_header_nritems(leaf)) {
 			ret = btrfs_next_leaf(root, path);


To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at>
More majordomo info at
(Continue reading)