Re: fs/btrfs/ctree.h:1559 warnings
On 2 May 2018 at 20:43, Paul Richards <paul.richa...@gmail.com> wrote: > The issue I have now is that the filesystem cannot be unmounted. > "umount" reports "target is busy", but I cannot find anything relevant > with "lsof" or "fuser" (this is a very quiet home NAS). Is this > something related to the resize? > Oh please ignore me. I forgot to unmount "/storage/.snapshots" before "/storage". Everything looks fine. -- 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: fs/btrfs/ctree.h:1559 warnings
On 29 April 2018 at 02:50, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > > > On 2018年04月29日 04:16, Paul Richards wrote: >> On 28 April 2018 at 20:39, Patrik Lundquist <patrik.lundqu...@gmail.com> >> wrote: >>> On 28 April 2018 at 20:54, Paul Richards <paul.richa...@gmail.com> wrote: >>>> >>>> Hi, >>>> I recently upgraded from Linux 4.4.0 to 4.13.0 (Ubuntu 16.04 stock to >>>> hwe kernel). >>>> >>>> Since then, I've noticed lots of btrfs warnings in dmesg (example at >>>> the end). I believe these warnings to be benign, and they relate to >>>> my partition not being a multiple of 4KiB in size (I confirmed that >>>> alignment is okay in this instance). >>> >>> >>> Run btrfs rescue fix-device-size . >>> >> >> >> Excellent, that looks like exactly what I need. It's a shame my >> google-fu didn't uncover it before I posted. >> >> However, the "fix-device-size" sub-command is not available in >> btrfs-tools (v4.4) from Ubuntu 16.04. I guess my original question >> still stands. Is this warning safe for me to ignore? > > Safe to ignore. > > And there is another way to solve it. > > Shrink your fs by 4K, and newer kernel will do the round down for you > and result new device size to be aligned. > > Thanks, > Qu > Thanks - this fixed the issue for me (modulo my problem below..). I thought I should follow up with exactly what I did for anyone else looking to fix this. I used this command to identify which devices were not exact multiples of 4KiB in size: % btrfs fi show --raw /storage Label: none uuid: c4b33374-9006-47d7-b6f9-2136dc988f9a Total devices 3 FS bytes used 7027891666944 devid1 size 8001560055808 used 4691211583488 path /dev/mapper/storage1 devid3 size 8001560059392 used 4691211583488 path /dev/mapper/storage3 devid4 size 8001560059392 used 4690104287232 path /dev/mapper/storage4 I used a calculator to determine that devids 3 and 4 were the offenders (they don't divide by 4006 nicely). I then ran: % btrfs fi resize 3:-1K /storage % btrfs fi resize 4:-1K /storage Which has resulted in this: % btrfs fi show --raw /storage Label: none uuid: c4b33374-9006-47d7-b6f9-2136dc988f9a Total devices 3 FS bytes used 7027891666944 devid1 size 8001560055808 used 4691211583488 path /dev/mapper/storage1 devid3 size 8001560055808 used 4691211583488 path /dev/mapper/storage3 devid4 size 8001560055808 used 4690104287232 path /dev/mapper/storage4 PERFECT! :) The issue I have now is that the filesystem cannot be unmounted. "umount" reports "target is busy", but I cannot find anything relevant with "lsof" or "fuser" (this is a very quiet home NAS). Is this something related to the resize? For what it's worth, here are the sizes of the underlying devices (output somewhat redacted): % lsblk -b NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT storage3 253:20 8001560059392 0 crypt storage4 253:10 8001560059392 0 crypt storage1 253:00 8001560059392 0 crypt /storage/.snapshots It looks like all the devices are an odd size. One of these disks was added after the others, presumably with a newer kernel that rounded the btrfs dev size downwards. -- 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: fs/btrfs/ctree.h:1559 warnings
On 28 April 2018 at 20:39, Patrik Lundquist <patrik.lundqu...@gmail.com> wrote: > On 28 April 2018 at 20:54, Paul Richards <paul.richa...@gmail.com> wrote: >> >> Hi, >> I recently upgraded from Linux 4.4.0 to 4.13.0 (Ubuntu 16.04 stock to >> hwe kernel). >> >> Since then, I've noticed lots of btrfs warnings in dmesg (example at >> the end). I believe these warnings to be benign, and they relate to >> my partition not being a multiple of 4KiB in size (I confirmed that >> alignment is okay in this instance). > > > Run btrfs rescue fix-device-size . > Excellent, that looks like exactly what I need. It's a shame my google-fu didn't uncover it before I posted. However, the "fix-device-size" sub-command is not available in btrfs-tools (v4.4) from Ubuntu 16.04. I guess my original question still stands. Is this warning safe for me to ignore? I will likely upgrade to Ubuntu 18.04 in a few months at which point I'll get a newer btrfs-tools, but until then can I safely ignore this warning? -- 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
fs/btrfs/ctree.h:1559 warnings
Hi, I recently upgraded from Linux 4.4.0 to 4.13.0 (Ubuntu 16.04 stock to hwe kernel). Since then, I've noticed lots of btrfs warnings in dmesg (example at the end). I believe these warnings to be benign, and they relate to my partition not being a multiple of 4KiB in size (I confirmed that alignment is okay in this instance). I would like to confirm a couple of things: 1. Is this warning definitely safe to ignore? 2. If this warning is a false alarm, has it been removed in more recent kernel versions (after 4.13)? I'd like to know if the warning will go away when I upgrade the kernel further, or if I'll have to recreate my partitions in order to resolve these warnings (which clog dmesg). Thanks. Example: [101320.529729] [ cut here ] [101320.529761] WARNING: CPU: 1 PID: 5027 at /build/linux-hwe-v6kHHF/linux-hwe-4.13.0/fs/btrfs/ctree.h:1559 btrfs_update_device+0x1b4/0x1c0 [btrfs] [101320.529762] Modules linked in: binfmt_misc dm_crypt crypto_simd glue_helper aes_x86_64 algif_skcipher af_alg gpio_ich intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf ipmi_ssif serio_raw ipmi_si hpilo acpi_power_meter ipmi_devintf ipmi_msghandler mac_hid lpc_ich shpchp ie31200_edac ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mgag200 i2c_algo_bit ttm crct10dif_pclmul uas drm_kms_helper tg3 syscopyarea sysfillrect sysimgblt fb_sys_fops crc32_pclmul ptp ghash_clmulni_intel cryptd psmouse ahci libahci usb_storage drm pps_core [101320.529803] CPU: 1 PID: 5027 Comm: kworker/u128:8 Tainted: G W 4.13.0-39-generic #44~16.04.1-Ubuntu [101320.529804] Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 06/06/2014 [101320.529809] Workqueue: writeback wb_workfn (flush-btrfs-2) [101320.529811] task: 9602b332d900 task.stack: a4ca02e08000 [101320.529829] RIP: 0010:btrfs_update_device+0x1b4/0x1c0 [btrfs] [101320.529830] RSP: 0018:a4ca02e0b498 EFLAGS: 00010206 [101320.529831] RAX: 0fff RBX: RCX: 074702251e00 [101320.529832] RDX: 0004 RSI: 3f5c RDI: 9602947aedf0 [101320.529833] RBP: a4ca02e0b4e0 R08: 3f60 R09: a4ca02e0b450 [101320.529834] R10: 1000 R11: 0003 R12: 9602b3a391c0 [101320.529835] R13: 9602f1bbe400 R14: 3f3c R15: 9602947aedf0 [101320.529837] FS: () GS:9602fa44() knlGS: [101320.529838] CS: 0010 DS: ES: CR0: 80050033 [101320.529839] CR2: 7feb823bb000 CR3: 2740a005 CR4: 001606e0 [101320.529840] Call Trace: [101320.529860] btrfs_finish_chunk_alloc+0x134/0x510 [btrfs] [101320.529877] ? free_extent_buffer+0x4b/0xa0 [btrfs] [101320.529891] ? btrfs_insert_item+0x80/0xf0 [btrfs] [101320.529906] btrfs_create_pending_block_groups+0x135/0x250 [btrfs] [101320.529919] ? btrfs_create_pending_block_groups+0x135/0x250 [btrfs] [101320.529936] __btrfs_end_transaction+0x8e/0x2e0 [btrfs] [101320.529951] btrfs_end_transaction+0x10/0x20 [btrfs] [101320.529965] find_free_extent+0xd12/0xfe0 [btrfs] [101320.529981] ? btrfs_defrag_leaves+0x360/0x360 [btrfs] [101320.529996] btrfs_reserve_extent+0x9b/0x1f0 [btrfs] [101320.530011] cow_file_range.isra.62+0x15b/0x430 [btrfs] [101320.530026] run_delalloc_range+0x2ba/0x3a0 [btrfs] [101320.530042] ? find_lock_delalloc_range.constprop.55+0x1d3/0x200 [btrfs] [101320.530058] writepage_delalloc.isra.45+0x10d/0x170 [btrfs] [101320.530073] __extent_writepage+0xd9/0x300 [btrfs] [101320.530088] extent_write_cache_pages.constprop.52+0x2c5/0x400 [btrfs] [101320.530104] extent_writepages+0x5c/0x90 [btrfs] [101320.530119] ? btrfs_releasepage+0x20/0x20 [btrfs] [101320.530133] btrfs_writepages+0x28/0x30 [btrfs] [101320.530136] do_writepages+0x1f/0x70 [101320.530138] __writeback_single_inode+0x45/0x330 [101320.530141] ? fprop_reflect_period_percpu.isra.5+0x8e/0xc0 [101320.530143] writeback_sb_inodes+0x26a/0x600 [101320.530146] __writeback_inodes_wb+0x92/0xc0 [101320.530148] wb_writeback+0x274/0x330 [101320.530151] wb_workfn+0x18a/0x3b0 [101320.530152] ? wb_workfn+0x18a/0x3b0 [101320.530156] process_one_work+0x15b/0x410 [101320.530158] worker_thread+0x4b/0x460 [101320.530161] kthread+0x10c/0x140 [101320.530163] ? process_one_work+0x410/0x410 [101320.530164] ? kthread_create_on_node+0x70/0x70 [101320.530166] ret_from_fork+0x35/0x40 [101320.530168] Code: 00 4c 89 ff 45 31 c0 ba 10 00 00 00 4c 89 f6 e8 73 23 ff ff 4c 89 ff e8 7b f5 fc ff e9 d9 fe ff ff b8 f4 ff ff ff e9 d9 fe ff ff <0f> ff eb b8 e8 53 08 01 cb 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 [101320.530199] ---[ end trace 7a108943044dc9ba ]--- -- To unsubscribe from this list: send the line
How to replace a failed drive in btrfs RAID 1 filesystem
Hello there, I have a 3 disk btrfs RAID 1 filesystem, with a single failed drive. Before I attempt any recovery I’d like to ask what is the recommended approach? (The wiki docs suggest consulting here before attempting recovery[1].) The system is powered down currently and a replacement drive is being delivered soon. Should I use “replace”, or “add” and “delete”? Once replaced should I rebalance and/or scrub? I believe that the recovery may involve mounting in degraded mode. If I do this, how do I later get out of degraded mode, or if it’s automatic how do i determine when I’m out of degraded mode? The system is running Ubuntu 16.04 LTS with kernel 4.4.0. 1: “it may be helpful to consult the mailing list of irc channel before attempting recovery”. - https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Replacing_failed_devices -- 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: Does balance implicitly defrag?
On 8 July 2013 22:12, David Sterba dste...@suse.cz wrote: On Tue, Jul 02, 2013 at 02:28:25PM +0100, Paul Richards wrote: When I run btrfs filesystem balance, does this implicitly defragment the filesystem? (Assuming there is plenty free space) In some sense it defragments the filesystem. The blockgroups are moved around based on the balance filter. Here a blockgroup consists of various and unrelated file extents. Extents representing a single file are not made contiguous, this is done by 'btrfs file defrag'. I think that the final layout of the 1G-chunks is not necessarily contiguous, ie. it depends on the chunk-allocator, the time of the allocation request and there's nothing like preallocate 30G for whole balance and put all data together because the space is available. Okay, I think I understand. It sounds like balance will fix external fragmentation (within the block groups, up to the 1G-chunk granularity), and will not fix any internal fragmentation. Thanks. :) -- Paul Richards @pauldoo -- 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
Swap file on btrfs fails (swapfile has holes)
Hi, I have just recently installed Debian squeeze with a root filesystem on btrfs [1]. I have noticed however that I cannot set up a swap file stored on the btrfs volume: dd if=/dev/zero of=/var/swap bs=16M count=4 mkswap /var/swap chmod 0 /var/swap swapon /var/swap [ 01751.879759] swapon: swapfile has holes swapon: /var/swap: swapon failed: Invalid argument For now I've set up a swap file under /boot (ext4), but is swap on btrfs expected to work? I'm using the stock Debian linux kernel 2.6.32-5-amd64. 1: This took a little bit of work - http://lists.debian.org/debian-user/2011/01/msg00217.html -- Paul Richards @pauldoo -- 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
