Re: Mount failure with 5.2.7 but mounts with 5.1.4

On 2019/8/10 下午11:54, Peter Chant wrote: > I attempted update an i5 machine today with kernel 5.2.7. Unfortunately > I could not mount the file system. However, reverting the kernel back > to 5.1.4 allowed it to mount with no issue. > > This issue is not critical to me, machine boots with olde

Re: Mount failure with 5.2.7 but mounts with 5.1.4

On 8/10/19 6:53 PM, Nikolay Borisov wrote: > It seems you have triggered one of the enhanced checks. Looks like the > generation (i.e transaction id) of inode 45745394 seems to be larger > than the inode of the super block. This doesn't make sense. Looking at > the number of this inode it seems to

Re: Mount failure with 5.2.7 but mounts with 5.1.4

On 10.08.19 г. 18:54 ч., Peter Chant wrote: > I attempted update an i5 machine today with kernel 5.2.7. Unfortunately > I could not mount the file system. However, reverting the kernel back > to 5.1.4 allowed it to mount with no issue. > > This issue is not critical to me, machine boots with

Mount failure with 5.2.7 but mounts with 5.1.4

I attempted update an i5 machine today with kernel 5.2.7. Unfortunately I could not mount the file system. However, reverting the kernel back to 5.1.4 allowed it to mount with no issue. This issue is not critical to me, machine boots with older kernel, I have a backup and the machine is only lig

[PATCH 0/1] btrfs: Add global_reserve_size mount option

Hi, This is a follow-up to my previous thread titled ""kernel BUG" and segmentation fault with "device delete"". Since my last message there, I discovered that the problem I was seeing was solved merely by increasing the size of the global reserve to 1G. I don't claim to have anywhere near a compl

[PATCH 1/1] btrfs: Add global_reserve_size mount option

In some circumstances (filesystems with many extents and backrefs), the global reserve gets overrun causing balance and device deletion operations to fail with -ENOSPC. Providing a way for users to increase the global reserve size can allow them to complete the operation. Signed-off-by: Vladimir P

Re: [PATCH 1/3] btrfs-progs: check/lowmem: Check and repair root generation

[...] >> >> Because we have extra transid check in >> btrfs_search_slot()/btrfs_cow_block(). >> >> EXTENT_BAD_TRANSID is to suppress such warning. > > nod > >> >>> >>> So repair_root_generation could possibly be as simple as just linking >>> root->node to the fs_info->recow_ebs and leave the rest