On Fri, Jun 26, 2015 at 7:08 AM, David Sterba dste...@suse.cz wrote:
On Mon, Apr 06, 2015 at 10:09:15PM -0700, Davide Italiano wrote:
- We call inode_size_ok() only if FL_KEEP_SIZE isn't specified.
- As an optimisation we can skip the call if (off + len)
isn't greater than the current size
On 07/20/2015 07:29 AM, Christoph Hellwig wrote:
Currently we have two different ways to signal an I/O error on a BIO:
(1) by clearing the BIO_UPTODATE flag
(2) by returning a Linux errno value to the bi_end_io callback
The first one has the drawback of only communicating a single possible
From: Zhao Lei zhao...@cn.fujitsu.com
btrfs progs output following error message when doing resize on
no-enouth-free-space case:
# btrfs filesystem resize +10g /mnt/btrfs_5gb
Resize '/mnt/btrfs_5gb' of '+10g'
ERROR: unable to resize '/mnt/btrfs_5gb' - File too large
#
It is not a good
Hi, Taeha Kim
-Original Message-
From: linux-btrfs-ow...@vger.kernel.org
[mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Taeha Kim
Sent: Wednesday, July 22, 2015 1:20 PM
To: linux-btrfs@vger.kernel.org
Subject: resize: File too large
Hello,
I met a problem when resize
Zygo Blaxell wrote on 2015/07/21 23:49 -0400:
On Wed, Jul 22, 2015 at 09:49:52AM +0800, Qu Wenruo wrote:
Change subject to reflect the core of the conversation.
Zygo Blaxell wrote on 2015/07/21 18:14 -0400:
On Tue, Jul 21, 2015 at 02:52:38PM +0800, Qu Wenruo wrote:
Zygo Blaxell wrote on
On Tue, 23 Jun 2015 02:52:43 AM Chris Murphy wrote:
OK I actually don't know what the intended block layer behavior is
when unplugging a device, if it is supposed to vanish, or change state
somehow so that thing that depend on it can know it's missing or
what. So the question here is, is this
Hi, Sasà Vita
Thanks for reporting!
-Original Message-
From: linux-btrfs-ow...@vger.kernel.org
[mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Sasà Vita
Sent: Wednesday, July 22, 2015 1:52 PM
To: linux-btrfs@vger.kernel.org
Subject: stack trace (free_fs_root) with either
Hi Chris,
Is there anything wrong with it?
It has been 2 weeks, and it's still not in your for linus branch.
Is there anything wrong?
Thanks,
Qu
Qu Wenruo wrote on 2015/07/08 11:35 +0800:
Hi Chris,
Sorry for the late pull request, this one should be sent on Monday. :(
This patchset is
subscribe linux-btrfs
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2015-07-21 22:01, Qu Wenruo wrote:
Steve Dainard wrote on 2015/07/21 14:07 -0700:
I don't know if this has any bearing on the failure case, but the
filesystem that I sent an image of was only ever created, subvol
created, and mounted/unmounted several times. There was never any data
written
Most likely user would replace or delete the device when
there is a problem with the device.
We want to test this condition by using the dm error target which
will help to create the EIO when needed.
Basically first create the linear device and then load the error
table to get the EIO when
From: Anand Jain anand.j...@oracle.com
This test case will test to confirm the replace works when
the replacing source device has EIO errors.
EIO condition is achieved using the DM device.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
v3-v4: rebase on latest xfstests code
v2-v3: accepts
From: Anand Jain anand.j...@oracle.com
This test case tests if the device delete would work when
the source device has failed with EIO errors.
EIO errors are achieved usign the DM device.
Also this test needs the latest btrfs-progs and kernel patch
under title
[PATCH] device delete by devid
From: Anand Jain anand.j...@oracle.com
This test case will test to confirm the replace works when
the replacing source device has EIO errors.
EIO condition is achieved using the DM device.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
v3-v4: rebase on latest xfstests code
v2-v3: accepts
From: Anand Jain anand.j...@oracle.com
Controlled EIO from the device is achieved using the dm device.
Helper functions are at common/dmerror.
Broadly steps will include calling _init_dmerror().
_init_dmerror() will use SCRATCH_DEV to create dm linear device and assign
DMERROR_DEV to
From: Anand Jain anand.j...@oracle.com
This test case tests if the device delete would work when
the source device has failed with EIO errors.
EIO errors are achieved usign the DM device.
Also this test needs the latest btrfs-progs and kernel patch
under title
[PATCH] device delete by devid
From: Anand Jain anand.j...@oracle.com
Controlled EIO from the device is achieved using the dm device.
Helper functions are at common/dmerror.
Broadly steps will include calling _init_dmerror().
_init_dmerror() will use SCRATCH_DEV to create dm linear device and assign
DMERROR_DEV to
Most likely user would replace or delete the device when
there is a problem with the device.
We want to test this condition by using the dm error target which
will help to create the EIO when needed.
Basically first create the linear device and then load the error
table to get the EIO when
On 07/22/2015 01:27 AM, Dave Chinner wrote:
On Tue, Jul 21, 2015 at 08:37:39PM -0400, Josef Bacik wrote:
On 07/21/2015 08:01 PM, Dave Chinner wrote:
On Tue, Jul 21, 2015 at 04:03:17PM +0530, Chandan Rajendra wrote:
On Tuesday 21 Jul 2015 08:12:20 Dave Chinner wrote:
On Mon, Jul 20, 2015 at
On Wed, Jul 22, 2015 at 05:28:48PM +0800, Qu Wenruo wrote:
Hi Chris,
Is there anything wrong with it?
It has been 2 weeks, and it's still not in your for linus branch.
Is there anything wrong?
Nothing wrong at all, I've got it queued here. Thanks for the resend.
-chris
--
To
On 07/22/2015 01:27 AM, Dave Chinner wrote:
On Tue, Jul 21, 2015 at 08:37:39PM -0400, Josef Bacik wrote:
On 07/21/2015 08:01 PM, Dave Chinner wrote:
On Tue, Jul 21, 2015 at 04:03:17PM +0530, Chandan Rajendra wrote:
On Tuesday 21 Jul 2015 08:12:20 Dave Chinner wrote:
On Mon, Jul 20, 2015 at
Hi, Chris Murphy
Thanks for report this bug.
-Original Message-
From: linux-btrfs-ow...@vger.kernel.org
[mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Chris Murphy
Sent: Thursday, July 09, 2015 11:16 AM
To: Btrfs BTRFS
Subject: [BUG] kernel BUG at fs/btrfs/scrub.c:1956!,
From: Zhao Lei zhao...@cn.fujitsu.com
Scrub panic in following operation:
mkfs.ext4 /dev/vdh
btrfs-convert /dev/vdh
mount /dev/vdh /mnt/tmp1
btrfs scrub start -B /dev/vdh
(panic)
Reason:
1: In some case, leaf created by btrfs-convert was splited into 2
strips.
2: Scrub
On Wed, Jul 22, 2015 at 07:28:55AM -0400, Josef Bacik wrote:
On 07/22/2015 01:27 AM, Dave Chinner wrote:
Josef, Chris, is this really how btrfs handles metadata write
failures? This handling of errors seems like a design flaw rather
than a desireable behaviour to me
Jeeze you are
Hello,
I am using as kernel Linux 4.1.3 (64bit) and btrfs-prog version 4.0 (32 bit
user space).
I wanted to use send/receive with btrfs for the first time today and I got the
following error:
humbur:~# btrfs send /snap /dev/null
At subvol /snap
ERROR: send ioctl failed with -25:
On Wed, Jul 22, 2015 at 08:47:54AM -0400, Josef Bacik wrote:
On 07/22/2015 01:27 AM, Dave Chinner wrote:
On Tue, Jul 21, 2015 at 08:37:39PM -0400, Josef Bacik wrote:
This test is to verify that said shit is on disk after an fsync.
The drop all writes from this point onwards does this silently.
On Wed, Jul 22, 2015 at 12:16 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2015-07-21 22:01, Qu Wenruo wrote:
Steve Dainard wrote on 2015/07/21 14:07 -0700:
I don't know if this has any bearing on the failure case, but the
filesystem that I sent an image of was only ever created,
27 matches
Mail list logo
