Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On Mon, Jan 22, 2018 at 08:35:43PM -0700, Edmund Nadolski wrote: >On 1/22/18 5:58 AM, Nikolay Borisov wrote: >> >> >> On 21.01.2018 21:08, Zygo Blaxell wrote: >>> This warning appears during execution of the LOGICAL_INO ioctl and >>> appears to be spurious: >>> >>> [ cut here

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On 23.01.2018 05:35, Edmund Nadolski wrote: > On 1/22/18 5:58 AM, Nikolay Borisov wrote: >> >> >> On 21.01.2018 21:08, Zygo Blaxell wrote: >>> This warning appears during execution of the LOGICAL_INO ioctl and >>> appears to be spurious: >>> >>> [ cut here ] >>>

Superblock update: Is there really any benefits of updating synchronously?

Note: This have been mentioned before, but since I see some issues related to superblocks I think it would be good to bring up the question again. According to the information found in the wiki: https://btrfs.wiki.kernel.org/index.php/On-disk_Format#Superblock The superblocks are updated

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On 1/22/18 5:58 AM, Nikolay Borisov wrote: > > > On 21.01.2018 21:08, Zygo Blaxell wrote: >> This warning appears during execution of the LOGICAL_INO ioctl and >> appears to be spurious: >> >> [ cut here ] >> WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391

Re: bad key ordering - repairable?

On Mon, Jan 22, 2018 at 2:06 PM, Claes Fransson wrote: > Hi! > > I really like the features of BTRFS, especially deduplication, > snapshotting and checksumming. However, when using it on my laptop the > last couple of years, it has became corrupted a lot of times. >

[PATCH v2 1/2] btrfs: fix device order consistency

By maintaining the device order consistency it makes reproducing the problems related to missing chunk in the degraded mode much more consistent. So fix this by sorting the devices by devid within the kernel. So that we know which device is assigned to the struct fs_info::latest_bdev when all the

[PATCH v2 0/2] fix device orders consistency

Hi David, Could you pls consider this for 4.16 ? v1->v2: No code change. Change log updated to include the type of problem that this consistency would help. And I don't see patch 2/2 in the ML. So trying to resend. By maintaining the device order (some) consistency it makes reproducing the

Re: bad key ordering - repairable?

On Mon, Jan 22, 2018 at 10:06:58PM +0100, Claes Fransson wrote: > Hi! > > I really like the features of BTRFS, especially deduplication, > snapshotting and checksumming. However, when using it on my laptop the > last couple of years, it has became corrupted a lot of times. > Sometimes I have

Re: Periodic frame losses when recording to btrfs volume with OBS

Hello, I attached to the ffmpeg-mux process for a little while and pasted the result here: https://pastebin.com/XHaMLX8z Can you help me with interpreting this result? If you'd like me to run strace with specific options, please let me know. This is a level of debugging I'm not dealing

Re: Periodic frame losses when recording to btrfs volume with OBS

On 01/22/2018 01:33 PM, Sebastian Ochmann wrote: [ skipping to the traces ;) ] 2866 ffmpeg-mux D [] btrfs_start_ordered_extent+0x101/0x130 [btrfs] [] lock_and_cleanup_extent_if_need+0x340/0x380 [btrfs] [] __btrfs_buffered_write+0x261/0x740 [btrfs] [] btrfs_file_write_iter+0x20f/0x650 [btrfs]

Re: Periodic frame losses when recording to btrfs volume with OBS

First off, thank you for all the responses! Let me reply to multiple suggestions at once in this mail. On 22.01.2018 01:39, Qu Wenruo wrote: Either such mount option has a bug, or some unrelated problem. As you mentioned the output is about 10~50MiB/s, 30s means 300~1500MiBs. Maybe it's

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On Mon, Jan 22, 2018 at 11:34:52AM +0800, Lu Fengqi wrote: > On Sun, Jan 21, 2018 at 02:08:58PM -0500, Zygo Blaxell wrote: > >This warning appears during execution of the LOGICAL_INO ioctl and > >appears to be spurious: > > > > [ cut here ] > > WARNING: CPU: 3 PID:

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On Mon, Jan 22, 2018 at 09:06:23PM +0800, Lu Fengqi wrote: > On Mon, Jan 22, 2018 at 02:38:42PM +0200, Nikolay Borisov wrote: > > > > > >On 22.01.2018 14:19, Lu Fengqi wrote: > >> On 01/22/2018 04:46 PM, Nikolay Borisov wrote: > >>> > >>> > >>> On 22.01.2018 05:34, Lu Fengqi wrote: >

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On 01/21/2018 08:34 PM, Lu Fengqi wrote: > On Sun, Jan 21, 2018 at 02:08:58PM -0500, Zygo Blaxell wrote: >> This warning appears during execution of the LOGICAL_INO ioctl and >> appears to be spurious: >> >> [ cut here ] >> WARNING: CPU: 3 PID: 18172 at

Re: [PATCH RESEND v4 0/4] device_list_add() peparation to add reappearing missing device

On Mon, Jan 22, 2018 at 09:31:47PM +0800, Anand Jain wrote: > Problem was mainly due to the patch 3/4, which tried to access the > return pointer even for the failed condition. The fix is to bring the > device point access under the else part as show below [2]. I have > included this fix

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Thanks for the quick reply, Qu! I forgot to say that I see weird characters in the btrfs check repair in lines "ERROR: DIR_ITEM... name ..." output. Although that can be due to corruption, I seem to remember that a previous version of btrfs-progs I used didn't show that... I also see:

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月22日 22:11, ^m'e wrote: > Hi there, > > After resuming from hibernation, my system shows weirdness; the > following dmesg line alerted me: > > Jan 22 08:10:33 [kernel] BTRFS critical (device sdb3): invalid dir > item name + data len: 3 + 32907 This is true problem. No dir item

Re: Periodic frame losses when recording to btrfs volume with OBS

On 01/20/2018 05:47 AM, Sebastian Ochmann wrote: Hello, I would like to describe a real-world use case where btrfs does not perform well for me. I'm recording 60 fps, larger-than-1080p video using OBS Studio [1] where it is important that the video stream is encoded and written out to disk

btrfs check: backref lost, mismatch with its hash -- can't repair

Hi there, After resuming from hibernation, my system shows weirdness; the following dmesg line alerted me: Jan 22 08:10:33 [kernel] BTRFS critical (device sdb3): invalid dir item name + data len: 3 + 32907 Although I can boot (root is BTRFS), (re-)mount the concerned FS, succesfully scrub it

[PATCH v5 0/4] device_list_add() peparation to add reappearing missing device

(Apply on top of my patchset [PATCH v4 0/6] preparatory work to add device forget for conflict free apply. They don't actually depend on each other though). v4->v5: @3/4: Fix null pointer dereference of device pointer in fn btrfs_scan_one_device() when device_list_add() fails. v3->v4:

[PATCH 4/4] btrfs: drop devid as device_list_add() arg

As struct btrfs_disk_super is being passed, so it can get devid the same way its parent does. Signed-off-by: Anand Jain Reviewed-by: Josef Bacik --- fs/btrfs/volumes.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

[PATCH 3/4] btrfs: get device pointer from device_list_add()

Instead of pointer to btrfs_fs_devices as an arg in device_list_add() better to get pointer to btrfs_device as return value, then we have both, pointer to btrfs_device and btrfs_fs_devices. btrfs_device is needed to handle reappearing missing device. Signed-off-by: Anand Jain

[PATCH 2/4] btrfs: set the total_devices in device_list_add()

There is no other parent for device_list_add() except for btrfs_scan_one_device(), which would set btrfs_fs_devices::total_devices if device_list_add is successful and this can be done with in device_list_add() itself. Signed-off-by: Anand Jain Reviewed-by: Josef Bacik

[PATCH 1/4] btrfs: move pr_info into device_list_add

Commit 60999ca4b403 ("btrfs: make device scan less noisy") adds return value 1 to device_list_add(), so that parent function can call pr_info only when new device is added. Move the pr_info() part into device_list_add() so that this function can be kept simple. Signed-off-by: Anand Jain

Re: [PATCH RESEND v4 0/4] device_list_add() peparation to add reappearing missing device

On 01/20/2018 07:27 AM, David Sterba wrote: On Thu, Jan 18, 2018 at 06:47:17PM +0100, David Sterba wrote: On Thu, Jan 18, 2018 at 10:02:32PM +0800, Anand Jain wrote: (Apply on top of my patchset [PATCH v4 0/6] preparatory work to add device forget for conflict free apply. They don't

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On Mon, Jan 22, 2018 at 02:38:42PM +0200, Nikolay Borisov wrote: > > >On 22.01.2018 14:19, Lu Fengqi wrote: >> On 01/22/2018 04:46 PM, Nikolay Borisov wrote: >>> >>> >>> On 22.01.2018 05:34, Lu Fengqi wrote: According to my bisect result, The frequency of the warning occurrence increased

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On 21.01.2018 21:08, Zygo Blaxell wrote: > This warning appears during execution of the LOGICAL_INO ioctl and > appears to be spurious: > > [ cut here ] > WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391 > find_parent_nodes+0xc41/0x14e0 > Modules

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On 22.01.2018 14:19, Lu Fengqi wrote: > On 01/22/2018 04:46 PM, Nikolay Borisov wrote: >> >> >> On 22.01.2018 05:34, Lu Fengqi wrote: >>> According to my bisect result, The frequency of the warning occurrence >>> increased to the detectable degree after this patch >> >> That sentence implies

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On 01/22/2018 04:46 PM, Nikolay Borisov wrote: On 22.01.2018 05:34, Lu Fengqi wrote: According to my bisect result, The frequency of the warning occurrence increased to the detectable degree after this patch That sentence implies that even before Ed's patch it was possible to trigger those

miss match in btrfs getattr

If i stat a file from userspace: File: ‘/home/builder/leon10’ Size: 0 Blocks: 0 IO Block: 4096 directory Device: 31h/49d Inode: 550109 Links: 1 Inode is 550109 and device id is 49. When I am in the kernel, I try to get that device id (49), I

Re: Periodic frame losses when recording to btrfs volume with OBS

On 22.01.2018 02:39, Qu Wenruo wrote: > > > On 2018年01月21日 23:27, Sebastian Ochmann wrote: >> On 21.01.2018 11:04, Qu Wenruo wrote: >>> >>> >>> On 2018年01月20日 18:47, Sebastian Ochmann wrote: Hello, I would like to describe a real-world use case where btrfs does not perform

Re: Can't mount (even in ro) after power outage - corrupt leaf, open_ctree failed

Hi. Badblocks finished on both disks with no errors. The only messages from kernel during night are 6x perf: interrupt took too long (2511 > 2500), lowering kernel.perf_event_max_sample_rate to 79500 root@nas:~# smartctl -l scterc /dev/sda smartctl 6.6 2016-05-31 r4324

Re: Periodic frame losses when recording to btrfs volume with OBS

Sebastian Ochmann posted on Sun, 21 Jan 2018 16:27:55 +0100 as excerpted: > On 21.01.2018 11:04, Qu Wenruo wrote: >> >> >> On 2018年01月20日 18:47, Sebastian Ochmann wrote: >>> Hello, >>> >>> I would like to describe a real-world use case where btrfs does not >>> perform well for me. I'm recording

Re: [PATCH] btrfs: remove spurious WARN_ON(ref->count) in find_parent_nodes

On 22.01.2018 05:34, Lu Fengqi wrote: > According to my bisect result, The frequency of the warning occurrence > increased to the detectable degree after this patch That sentence implies that even before Ed's patch it was possible to trigger those warnings, is that true? Personally I've never

Re: [PATCH v2] btrfs: Add chunk allocation ENOSPC debug message for enospc_debug mount option

On 22.01.2018 07:50, Qu Wenruo wrote: > Enospc_debug makes extent allocator to print more debug messages, > however for chunk allocation, there is no debug message for enospc_debug > at all. > > This patch will add message for the following parts of chunk allocator: > > 1) No rw device at all

Re: [PATCH v2.1 2/3] btrfs-progs: dir-item: Don't do extra filetype validaction check for btrfs_match_dir_item_name

On 22.01.2018 07:45, Qu Wenruo wrote: > verify_dir_item() is called in btrfs_match_dir_item_name() to ensure we > won't search beyond item boundary and does extra filetype check. > > However in the follow call chain, such extra filetype check can cause > problems: > > 1) btrfs_add_link() >

btrfs inode is different across file systems ?

Hey, If I get btrfs inode in this way: btrfs_ino(inode) implemented at btrfs_inode.h: static inline u64 btrfs_ino(struct inode *inode) { u64 ino = BTRFS_I(inode)->location.objectid; if (!ino || BTRFS_I(inode)->location.type == BTRFS_ROOT_ITEM_KEY) ino = inode->i_ino; return ino; } Is that inode