Hi,
Is there some way to cancel a device remove operation? I have discovered that
if I reboot that will cancel it, but that's not always possible. What I'm after
is something the same as cancelling scrub.
I keep running into situations where I want to pause a remove operation for
speed reasons.
As now btrfs-convert is forced to used mixed block group, only test
pagesize as nodesize for convert.
Signed-off-by: Qu Wenruo
---
tests/convert-tests.sh | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/tests/convert-tests.sh b/tests/conv
Convert has a bug that even we disable it from using mixed block, it
will still put data and metadata extent into the same chunk.
The bug can be reported by previous fsck patch.
Even without the bug, it's still high recommeneded to use mixed block
group, as unlike btrfs, ext* is not extent based
Check nodesize against features, not only sectorsize.
In fact, one of the btrfs-convert and mkfs differs in the nodesize
check.
This patch also provides the basis for later btrfs-convert fix.
Signed-off-by: Qu Wenruo
---
btrfs-convert.c | 2 +-
mkfs.c | 16 +---
utils.c
Even we tried to make mkfs and btrfs-convert use the same features, but
previous patch forced btrfs-convert to use mix-bg feature.
So the default fs features is different for mkfs and btrfs-convert, add
mask_default parameter for btrfs_list_all_fs_features() to handle the
difference.
Signed-off-b
There is a bug in btrfs-convert in 4.1.2, even we don't allow mixed
block group for converted image, btrfs-convert will still create image
with data and metadata inside one chunk.
And further more, the chunk type is still DATA or METADATA, not
DATA|METADATA (not mixed).
So add btrfsck check for i
Again the buggy btrfs-convert, even David tried to ban mixed-bg features
for btrfs-convert, it will still put data and metadata extents into the
same chunk, without marking the chunk mixed.
So in the patchset, first add fsck support for such problem, and then
force btrfs-convert to use mixed block
Do you need a genuine Loan to settle your bills and start up a good
business? Kindly contact us now with your details to get a good
Loan at a low rate of 3% per Annu, Quick send your details via:
guarloa...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the b
David Sterba wrote on 2015/09/09 15:25 +0200:
On Wed, Sep 09, 2015 at 11:24:17AM +0800, Qu Wenruo wrote:
The problem is that, for converted image, it's quite possible that data
and metadata extent are stored in one chunk even the chunk is not mixed.
I'll add fsck support for it soon.
That w
Brendan Hide posted on Wed, 09 Sep 2015 17:48:11 +0200 as excerpted:
> Things can be a little more nuanced.
>
> First off, I'm not even sure btrfs supports a hot spare currently. I
> haven't seen anything along those lines recently in the list - and don't
> recall anything along those lines befor
On Wed, Sep 9, 2015 at 9:48 AM, Brendan Hide wrote:
> Things can be a little more nuanced.
>
> First off, I'm not even sure btrfs supports a hot spare currently. I haven't
> seen anything along those lines recently in the list - and don't recall
> anything along those lines before either. The curr
bogus 'no space left on device' with 'btrfs delete missing' raid5
https://bugzilla.kernel.org/show_bug.cgi?id=104361
Summary: 4x 8GB virtual disks in raid5 with 3.62GiB data, no snapshots
or subvolumes or reflinks; fail one of the devices; reboot; btrfs dev
delete missing fails with 'no space left
On Wed, Sep 09, 2015 at 04:41:34PM -0400, Anna Schumaker wrote:
> On 09/09/2015 04:38 PM, Chris Mason wrote:
> > On Wed, Sep 09, 2015 at 04:26:58PM -0400, Trond Myklebust wrote:
> >> On Wed, Sep 9, 2015 at 4:09 PM, Chris Mason wrote:
> >>> On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski
Thank you all for the quick response! For anyone running into similar issues:
I updated my kernel, and then ran btrfs-zero-log. Everything worked
fine, and the drive is mountable with no issues so far.
-Jon
On Wed, Sep 9, 2015 at 12:27 PM, Roman Mamedov wrote:
> On Wed, 9 Sep 2015 17:19:51 +00
On Wed, Sep 09, 2015 at 02:52:08PM -0400, Anna Schumaker wrote:
> On 09/08/2015 06:39 PM, Darrick J. Wong wrote:
> > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 8, 2015 at 2:29 PM, Darrick J. Wong
> >> wrote:
> >>> On Tue, Sep 08, 2015 at 09:03:09PM +0100, Pá
On Wed, Sep 09, 2015 at 01:37:44PM -0700, Andy Lutomirski wrote:
> On Wed, Sep 9, 2015 at 1:09 PM, Chris Mason wrote:
> > On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong
> >> wrote:
> >> > On Tue, Sep 08, 2015 at 02:45:39PM -0
On 09/09/2015 04:38 PM, Chris Mason wrote:
> On Wed, Sep 09, 2015 at 04:26:58PM -0400, Trond Myklebust wrote:
>> On Wed, Sep 9, 2015 at 4:09 PM, Chris Mason wrote:
>>> On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote:
On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong
wrote
On Wed, Sep 09, 2015 at 04:26:58PM -0400, Trond Myklebust wrote:
> On Wed, Sep 9, 2015 at 4:09 PM, Chris Mason wrote:
> > On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong
> >> wrote:
> >> > On Tue, Sep 08, 2015 at 02:45:39PM -0
On Wed, Sep 9, 2015 at 1:09 PM, Chris Mason wrote:
> On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong
>> wrote:
>> > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:
>> >> What I meant by this was: if you ask for
On Wed, Sep 9, 2015 at 4:09 PM, Chris Mason wrote:
> On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong
>> wrote:
>> > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:
>> >> What I meant by this was: if you ask for
On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong
> wrote:
> > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:
> >> What I meant by this was: if you ask for "regular copy", you may end
> >> up with a reflink anyway.
On 09/09/2015 02:12 PM, Darrick J. Wong wrote:
> On Wed, Sep 09, 2015 at 01:31:24PM -0400, Anna Schumaker wrote:
>> On 09/09/2015 01:17 PM, Darrick J. Wong wrote:
>>> On Wed, Sep 09, 2015 at 07:38:14AM -0400, Austin S Hemmelgarn wrote:
On 2015-09-08 16:39, Darrick J. Wong wrote:
> On Tue,
On 09/08/2015 06:39 PM, Darrick J. Wong wrote:
> On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 8, 2015 at 2:29 PM, Darrick J. Wong
>> wrote:
>>> On Tue, Sep 08, 2015 at 09:03:09PM +0100, Pádraig Brady wrote:
On 08/09/15 20:10, Andy Lutomirski wrote:
> On
On Wed, Sep 09, 2015 at 01:31:24PM -0400, Anna Schumaker wrote:
> On 09/09/2015 01:17 PM, Darrick J. Wong wrote:
> > On Wed, Sep 09, 2015 at 07:38:14AM -0400, Austin S Hemmelgarn wrote:
> >> On 2015-09-08 16:39, Darrick J. Wong wrote:
> >>> On Tue, Sep 08, 2015 at 11:04:03AM -0400, Anna Schumaker w
On 09/09/2015 01:17 PM, Darrick J. Wong wrote:
> On Wed, Sep 09, 2015 at 07:38:14AM -0400, Austin S Hemmelgarn wrote:
>> On 2015-09-08 16:39, Darrick J. Wong wrote:
>>> On Tue, Sep 08, 2015 at 11:04:03AM -0400, Anna Schumaker wrote:
On 09/04/2015 05:38 PM, Darrick J. Wong wrote:
> On Fri,
On Wed, 9 Sep 2015 17:19:51 +
Hugo Mills wrote:
>The bug you've hit is almost certainly fixed in more recent
> kernels. I can't recommend stongly enough that you upgrade it (or
> contact your vendor's support department to find out how they will
> support your use of btrfs on a kernel tha
uOn Wed, Sep 09, 2015 at 10:30:33AM -0500, Jon Keane wrote:
> I recently had a power failure, and ever since I have been unable to
> mount one of my btrfs drives (data is the one that is failing to
> mount, store is fine). I’m running:
>
> jkeane@bet:~$ uname -a
>
> Linux bet 3.8.0-33-generic #4
On Wed, Sep 09, 2015 at 07:38:14AM -0400, Austin S Hemmelgarn wrote:
> On 2015-09-08 16:39, Darrick J. Wong wrote:
> >On Tue, Sep 08, 2015 at 11:04:03AM -0400, Anna Schumaker wrote:
> >>On 09/04/2015 05:38 PM, Darrick J. Wong wrote:
> >>>On Fri, Sep 04, 2015 at 04:17:03PM -0400, Anna Schumaker wrot
On 08/19/2015 08:17 PM, Chris Mason wrote:
On Wed, Aug 19, 2015 at 02:17:39PM +0200, mho...@kernel.org wrote:
Hi,
these two patches were sent as a part of a larger RFC which aims at
allowing GFP_NOFS allocations to fail to help sort out memory reclaim
issues bound to the current behavior
(http:/
Things can be a little more nuanced.
First off, I'm not even sure btrfs supports a hot spare currently. I
haven't seen anything along those lines recently in the list - and don't
recall anything along those lines before either. The current mention of
it in the Project Ideas page on the wiki im
On 09/09/2015 05:18 AM, David Sterba wrote:
> On Fri, Sep 04, 2015 at 04:16:58PM -0400, Anna Schumaker wrote:
>> We need to verify that both the source and the destination files are
>> part of the same filesystem, otherwise we can't create a reflink.
>>
>> Signed-off-by: Anna Schumaker
>> ---
>>
On Tue, Sep 08, 2015 at 09:16:48PM +0800, Zhao Lei wrote:
> sequence, transid and reserved field of inode was write to disk
> with uninitizlized value, this patchset fixed it, also fixed some
> other typo.
>
> Zhao Lei (3):
> btrfs-progs: fix set_get typo of btrfs_inode_item->sequence
> btrfs-
I recently had a power failure, and ever since I have been unable to
mount one of my btrfs drives (data is the one that is failing to
mount, store is fine). I’m running:
jkeane@bet:~$ uname -a
Linux bet 3.8.0-33-generic #48-Ubuntu SMP Wed Oct 23 09:16:58 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
On 2015-09-09 09:25, David Sterba wrote:
On Wed, Sep 09, 2015 at 11:24:17AM +0800, Qu Wenruo wrote:
The problem is that, for converted image, it's quite possible that data
and metadata extent are stored in one chunk even the chunk is not mixed.
I'll add fsck support for it soon.
That would be
devices opened by check_mounted() in main() should close before
exit of btrfs-image.
Signed-off-by: Zhao Lei
---
btrfs-image.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/btrfs-image.c b/btrfs-image.c
index c7681f4..78ae828 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@ -2881,5 +288
Bug:
# btrfs-image -t0 -c9 /dev/sda6 /tmp/btrfs_image.img
(hang)
# btrfs-image -r -t0 /tmp/btrfs_image.img /dev/sda6
(hang)
Reason:
Program need to create at least 1 thread for compress/decompress.
but if user specify -t0 in argument, it overwrite the default value
of 1, then the program re
In case of creating image without compess, we don't need to create
many no-used compress threads.
Signed-off-by: Zhao Lei
---
btrfs-image.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index 7f49cce..c7681f4 100644
--- a/btrfs-im
On Wed, Sep 09, 2015 at 11:24:17AM +0800, Qu Wenruo wrote:
> The problem is that, for converted image, it's quite possible that data
> and metadata extent are stored in one chunk even the chunk is not mixed.
>
> I'll add fsck support for it soon.
That would be great, I have no idea how the data/
On Wed, Sep 09, 2015 at 11:35:50AM +0100, Vytautas D wrote:
> sorry for side question - but does this mean that btrfs-convert issues
> others were having on kernel 4.0+ on this mailing list is now
> addressed ?
Per Qu's analysis yes, the broken versions are 3.19.1-4.0.1.
--
To unsubscribe from thi
On Wed, Sep 09, 2015 at 09:34:53AM +0800, Qu Wenruo wrote:
> > David Sterba (79):
> >btrfs-progs: tests: log the test name in results file
> >btrfs-progs: tests: support more formats of test images
> >btrfs-progs: tests: use readlink -f to resolve path
> >btrfs-progs
On 09/09/2015 03:40 PM, Austin S Hemmelgarn wrote:
> On 2015-09-09 08:12, Boaz Harrosh wrote:
>> On 09/09/2015 02:28 PM, Austin S Hemmelgarn wrote:
>>> On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote:
>> <>
>>
>>> this may actually make things slower (the particular effect of SSD mod
On 2015-09-09 08:12, Boaz Harrosh wrote:
On 09/09/2015 02:28 PM, Austin S Hemmelgarn wrote:
On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote:
<>
this may actually make things slower (the particular effect of SSD mode
is that it tries to spread allocations out as much as possible
On 09/09/2015 02:28 PM, Austin S Hemmelgarn wrote:
> On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote:
<>
> this may actually make things slower (the particular effect of SSD mode
> is that it tries to spread allocations out as much as possible, as this
> helps with wear-leveling o
On Thu, Sep 03, 2015 at 12:44:27PM -0700, Omar Sandoval wrote:
> Now we can finally hook up everything so we can actually use free space
> tree. On the first mount with the free_space_tree mount option, the free
> space tree will be created and the FREE_SPACE_TREE read-only compat bit
> will be set
On 2015-09-08 16:39, Darrick J. Wong wrote:
On Tue, Sep 08, 2015 at 11:04:03AM -0400, Anna Schumaker wrote:
On 09/04/2015 05:38 PM, Darrick J. Wong wrote:
On Fri, Sep 04, 2015 at 04:17:03PM -0400, Anna Schumaker wrote:
copy_file_range() is a new system call for copying ranges of data
completel
On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote:
-Original Message-
From: Austin S Hemmelgarn [mailto:ahferro...@gmail.com]
Sent: Tuesday, September 8, 2015 7:56 AM
Subject: Re: mkfs.btrfs cannot find rotational file for SSD detection for
a pmem device
On 2015-09-06 13:5
Vytautas D posted on Wed, 09 Sep 2015 11:35:50 +0100 as excerpted:
> sorry for side question - but does this mean that btrfs-convert issues
> others were having on kernel 4.0+ on this mailing list is now addressed
> ?
AFAIK they've not yet been entirely fixed, no. There's still active
(within t
sorry for side question - but does this mean that btrfs-convert issues
others were having on kernel 4.0+ on this mailing list is now
addressed ?
On Wed, Sep 9, 2015 at 4:24 AM, Qu Wenruo wrote:
>
>
> Qu Wenruo wrote on 2015/09/09 09:34 +0800:
>>
>> Hi David,
>>
>> Sorry for the late reply, but I
On Fri, Sep 04, 2015 at 04:16:58PM -0400, Anna Schumaker wrote:
> We need to verify that both the source and the destination files are
> part of the same filesystem, otherwise we can't create a reflink.
>
> Signed-off-by: Anna Schumaker
> ---
> fs/btrfs/ioctl.c | 4
> 1 file changed, 4 inse
On Tue, Sep 08, 2015 at 01:39:18PM -0700, Darrick J. Wong wrote:
> > >> +The file descriptors must not refer to the same file.
> > >
> > > Why? btrfs (and XFS) reflink can handle the case of a file sharing blocks
> > > with itself.
> >
> > I've never really thought about it... Zach had that in h
Hi, Qu Wenruo
> -Original Message-
> From: Qu Wenruo [mailto:quwen...@cn.fujitsu.com]
> Sent: Wednesday, September 09, 2015 9:46 AM
> To: Zhao Lei ; linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH 3/3] btrfs-progs: tests: Introduce
> misc-tests/008-leaf-accross-stripes
>
>
>
> Zhao Le
On 9 September 2015 at 09:07, Ian Kumlien wrote:
> On 9 September 2015 at 03:35, Anand Jain wrote:
> > There is a patch set to handle this..
> > 'Btrfs: introduce function to handle device offline'
>
> I'll have a look
So from my very quick look at the code that i could find (can only
find
Check nodesize against features, not only sectorsize.
In fact, one of the btrfs-convert and mkfs differs in the nodesize
check.
This patch also provides the basis for later btrfs-convert fix.
Signed-off-by: Qu Wenruo
---
btrfs-convert.c | 2 +-
mkfs.c | 16 +---
utils.c
Even we tried to make mkfs and btrfs-convert use the same features, but
previous patch forced btrfs-convert to use mix-bg feature.
So the default fs features is different for mkfs and btrfs-convert, add
mask_default parameter for btrfs_list_all_fs_features() to handle the
difference.
Signed-off-b
Convert has a bug that even we disable it from using mixed block, it
will still put data and metadata extent into the same chunk.
The bug can be reported by previous fsck patch.
Even without the bug, it's still high recommeneded to use mixed block
group, as unlike btrfs, ext* is not extent based
There is a bug in btrfs-convert in 4.1.2, even we don't allow mixed
block group for converted image, btrfs-convert will still create image
with data and metadata inside one chunk.
And further more, the chunk type is still DATA or METADATA, not
DATA|METADATA (not mixed).
So add btrfsck check for i
Again the buggy btrfs-convert, even David tried to ban mixed-bg features
for btrfs-convert, it will still put data and metadata extents into the
same chunk, without marking the chunk mixed.
So in the patchset, first add fsck support for such problem, and then
force btrfs-convert to use mixed block
On Fri, Sep 04, 2015 at 04:16:57PM -0400, Anna Schumaker wrote:
> From: Zach Brown
>
> This rearranges the existing COPY_RANGE ioctl implementation so that the
> .copy_file_range file operation can call the core loop that copies file
> data extent items.
>
> The extent copying loop is lifted up
On 9 September 2015 at 03:35, Anand Jain wrote:
> On 09/09/2015 03:34 AM, Hugo Mills wrote:
>>
>> On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote:
>>>
>>> Hi,
>>>
>>> Currently i have a raid1 configuration on two disks where one of them
>>> is failing.
>>>
>>> But since:
>>> btrfs fi d
59 matches
Mail list logo