On Fri, Jun 06, 2014 at 01:11:17PM +0100, Filipe David Manana wrote:
On Fri, Jun 6, 2014 at 7:25 AM, Liu Bo bo.li@oracle.com wrote:
Several reports about leaf corruption has been floating on the list, one of
them
points to __btrfs_drop_extents(), and we find that the leaf becomes
The skinny extents are intepreted incorrectly in scrub_print_warning(),
and end up hitting the BUG() in btrfs_extent_inline_ref_size.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/backref.c | 30 +++---
fs/btrfs/backref.h | 4 ++--
fs/btrfs/scrub.c | 5 +++--
We want to make sure the point is still within the extent item, not to verify
the memory it's pointing to.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/backref.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index
On Fri, Jun 06, 2014 at 02:02:07PM +, Holger Hoffstätte wrote:
On Fri, 06 Jun 2014 14:25:58 +0800, Liu Bo wrote:
Several reports about leaf corruption has been floating on the list, one
of them points to __btrfs_drop_extents(), and we find that the leaf
becomes corrupted after
On Sun, Jun 8, 2014 at 11:54 AM, Liu Bo bo.li@oracle.com wrote:
On Fri, Jun 06, 2014 at 01:11:17PM +0100, Filipe David Manana wrote:
On Fri, Jun 6, 2014 at 7:25 AM, Liu Bo bo.li@oracle.com wrote:
Several reports about leaf corruption has been floating on the list, one
of them
When cloning into a file, we were correctly replacing the extent
items in the target range and removing the extent maps. However
we weren't replacing the extent maps with new ones that point to
the new extents - as a consequence, an incremental fsync (when the
inode doesn't have the full sync
On Sun, Jun 8, 2014 at 12:11 PM, Filipe David Manana fdman...@gmail.com wrote:
On Sun, Jun 8, 2014 at 11:54 AM, Liu Bo bo.li@oracle.com wrote:
On Fri, Jun 06, 2014 at 01:11:17PM +0100, Filipe David Manana wrote:
On Fri, Jun 6, 2014 at 7:25 AM, Liu Bo bo.li@oracle.com wrote:
Several
On Thursday, June 5, 2014 7:11:44 PM MSK, Roman Mamedov wrote:
Yeah, a PSA of sorts: take whatever SSDs you have and use, and go to the
manufacturer's website (right *NOW* :) to check if they have a
newer firmware,
or to ensure that you have the latest version. There are such horrible
bugs
On Friday, June 6, 2014 3:58:26 AM MSK, Martin K. Petersen wrote:
Until then, the following command will give you the answer:
# smartctl -l gplog,0x13 /dev/sda | grep :
000: 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
||
^^ ^^
These two 01 fields
Pavel == Pavel Volkov sai...@lists.xtsubasa.org writes:
Pavel Is mine a dinosaur drive?
[...]
Pavel General Purpose Log 0x13 does not exist (override with '-T
Pavel permissive' option)
The only flags defined in general purpose log page 0x13 are the queued
trim ones. So there is no compelling
When cloning into a file, we were correctly replacing the extent
items in the target range and removing the extent maps. However
we weren't replacing the extent maps with new ones that point to
the new extents - as a consequence, an incremental fsync (when the
inode doesn't have the full sync
Regression test for btrfs ioctl clone operation + fsync + log
recovery. The issue was that doing an fsync after cloning into
a file didn't gave any persistence guarantees as it should.
What happened was that the in memory metadata (extent maps)
weren't updated, which made the fsync code not able
Original Message
Subject: [PATCH V3] Btrfs: device_list_add() should not update list when
mounted
From: Anand Jain anand.j...@oracle.com
To: linux-btrfs@vger.kernel.org
Date: 2014年06月06日 11:26
(looks like there was some sendmail problem I don't see this in the btrfs list,
Hi Qu,
Thanks for your patch.
The patch works fine,
but unfortunately the solution seems not so generic.
The patch just avoid the dirty work to distinguish devices with same uuid,
This will fix the bug with dev scan, but when you umount the fs and
mount it again, it will use the old
Original Message
Subject: Re: [PATCH V3] Btrfs: device_list_add() should not update list
when mounted
From: Anand Jain anand.j...@oracle.com
To: Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org
Date: 2014年06月09日 10:19
Hi Qu,
Thanks for your patch.
The patch
The skinny extents are intepreted incorrectly in scrub_print_warning(),
and end up hitting the BUG() in btrfs_extent_inline_ref_size.
Reported-by: Konstantinos Skarlatos k.skarla...@gmail.com
Signed-off-by: Liu Bo bo.li@oracle.com
---
v2: Add a 'Reported-by' tag.
fs/btrfs/backref.c | 30
Several reports about leaf corruption has been floating on the list, one of them
points to __btrfs_drop_extents(), and we find that the leaf becomes corrupted
after __btrfs_drop_extents(), it's really a rare case but it does exist.
The problem turns out to be btrfs_next_leaf() called in
As mentioned in the other thread.. we expect user to check the devices
before / after mount and wipefs the disks which should not belong to
the fsid.
my bad. I just realized that unmount and wipefs may not be an
viable choice in case of btrfs as root fs.
For the case you mentioned, I
18 matches
Mail list logo
