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 whe
From: Zhao Lei
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 description for users, and th
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 eit
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 mean
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 needed.
From: Anand Jain
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
---
v3->v4: rebase on latest xfstests code
v2->v3: accepts Filipe Manana's review comments, thanks
v1
From: Anand Jain
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
When this patch is not
From: Anand Jain
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 /dev/mapper/error-test.
When tes
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 needed.
From: Anand Jain
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
When this patch is not
From: Anand Jain
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
---
v3->v4: rebase on latest xfstests code
v2->v3: accepts Filipe Manana's review comments, thanks
v1
From: Anand Jain
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 /dev/mapper/error-test.
When tes
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 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
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 t
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 08
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 uns
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 08
On Wed, Jul 22, 2015 at 12:16 PM, Austin S Hemmelgarn
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, subvol
>
On Fri, Jun 26, 2015 at 7:08 AM, David Sterba 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 of the fil
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
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
> >>>
> >>
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: Inappropriat
On 07/22/2015 12:51 PM, Jens Axboe wrote:
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 drawba
Hi
Any ideas on this?
Regards,
Tobias
2015-07-20 18:20 GMT+02:00 Tobias Holst :
> Hi
>
> My btrfs-RAID6 seems to be broken again :(
>
> When reading from it I get several of these:
> [ 176.349943] BTRFS info (device dm-4): csum failed ino 1287707
> extent 21274957705216 csum 2830458701 wanted
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 th
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:195
From: Zhao Lei
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 bypassed part of above wrong l
28 matches
Mail list logo
