Ping.
No new comment nor merged?
Thanks,
Qu
Original Message
Subject: [PATCH 0/7] Allow btrfsck to reset csum of all tree blocks, AKA
dangerous mode.
From: Qu Wenruo
To:
Date: 2015年02月04日 15:16
Btrfs's metadata csum is a good mechanism, keeping bit error away from
sensi
The BTRFS_IOC_RESIZE ioctl returns 0 on success, negative for POSIX
errors, and positive for btrfs-specific errors.
If resize fails with a btrfs-specific error, decode the error and
report it. If we can't decode the error, report its numeric value so
that the userspace tool is not instantly usele
On Tue, Apr 21, 2015 at 08:49:08PM -0400, Chris Mason wrote:
> On 04/21/2015 05:47 PM, Mark Fasheh wrote:
> > btrfs_check_shared() is leaking a return value of '1' from
> > find_parent_nodes(). As a result, callers (in this case, extent_fiemap())
> > are told extents are shared when they are not. T
On 04/21/2015 05:47 PM, Mark Fasheh wrote:
> btrfs_check_shared() is leaking a return value of '1' from
> find_parent_nodes(). As a result, callers (in this case, extent_fiemap())
> are told extents are shared when they are not. This in turn broke fiemap on
> btrfs for kernels v3.18 and up.
>
> Th
Original Message
Subject: Re: Carefully crafted BTRFS-image causes kernel to crash
From: Zygo Blaxell
To: Qu Wenruo
Date: 2015年04月21日 23:17
On Tue, Apr 21, 2015 at 11:16:44AM +0800, Qu Wenruo wrote:
Original Message
Subject: Carefully crafted BTRFS-imag
On Mon, 20 Apr 2015 02:45:39 -0700 Christoph Hellwig
wrote:
> On Mon, Apr 20, 2015 at 04:27:00PM +1000, NeilBrown wrote:
> > A worthwhile goal, but I certainly wouldn't consider pursuing it until what
> > I
> > have submitted so far as been accepted - let's not reject "good" while
> > waiting fo
See also https://bugzilla.kernel.org/show_bug.cgi?id=97041
The btrfs-image attached to this bug causes the userland tools v3.19.1
to crash with a SIGFPE. The problem is that map->sub_stripes in
__btrfs_map_block() is allowed to be 0 before entering a division.
The userland tool crashes. The kerne
See also https://bugzilla.kernel.org/show_bug.cgi?id=97031
The btrfs-image attached to this bug causes the userland tools v3.19.1
to crash with a SIGFPE. The problem is that map->stripe_len in
__btrfs_map_block() is allowed to be 0 before entering a division.
The userland tool crashes.
The kernel
See also https://bugzilla.kernel.org/show_bug.cgi?id=97021
The btrfs-image attached to this bug causes the userland tools v3.19.1
to crash by reaching a call to abort().
(gdb) run check btrfs_fukked_abort_cmds-check:5919.bin
Starting program: /usr/sbin/btrfs check btrfs_fukked_abort_cmds-check:59
btrfs_check_shared() is leaking a return value of '1' from
find_parent_nodes(). As a result, callers (in this case, extent_fiemap())
are told extents are shared when they are not. This in turn broke fiemap on
btrfs for kernels v3.18 and up.
The fix is simple - we just have to clear 'ret' after we
On Sun, Apr 19, 2015 at 10:27 PM, Zygo Blaxell
wrote:
> On Sun, Apr 19, 2015 at 10:31:02PM +0800, Craig Ringer wrote:
>> I'm curious as to whether +C has any effect on BTRFS's durability, too.
>
> I would expect it to be strictly equal to or worse than the CoW
> durability. It would have all the
On Tue, Apr 21, 2015 at 11:16:44AM +0800, Qu Wenruo wrote:
> Original Message
> Subject: Carefully crafted BTRFS-image causes kernel to crash
> From: Lukas Lueg
> To:
> Date: 2015年04月21日 07:04
>
> >See also https://bugzilla.kernel.org/show_bug.cgi?id=96971
> >
> >
> >I've iden
On 2015-04-21 05:38, Russell Coker wrote:
On Tue, 21 Apr 2015, Qu Wenruo wrote:
Although we may add extra check for such problem to improve robustness,
but IMHO it's not a real world problem.
Some of the ReiserFS developers gave a similar reaction to some of my bug
reports. ReiserFS wasn't t
On Tue, 21 Apr 2015, Christoph Hellwig wrote:
> On Mon, Apr 20, 2015 at 01:58:35PM +0100, Al Viro wrote:
> > > > Do ext4 and xfs support this, do you know?
> > >
> > > Yes. As do f2fs, ocfs2, gfs2, ceph and NFSv4.2
> >
> > Er... Nominally, gfs2 supports it. By treating all files as "there's a
On Tue, 21 Apr 2015, Qu Wenruo wrote:
> Although we may add extra check for such problem to improve robustness,
> but IMHO it's not a real world problem.
Some of the ReiserFS developers gave a similar reaction to some of my bug
reports. ReiserFS wasn't the most robust filesystem.
I think that
Hugo Mills carfax.org.uk> writes:
>
> On Mon, Apr 20, 2015 at 02:15:47PM +, sri wrote:
> > Hi,
> >
> > I have a subvolume with only one file (file.txt) with 5Mb size.
> > under /btrfs/subvol1/
> > 1)
> > I have created 1st snapshot /btrfs/snap1_subvol1. Then I ran "btrfs
> > send" and give
On Mon, Apr 20, 2015 at 01:58:35PM +0100, Al Viro wrote:
> > > Do ext4 and xfs support this, do you know?
> >
> > Yes. As do f2fs, ocfs2, gfs2, ceph and NFSv4.2
>
> Er... Nominally, gfs2 supports it. By treating all files as "there's a
> hole starting at EOF". Same as ext2 or even minix...
Y
17 matches
Mail list logo
