Re: [RFC PATCH 5/5] Btrfs: fix broken free space cache after the system crashed
Thanks, Miao,
so the problem is that cow_file_range() joins transaction, allocates
space through btrfs_reserve_extent(), then detaches from transaction.
And then btrfs_finish_ordered_io() joins transaction again, adds a
delayed ref and detaches from transaction. So if between these two,
the transaction commits and we crash, then yes, the allocation is
lost.
Alex.
On Tue, Mar 4, 2014 at 8:04 AM, Miao Xie mi...@cn.fujitsu.com wrote:
On sat, 1 Mar 2014 20:05:01 +0200, Alex Lyakas wrote:
Hi Miao,
On Wed, Jan 15, 2014 at 2:00 PM, Miao Xie mi...@cn.fujitsu.com wrote:
When we mounted the filesystem after the crash, we got the following
message:
BTRFS error (device xxx): block group 4315938816 has wrong amount of free
space
BTRFS error (device xxx): failed to load free space cache for block group
4315938816
It is because we didn't update the metadata of the allocated space until
the file data was written into the disk. During this time, there was no
information about the allocated spaces in either the extent tree nor the
free space cache. when we wrote out the free space cache at this time, those
spaces were lost.
Can you please clarify more about the problem?
So I understand that we allocate something from the free space cache.
So after that, the free space cache does not account for this extent
anymore. On the other hand the extent tree also does not account for
it (yet). We need to add a delayed reference, which will be run at
transaction commit and update the extent tree. But free-space cache is
also written out during transaction commit. So how the issue happens?
Can you perhaps post a flow of events?
Task1 Task2
btrfs_writepages()
alloc data space
(The allocated space was
removed from the free
space cache)
submit_bio()
btrfs_commit_transaction()
write out space cache
...
commit transaction completed
system crash
(end_io() wasn't executed)
The system crashed before end_io was executed, so no file references to the
allocated space, and the extent tree also does not account for it. That space
was lost.
Thanks
Miao
Thanks.
Alex.
In ordered to fix this problem, I use a state tree for every block group
to record those allocated spaces. We record the information when they are
allocated, and clean up the information after the metadata update. Besides
that, we also introduce a read-write semaphore to avoid the race between
the allocation and the free space cache write out.
Only data block groups had this problem, so the above change is just
for data space allocation.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ctree.h| 15 ++-
fs/btrfs/disk-io.c | 2 +-
fs/btrfs/extent-tree.c | 24
fs/btrfs/free-space-cache.c | 42 ++
fs/btrfs/inode.c| 42 +++---
5 files changed, 108 insertions(+), 17 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 1667c9a..f58e1f7 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1244,6 +1244,12 @@ struct btrfs_block_group_cache {
/* free space cache stuff */
struct btrfs_free_space_ctl *free_space_ctl;
+ /*
+* It is used to record the extents that are allocated for
+* the data, but don/t update its metadata.
+*/
+ struct extent_io_tree pinned_extents;
+
/* block group cache stuff */
struct rb_node cache_node;
@@ -1540,6 +1546,13 @@ struct btrfs_fs_info {
*/
struct list_head space_info;
+ /*
+* It is just used for the delayed data space allocation
+* because only the data space allocation can be done during
+* we write out the free space cache.
+*/
+ struct rw_semaphore data_rwsem;
+
struct btrfs_space_info *data_sinfo;
struct reloc_control *reloc_ctl;
@@ -3183,7 +3196,7 @@ int btrfs_alloc_logged_file_extent(struct
btrfs_trans_handle *trans,
struct btrfs_key *ins);
int btrfs_reserve_extent(struct btrfs_root *root, u64 num_bytes,
u64 min_alloc_size, u64 empty_size, u64 hint_byte,
-struct btrfs_key *ins, int is_data);
+struct btrfs_key *ins, int is_data, bool need_pin);
int btrfs_inc_ref(struct btrfs_trans_handle *trans, struct btrfs_root
*root,
struct extent_buffer *buf, int full_backref, int for_cow);
int btrfs_dec_ref(struct btrfs_trans_handle *trans, struct btrfs_root
*root,
diff --git
btrfs send kernel error btrfs_compare_tree
Greetings, A call to: btrfs send -vvv -p parent child | ssh host btrfs receive -vvve dir fails with: ERROR: send ioctl failed with -5: Input/output error ERROR: unexpected EOF in stream. Resulting in the kernel log below on the sending system. The key line seems to be: Mar 8 18:13:23 kernel: [ 2041.956270] btrfs: btrfs_compare_tree detected a change in one of the trees while iterating. This is probably a bug. I've searched but Google didn't seem to find anyone reporting a similar error. This is running on Debian sid, fully up to date. The source drive is an Intel 320 SSD and smartctl doesn't indicate any issues with it. The read-only subvolumes acting as the parent and child would have been created with an older kernel, perhaps 3.2. I tried taking a new read-only snapshot of the child and sending that, but the effect was the same. I also tried mounting the source filesystem read-only, but there was no difference. If I make a read-only snapshot of the parent and send that snapshot as a child of the parent, that sends OK. Please let me know if I can provide any further assistance in tracking this down (and thanks for all the great work on btrfs). $ uname -a Linux 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux Mar 8 18:12:51 kernel: [ 2009.568506] [ cut here ] Mar 8 18:12:51 kernel: [ 2009.568564] WARNING: CPU: 1 PID: 1264 at /build/linux-UvfduQ/linux-3.13.5/fs/btrfs/send.c:4687 btrfs_ioctl_send+0xba6/0xbc0 [btrfs]() Mar 8 18:12:51 kernel: [ 2009.568569] Modules linked in: ext4 crc16 mbcache jbd2 iTCO_wdt coretemp iTCO_vendor_support psmouse serio_raw pcspkr i2c_i801 i2c_core lpc_ich mfd_core joydev evdev processor button thermal_sys raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx md_mod ipmi_si ipmi_devintf ipmi_msghandler autofs4 btrfs xor raid6_pq crc32c libcrc32c sg sd_mod crct10dif_generic crc_t10dif crct10dif_common hid_generic usbhid hid ata_generic ata_piix libata scsi_mod e1000e ptp pps_core ehci_pci uhci_hcd ehci_hcd usbcore usb_common Mar 8 18:12:51 kernel: [ 2009.568635] CPU: 1 PID: 1264 Comm: btrfs Tainted: G W3.13-1-amd64 #1 Debian 3.13.5-1 Mar 8 18:12:51 kernel: [ 2009.568639] Hardware name: Supermicro X7SPA-HF/X7SPA-HF, BIOS 1.2a 02/21/12 Mar 8 18:12:51 kernel: [ 2009.568643] 0009 814a0927 8105ba72 Mar 8 18:12:51 kernel: [ 2009.568652] 7fff1006a1e8 8800b92d9380 7fff1006a1e8 8800b92d9380 Mar 8 18:12:51 kernel: [ 2009.568658] 0001 a0214e96 88013fff9b08 8800360f8000 Mar 8 18:12:51 kernel: [ 2009.568666] Call Trace: Mar 8 18:12:51 kernel: [ 2009.568677] [814a0927] ? dump_stack+0x41/0x51 Mar 8 18:12:51 kernel: [ 2009.568685] [8105ba72] ? warn_slowpath_common+0x72/0x90 Mar 8 18:12:51 kernel: [ 2009.568714] [a0214e96] ? btrfs_ioctl_send+0xba6/0xbc0 [btrfs] Mar 8 18:12:51 kernel: [ 2009.568723] [8111eee9] ? __alloc_pages_nodemask+0x149/0x9d0 Mar 8 18:12:51 kernel: [ 2009.568731] [811607c9] ? kmem_getpages+0xb9/0x140 Mar 8 18:12:51 kernel: [ 2009.568758] [a01e4b6a] ? btrfs_ioctl+0xfca/0x25d0 [btrfs] Mar 8 18:12:51 kernel: [ 2009.568766] [8108706c] ? set_task_cpu+0x5c/0x160 Mar 8 18:12:51 kernel: [ 2009.568775] [8126f860] ? cpumask_next_and+0x30/0x40 Mar 8 18:12:51 kernel: [ 2009.568781] [8108d4ef] ? select_task_rq_fair+0x2af/0x6f0 Mar 8 18:12:51 kernel: [ 2009.568789] [8101981f] ? native_sched_clock+0xf/0x70 Mar 8 18:12:51 kernel: [ 2009.568796] [8108f827] ? enqueue_task_fair+0x2c7/0xe10 Mar 8 18:12:51 kernel: [ 2009.568803] [81086e25] ? check_preempt_curr+0x65/0x90 Mar 8 18:12:51 kernel: [ 2009.568810] [81088c45] ? wake_up_new_task+0xd5/0x160 Mar 8 18:12:51 kernel: [ 2009.568817] [8118b5bf] ? do_vfs_ioctl+0x2cf/0x4a0 Mar 8 18:12:51 kernel: [ 2009.568823] [8118b810] ? SyS_ioctl+0x80/0xa0 Mar 8 18:12:51 kernel: [ 2009.568831] [814ade99] ? stub_clone+0x69/0x90 Mar 8 18:12:51 kernel: [ 2009.568838] [814adb39] ? system_call_fastpath+0x16/0x1b Mar 8 18:12:51 kernel: [ 2009.568843] ---[ end trace 627af7edfbb43119 ]--- Mar 8 18:13:23 kernel: [ 2041.956215] [ cut here ] Mar 8 18:13:23 kernel: [ 2041.956264] WARNING: CPU: 1 PID: 1264 at /build/linux-UvfduQ/linux-3.13.5/fs/btrfs/ctree.c:5246 btrfs_compare_trees+0x461/0x960 [btrfs]() Mar 8 18:13:23 kernel: [ 2041.956270] btrfs: btrfs_compare_tree detected a change in one of the trees while iterating. This is probably a bug. Mar 8 18:13:23 kernel: [ 2041.956274] Modules linked in: ext4 crc16 mbcache jbd2 iTCO_wdt coretemp iTCO_vendor_support psmouse serio_raw pcspkr i2c_i801 i2c_core lpc_ich mfd_core joydev evdev processor button thermal_sys raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx md_mod ipmi_si
Re: btrfs send kernel error btrfs_compare_tree
On 2014-03-08 18:40, Travis Cross wrote: Mar 8 18:13:23 kernel: [ 2041.956270] btrfs: btrfs_compare_tree detected a change in one of the trees while iterating. This is probably a bug. xaba on IRC helpfully encouraged me to run btrfs check on the device. I receive a flood of messages: Extent back ref already exists for x parent 0 root y Then it pauses for awhile, and starts flooding out: ref mismatch on [x 4096] extent item 1, found 2 Incorrect global backref count on x found 1 wanted 2 backpointer mismatch on [x 4096] Then it outputs a comparably fewer lines of: free space inode generation (0) did not match free space cache generation (x) Finally it outputs: checking fs roots And after some time gets killed by the Linux OOM killer. The system has 4G of memory. The dark irony here is I was trying to btrfs send the subvolumes off of this disk so I could use it for swap space because btrfs send operations on other disks were running out of memory. The filesystem here was likely created with Linux 3.2 and hasn't seen much use for awhile, until today I mounted it to try to btrfs send off those volumes. xaba noted this could be the result of some 3.2-era kernel bug. He recognized the messages I was seeing. If this is the case, and this sort of thing is common, it seems we might want to have a way of detecting this and trying to salvage the situation (particularly as Debian wheezy -- the last Debian stable release -- is on a 3.2 kernel). Either way, I'll wait for a consensus here on how to proceed. -- 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
send/receive locking
Is there anything that can be done about the issues of btrfs send blocking? I've been writing a backup script (slowly), and several times I've managed to hit a situation where large chunks of the machine grind to a complete halt in D state because the backup script has jammed up. Now, I'm aware that you can't send and receive to the same filesystem at the same time, and that's a restriction I can live with. However, having things that aren't related to the backup process suddenly stop working because the backup script is trying to log its progress to the same FS it's backing up is... umm... somewhat vexing, to say the least. Is this a truly fundamental property of send/receive, or is there likely to be a simple(ish) solution? Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Well, you don't get to be a kernel hacker simply by looking --- good in Speedos. -- Rusty Russell signature.asc Description: Digital signature
Re: send/receive locking
Hey Hugo will you try the danger branch on btrfs-next, Wang changed the locking a bit. Thanks, Josef Hugo Mills h...@carfax.org.uk wrote: Is there anything that can be done about the issues of btrfs send blocking? I've been writing a backup script (slowly), and several times I've managed to hit a situation where large chunks of the machine grind to a complete halt in D state because the backup script has jammed up. Now, I'm aware that you can't send and receive to the same filesystem at the same time, and that's a restriction I can live with. However, having things that aren't related to the backup process suddenly stop working because the backup script is trying to log its progress to the same FS it's backing up is... umm... somewhat vexing, to say the least. Is this a truly fundamental property of send/receive, or is there likely to be a simple(ish) solution? Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or https://urldefense.proofpoint.com/v1/url?u=http://www.carfax.org.uk/k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=cKCbChRKsMpTX8ybrSkonQ%3D%3D%0Am=DpjVPUDw%2BBOF8It3j6uqicc%2Fa8ToXNmi%2FzBNxek3pv8%3D%0As=b4f6d6e5bbee25bad639a60b61a95c5813d89a00a979388dea429adfb3902498 --- Well, you don't get to be a kernel hacker simply by looking --- good in Speedos. -- Rusty Russell -- 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: send/receive locking
On Sat, Mar 08, 2014 at 09:55:50PM +, Josef Bacik wrote: Hey Hugo will you try the danger branch on btrfs-next, Wang changed the locking a bit. Thanks, Sure. I'll build a kernel tonight and report tomorrow. I'm not sure how repeatable the problem is, though. I'll see if I can quantify that, too. Hugo. Josef Hugo Mills h...@carfax.org.uk wrote: Is there anything that can be done about the issues of btrfs send blocking? I've been writing a backup script (slowly), and several times I've managed to hit a situation where large chunks of the machine grind to a complete halt in D state because the backup script has jammed up. Now, I'm aware that you can't send and receive to the same filesystem at the same time, and that's a restriction I can live with. However, having things that aren't related to the backup process suddenly stop working because the backup script is trying to log its progress to the same FS it's backing up is... umm... somewhat vexing, to say the least. Is this a truly fundamental property of send/receive, or is there likely to be a simple(ish) solution? Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Well, you don't get to be a kernel hacker simply by looking --- good in Speedos. -- Rusty Russell signature.asc Description: Digital signature
Re: send/receive locking
Don't do it on a fs you care about, cow is broken with that branch so it will corrupt your fs. So actually just find Wang's patch that sets skip locking for send and do that. Thanks, Josef Hugo Mills h...@carfax.org.uk wrote: On Sat, Mar 08, 2014 at 09:55:50PM +, Josef Bacik wrote: Hey Hugo will you try the danger branch on btrfs-next, Wang changed the locking a bit. Thanks, Sure. I'll build a kernel tonight and report tomorrow. I'm not sure how repeatable the problem is, though. I'll see if I can quantify that, too. Hugo. Josef Hugo Mills h...@carfax.org.uk wrote: Is there anything that can be done about the issues of btrfs send blocking? I've been writing a backup script (slowly), and several times I've managed to hit a situation where large chunks of the machine grind to a complete halt in D state because the backup script has jammed up. Now, I'm aware that you can't send and receive to the same filesystem at the same time, and that's a restriction I can live with. However, having things that aren't related to the backup process suddenly stop working because the backup script is trying to log its progress to the same FS it's backing up is... umm... somewhat vexing, to say the least. Is this a truly fundamental property of send/receive, or is there likely to be a simple(ish) solution? Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or https://urldefense.proofpoint.com/v1/url?u=http://www.carfax.org.uk/k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=cKCbChRKsMpTX8ybrSkonQ%3D%3D%0Am=mielorsIWCCiMGh9bKTw2yfu58jDUmYHzG5Bs4%2BQ668%3D%0As=e7731595293b5612cadc9ba07854b17052b8c74ac69ddefd02b0437e42086594 --- Well, you don't get to be a kernel hacker simply by looking --- good in Speedos. -- Rusty Russell -- 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: send/receive locking
On Sat, Mar 08, 2014 at 10:02:39PM +, Josef Bacik wrote: Don't do it on a fs you care about, cow is broken with that branch so it will corrupt your fs. So actually just find Wang's patch that sets skip locking for send and do that. Thanks, Aah, that's good to know. It's not an FS I care about massively much, but it'd be a pain to recreate all the setup. I think I'll go cherry picking tomorrow morning. :) Hugo. Josef Hugo Mills h...@carfax.org.uk wrote: On Sat, Mar 08, 2014 at 09:55:50PM +, Josef Bacik wrote: Hey Hugo will you try the danger branch on btrfs-next, Wang changed the locking a bit. Thanks, Sure. I'll build a kernel tonight and report tomorrow. I'm not sure how repeatable the problem is, though. I'll see if I can quantify that, too. Hugo. Josef Hugo Mills h...@carfax.org.uk wrote: Is there anything that can be done about the issues of btrfs send blocking? I've been writing a backup script (slowly), and several times I've managed to hit a situation where large chunks of the machine grind to a complete halt in D state because the backup script has jammed up. Now, I'm aware that you can't send and receive to the same filesystem at the same time, and that's a restriction I can live with. However, having things that aren't related to the backup process suddenly stop working because the backup script is trying to log its progress to the same FS it's backing up is... umm... somewhat vexing, to say the least. Is this a truly fundamental property of send/receive, or is there likely to be a simple(ish) solution? Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Comic Sans goes into a bar, and the barman says, We don't --- serve your type here. signature.asc Description: Digital signature
btrfs send fails with cannot allocate memory
Greetings, When running: btrfs send -vvv subvol | ssh host btrfs receive -vvve dir the command fails well into the send with: ERROR: send ioctl failed with -12: Cannot allocate memory ERROR: unexpected EOF in stream. I've been able to successfully btrfs send other large volumes off of this filesystem, but the two volumes that have a particularly large number of small files both hit this error consistently. The system has 4G of memory. I had hoped that adding a fast swap device would help get past this issue, but no such luck. Despite 60G of SSD swap being available, it was never touched. The box isn't doing anything other than this send. Someone reported a similar issue in the bug tracker, but then abandoned it and moved to using rsync: https://bugzilla.kernel.org/show_bug.cgi?id=60761 On 2013-12-05 Jim Salter j...@jrs-s.net also reported this issue to the mailing list. He was running on a lightly loaded box with 32G of RAM. Duncan 1i5t5.dun...@cox.net mentioned that work on memory leaks was going in on the 3.13 cycle, and that the devs would be interested if it was still an issue on 3.13. Apparently it is. I'm running a fully up-to-date Debian sid box at Linux 3.13.5. I'm including below the full kernel output when this fails. Also, does there exist some workaround for recreating the parent subvolume on another device such that child subvolumes can be btrfs sent against it (perhaps with rsync)? I tried the obvious approaches and couldn't get a seemingly identical volume to be recognized as the parent of a btrfs send by btrfs receive. $ uname -a Linux 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux Mar 9 00:51:42 kernel: [13332.222953] btrfs: page allocation failure: order:5, mode:0x204050 Mar 9 00:51:42 kernel: [13332.229190] CPU: 0 PID: 1225 Comm: btrfs Tainted: G W3.13-1-amd64 #1 Debian 3.13.5-1 Mar 9 00:51:42 kernel: [13332.237951] Hardware name: Supermicro X7SPA-HF/X7SPA-HF, BIOS 1.2a 02/21/12 Mar 9 00:51:42 kernel: [13332.245715] 8800b7d41708 814a0927 00204050 8111b4f3 Mar 9 00:51:42 kernel: [13332.253356] 88013fff9b00 0002 Mar 9 00:51:42 kernel: [13332.260860] 0005 81130fad 88013fff9b08 0002 Mar 9 00:51:42 kernel: [13332.268463] Call Trace: Mar 9 00:51:42 kernel: [13332.270943] [814a0927] ? dump_stack+0x41/0x51 Mar 9 00:51:42 kernel: [13332.276320] [8111b4f3] ? warn_alloc_failed+0xe3/0x130 Mar 9 00:51:42 kernel: [13332.282389] [81130fad] ? next_online_pgdat+0x1d/0x50 Mar 9 00:51:42 kernel: [13332.288369] [8111f5ba] ? __alloc_pages_nodemask+0x81a/0x9d0 Mar 9 00:51:42 kernel: [13332.294936] [8116076f] ? kmem_getpages+0x5f/0x140 Mar 9 00:51:42 kernel: [13332.300639] [81161f1e] ? fallback_alloc+0x15e/0x200 Mar 9 00:51:42 kernel: [13332.306541] [811639fa] ? __kmalloc_track_caller+0x2da/0x4a0 Mar 9 00:51:42 kernel: [13332.313178] [a027cdcf] ? ulist_add_merge+0x1bf/0x290 [btrfs] Mar 9 00:51:42 kernel: [13332.319841] [81130538] ? krealloc+0x48/0xa0 Mar 9 00:51:42 kernel: [13332.325052] [a027cdcf] ? ulist_add_merge+0x1bf/0x290 [btrfs] Mar 9 00:51:42 kernel: [13332.331731] [a027b582] ? find_parent_nodes+0x9c2/0xe90 [btrfs] Mar 9 00:51:42 kernel: [13332.338579] [a027bb02] ? btrfs_find_all_roots+0x92/0x100 [btrfs] Mar 9 00:51:42 kernel: [13332.345603] [a0280d30] ? record_ref+0xc0/0xc0 [btrfs] Mar 9 00:51:42 kernel: [13332.351674] [a027c402] ? iterate_extent_inodes+0x132/0x250 [btrfs] Mar 9 00:51:42 kernel: [13332.358871] [a0284eb3] ? process_extent+0x6c3/0x1130 [btrfs] Mar 9 00:51:42 kernel: [13332.365544] [a02212ed] ? btrfs_buffer_uptodate+0x4d/0x70 [btrfs] Mar 9 00:51:42 kernel: [13332.372569] [a0285bfd] ? changed_cb+0x2dd/0x9d0 [btrfs] Mar 9 00:51:42 kernel: [13332.378805] [a0224db7] ? record_root_in_trans+0xa7/0x100 [btrfs] Mar 9 00:51:42 kernel: [13332.385824] [a0245168] ? read_extent_buffer+0xc8/0x120 [btrfs] Mar 9 00:51:42 kernel: [13332.392669] [a0208a73] ? btrfs_search_slot_for_read+0xa3/0x190 [btrfs] Mar 9 00:51:42 kernel: [13332.400213] [a0286cdc] ? btrfs_ioctl_send+0x9ec/0xbc0 [btrfs] Mar 9 00:51:42 kernel: [13332.406972] [a0256b6a] ? btrfs_ioctl+0xfca/0x25d0 [btrfs] Mar 9 00:51:42 kernel: [13332.413361] [8108706c] ? set_task_cpu+0x5c/0x160 Mar 9 00:51:42 kernel: [13332.418963] [8126f860] ? cpumask_next_and+0x30/0x40 Mar 9 00:51:42 kernel: [13332.424833] [8108d4ef] ? select_task_rq_fair+0x2af/0x6f0 Mar 9 00:51:42 kernel: [13332.431131] [8101981f] ? native_sched_clock+0xf/0x70 Mar 9 00:51:42 kernel: [13332.437088] [8108f827] ? enqueue_task_fair+0x2c7/0xe10 Mar 9 00:51:42 kernel: [13332.443211] [81086e25] ?
Re: Understanding btrfs and backups
On Fri, 7 Mar 2014 04:14:16 PM Sander wrote: But if the filesystem or underlaying disk goes up in flames, the snapshots are toast as well. So you need additional backups, preferably not on the same hardware, for real protection against data loss. ...and don't forget to think about off-site backups too. http://www.flickr.com/photos/94482242@N00/7746409996/ cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs send kernel error btrfs_compare_tree
On Sat, 8 Mar 2014 06:40:52 PM Travis Cross wrote: $ uname -a Linux 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux Not sure if it will help, but Chris Mason has a git tree with currently 4 fixes against 3.13.5: https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/log/?h=for-stable-3.13 Best of luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
Massive BTRFS performance degradation
I am experiencing massive performance degradation on my BTRFS root partition on SSD. Except for regular daily updates, nothing changed in the system. The mount point remained the same: / btrfs rw,noatime,compress=lzo,ssd,space_cache,autodefrag 0 0 but the performance dropped to less than 8% of norm. Before: # dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 1.57307 s, 683 MB/s Now: # dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 26.4373 s, 40.6 MB/s I created a new btrfs partition on the SSD with the same mount options and it is not being affected: # dd if=/mnt/er/tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 1.57634 s, 681 MB/s I also did btrfs filesystem balance start / wit no effect. I tried changing mount options - still no effect. I'd appreciate some suggestions. -- 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
