During the mkfs.btrfs -b btrfs_prepare_device() zeros all
the superblock bytenr locations only if the bytenr is below the
blockcount. The problem with this is that if the BTRFS is recreated
with a smaller size then we will leave the stale superblock in the disk
which shall confuse the recovery. As
diff --git a/cmds-inspect-dump-tree.c b/cmds-inspect-dump-tree.c
index df44bb635c9c..d2676ce55af7 100644
--- a/cmds-inspect-dump-tree.c
+++ b/cmds-inspect-dump-tree.c
@@ -198,6 +198,7 @@ const char * const cmd_inspect_dump_tree_usage[] = {
"-u|--uuid print only the uuid tre
When looping btrfs/074 with many cpus (>= 8), it's possible to trigger
kernel warning due to first key verification:
[ 4239.523446] WARNING: CPU: 5 PID: 2381 at fs/btrfs/disk-io.c:460
btree_read_extent_buffer_pages+0x1ad/0x210
[ 4239.523830] Modules linked in:
[ 4239.524630] RIP: 0010:btree_read_
The original first key check is handled in
btree_read_extent_buffer_pages(), which is good enough for level check,
but to verify first key, we need at least read lock on the extent
buffer, or we can hit some race and cause false alert.
Fix it by adding new verifcation function: btrfs_verify_first_
On 12.04.2018 13:00, Qu Wenruo wrote:
> The original first key check is handled in
> btree_read_extent_buffer_pages(), which is good enough for level check,
> but to verify first key, we need at least read lock on the extent
> buffer, or we can hit some race and cause false alert.
>
> Fix it by
On 2018年04月12日 18:59, Nikolay Borisov wrote:
>
>
> On 12.04.2018 13:00, Qu Wenruo wrote:
>> The original first key check is handled in
>> btree_read_extent_buffer_pages(), which is good enough for level check,
>> but to verify first key, we need at least read lock on the extent
>> buffer, or we
On 12.04.2018 14:48, Qu Wenruo wrote:
>
>
> On 2018年04月12日 18:59, Nikolay Borisov wrote:
>>
>>
>> On 12.04.2018 13:00, Qu Wenruo wrote:
>>> The original first key check is handled in
>>> btree_read_extent_buffer_pages(), which is good enough for level check,
>>> but to verify first key, we need
On Wed, Apr 11, 2018 at 05:03:15PM -0700, Omar Sandoval wrote:
> >
> > On 2018年04月04日 16:53, Nikolay Borisov wrote:
> > > On 3.04.2018 10:30, Qu Wenruo wrote:
> > >> I didn't see this patch merged in your misc-next branch but only the
> > >> remaining patches.
> > >>
> > >> However without this p
On Tue, Apr 03, 2018 at 03:30:34PM +0800, Qu Wenruo wrote:
> I didn't see this patch merged in your misc-next branch but only the
> remaining patches.
>
> However without this patch, btrfs qgroup reserved space will get
> obviously increased as prealloc metadata reserved space is never freed
> unt
On Thu, Apr 12, 2018 at 06:00:02PM +0800, Qu Wenruo wrote:
> When looping btrfs/074 with many cpus (>= 8), it's possible to trigger
> kernel warning due to first key verification:
>
> [ 4239.523446] WARNING: CPU: 5 PID: 2381 at fs/btrfs/disk-io.c:460
> btree_read_extent_buffer_pages+0x1ad/0x210
>
On Thu, Apr 12, 2018 at 06:00:03PM +0800, Qu Wenruo wrote:
> The original first key check is handled in
> btree_read_extent_buffer_pages(), which is good enough for level check,
> but to verify first key, we need at least read lock on the extent
> buffer, or we can hit some race and cause false ale
On 2018年04月12日 21:35, David Sterba wrote:
> On Thu, Apr 12, 2018 at 06:00:02PM +0800, Qu Wenruo wrote:
>> When looping btrfs/074 with many cpus (>= 8), it's possible to trigger
>> kernel warning due to first key verification:
>>
>> [ 4239.523446] WARNING: CPU: 5 PID: 2381 at fs/btrfs/disk-io.c:46
On Wed, Apr 11, 2018 at 01:22:23PM +0300, Ilan Schwarts wrote:
> Hi
> While trying to compile my kernel module on suse 12.2 kernel
> 4.4.103-92.53-default
> I recieve the following warning: error: redefinition of 'struct
> btrfs_ioctl_defrag_range_args
> I see that struct is defined in 2 places:
>
On Tue, Apr 10, 2018 at 01:50:21PM +, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: c71bf099abdd Btrfs: Avoid orphan inodes cleanup while
> replaying log.
>
> The bot has also determined it's
Hi,
We came across what seems to be a crash consistency bug on btrfs and
f2fs. When we create a symlink for a file and fsync the symlink, on
recovery from crash, the fsync-ed file is missing.
You can reproduce this behaviour using this minimal workload :
1. symlink (foo, bar)
2. open bar
3. fsyn
Hi All,
I had a ctree.c error during a send/receive backup:
kernel BUG at fs/btrfs/ctree.c:1862
Nothing seemed to go wrong otherwise on the file system. After
restarting the send, it completed, but I'm left with a subvolume I can't
delete:
BTRFS warning (device sdb1): Attempt to delete sub
When looping btrfs/074 with many cpus (>= 8), it's possible to trigger
kernel warning due to first key verification:
[ 4239.523446] WARNING: CPU: 5 PID: 2381 at fs/btrfs/disk-io.c:460
btree_read_extent_buffer_pages+0x1ad/0x210
[ 4239.523830] Modules linked in:
[ 4239.524630] RIP: 0010:btree_read_
On 2018/04/11 3:23, David Sterba wrote:
> On Mon, Mar 19, 2018 at 04:27:09PM +0900, Misono, Tomohiro wrote:
>> changelog:
>>
>> v2-> v3
>> - fix kbuild test bot warning
>> v1 -> v2
>> - completely reimplement 1st/2nd ioctl to have user friendly api
>> - various cleanup, remove unnecessary goto
On Mon, Apr 09, 2018 at 01:28:30PM +0800, Anand Jain wrote:
> Verify if the superblock corruption is handled correctly.
>
> Signed-off-by: Anand Jain
> ---
> v2->v3:
> Provide the disk to be corrupted as an arg, instead of swapping the devices,
> so drop mount_opt_minus_args().
> 159.out slig
@@ -4569,8 +4560,10 @@ static long btrfs_ioctl_balance(struct file *file, void
__user *arg)
/* this is either (2) or (3) */
if (!atomic_read(&fs_info->balance_running)) {
mutex_unlock(&fs_info->balance_mutex);
- if (
Qu Wenruo posted on Thu, 12 Apr 2018 07:25:15 +0800 as excerpted:
> On 2018年04月11日 23:33, Tom Vincent wrote:
>> My btrfs laptop had a power outage and failed to boot with "parent
>> transid verify failed..." errors. (I have backups).
>
> Metadata corruption, again.
>
> I'm curious about what's
On Thu, Apr 12, 2018 at 8:51 PM, Jayashree Mohan
wrote:
> Hi,
>
> We came across what seems to be a crash consistency bug on btrfs and
> f2fs. When we create a symlink for a file and fsync the symlink, on
> recovery from crash, the fsync-ed file is missing.
>
> You can reproduce this behaviour usi
22 matches
Mail list logo
