At 02/17/2017 09:04 AM, Qu Wenruo wrote:
Hi David,
Any update about this patchset?
As I see a lot of cleanups related to qgroup is submitted to mail list,
should I rebase this patchset to handle the conflicts using your latest
for-next?
Or should I rebase them only after cleanups got merged
From: Omar Sandoval
This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()".
It fails for zlib on v4.10-rc[1-7].
Signed-off-by: Omar Sandoval
---
This runs in <60 seconds on my test VM, which I think qualifies for the
quick group?
common/btrfs
From: Omar Sandoval
Signed-off-by: Omar Sandoval
---
common/rc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/rc b/common/rc
index 76515e2b..6304d690 100644
--- a/common/rc
+++ b/common/rc
@@ -2417,7 +2417,7 @@ _die()
# convert
Hi David,
Any update about this patchset?
As I see a lot of cleanups related to qgroup is submitted to mail list,
should I rebase this patchset to handle the conflicts using your latest
for-next?
Or should I rebase them only after cleanups got merged into mainline?
Thanks,
Qu
At
On Thu, Feb 16, 2017 at 09:05:02AM +0800, Qu Wenruo wrote:
>
>
> At 02/16/2017 04:50 AM, Lakshmipathi.G wrote:
> >Signed-off-by: Lakshmipathi.G
>
> Looks good to me.
>
> Reviewed by: Qu Wenruo
>
> BTW, it would be better to have some
At 02/16/2017 06:03 PM, Filipe Manana wrote:
On Thu, Feb 16, 2017 at 12:39 AM, Qu Wenruo wrote:
At 02/15/2017 11:59 PM, Filipe Manana wrote:
On Wed, Feb 15, 2017 at 8:49 AM, Qu Wenruo
wrote:
If run btrfs/125 with nospace_cache or
Test script to recover damaged primary superblock using backup superblock.
Signed-off-by: Lakshmipathi.G
---
.../019-fix-superblock-corruption/test.sh | 36 ++
1 file changed, 36 insertions(+)
create mode 100755
Test script to create file with specific data-stripe layout and pre-computed
parity values.
Inject corruption into data-stripe and verify scrubbing process fixes corrupted
block.
It also attempts to validate the corresponding parity block value.
Signed-off-by: Lakshmipathi.G
Thanks Qu,
Just before I’ll go and accidentally mess up this FS more - I’ve
mentioned originally that this problem started with FS not being able
to create a snapshot ( it would get remounted RO automatically ) for
about a month, and when I’ve realised that there is a problem like
that I’ve
On Fri, Feb 17, 2017 at 01:58:49PM +0800, Eryu Guan wrote:
> On Thu, Feb 16, 2017 at 06:32:49PM -0800, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()".
> > It fails for zlib on v4.10-rc[1-7].
> >
> >
On Thu, Feb 16, 2017 at 06:32:49PM -0800, Omar Sandoval wrote:
> From: Omar Sandoval
>
> This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()".
> It fails for zlib on v4.10-rc[1-7].
>
> Signed-off-by: Omar Sandoval
> ---
> This runs in <60
On Thu, Feb 16, 2017 at 01:37:53PM +0200, Imran Geriskovan wrote:
> What are your experiences for btrfs regarding 4.10 and 4.11 kernels?
> I'm still on 4.8.x. I'd be happy to hear from anyone using 4.1x for
> a very typical single disk setup. Are they reasonably stable/good
> enough for this case?
Just a minor nit.
On 15.02.2017 04:43, Qu Wenruo wrote:
> Just as Filipe pointed out, the most time consuming parts of qgroup are
> btrfs_qgroup_account_extents() and
> btrfs_qgroup_prepare_account_extents().
> Which both call btrfs_find_all_roots() to get old_roots and new_roots
> ulist.
>
>
On Wed, Feb 15, 2017 at 2:43 AM, Qu Wenruo wrote:
> Just as Filipe pointed out, the most time consuming parts of qgroup are
> btrfs_qgroup_account_extents() and
> btrfs_qgroup_prepare_account_extents().
> Which both call btrfs_find_all_roots() to get old_roots and
At 02/16/2017 04:45 PM, Nikolay Borisov wrote:
Just a minor nit.
On 15.02.2017 04:43, Qu Wenruo wrote:
Just as Filipe pointed out, the most time consuming parts of qgroup are
btrfs_qgroup_account_extents() and
btrfs_qgroup_prepare_account_extents().
Which both call btrfs_find_all_roots() to
At 02/16/2017 04:56 PM, Nikolay Borisov wrote:
On 16.02.2017 10:50, Qu Wenruo wrote:
At 02/16/2017 04:45 PM, Nikolay Borisov wrote:
Just a minor nit.
On 15.02.2017 04:43, Qu Wenruo wrote:
Just as Filipe pointed out, the most time consuming parts of qgroup are
Opps.. I mean 4.9/4.10 Experiences
On 2/16/17, Imran Geriskovan wrote:
> What are your experiences for btrfs regarding 4.10 and 4.11 kernels?
> I'm still on 4.8.x. I'd be happy to hear from anyone using 4.1x for
> a very typical single disk setup. Are they reasonably
On Thu, Feb 16, 2017 at 12:39 AM, Qu Wenruo wrote:
>
>
> At 02/15/2017 11:59 PM, Filipe Manana wrote:
>>
>> On Wed, Feb 15, 2017 at 8:49 AM, Qu Wenruo
>> wrote:
>>>
>>> If run btrfs/125 with nospace_cache or space_cache=v2 mount option,
>>> 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
From: Filipe Manana
Hi Chris.
Please consider the following changes for the 4.11 merge window.
This time there is nothing particularly outstanding when compared to the
usual set of bug fixes. These are mostly fixes for send and the no-holes
feature introduced in 3.14. Test
What are your experiences for btrfs regarding 4.10 and 4.11 kernels?
I'm still on 4.8.x. I'd be happy to hear from anyone using 4.1x for
a very typical single disk setup. Are they reasonably stable/good
enough for this case?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
On 16.02.2017 10:50, Qu Wenruo wrote:
>
>
> At 02/16/2017 04:45 PM, Nikolay Borisov wrote:
>> Just a minor nit.
>>
>> On 15.02.2017 04:43, Qu Wenruo wrote:
>>> Just as Filipe pointed out, the most time consuming parts of qgroup are
>>> btrfs_qgroup_account_extents() and
>>>
On Thu, Feb 16, 2017 at 09:12:31AM +0800, Qu Wenruo wrote:
>
>
> At 02/16/2017 04:56 AM, Lakshmipathi.G wrote:
> >On Wed, Feb 15, 2017 at 05:29:33PM +0800, Qu Wenruo wrote:
> >>
> >>
> >>At 02/15/2017 05:03 PM, Lakshmipathi.G wrote:
> >>>Signed-off-by: Lakshmipathi.G
On Wed, Feb 15, 2017 at 07:24:55PM +0100, Goffredo Baroncelli wrote:
> The chunk-tree maps the logical address [145096704...145096704+134217728)
> [size=128MB] to the physical ones
> devid3 : [6368..6368+67108864) [size=64MB]
> devid1 : [6368..6368+67108864)
On 2017-02-16 14:00, Ilan Schwarts wrote:
> Hi,
> Found the solution at: https://patchwork.kernel.org/patch/2825842/
The patches below provided by suse seem more general
http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/vfs-add-super_operations-get_inode_dev
Hi,
This man page contains a list for pretty much every other file system,
with a oneliner description: ext4, XFS is in there, and even NTFS, but
not Btrfs.
Also, /etc/filesystems doesn't contain Btrfs. Anyone know if either,
or both, ought to contain an entry for Btrfs?
--
Chris Murphy
--
To
On 2017-02-16 15:13, E V wrote:
It would be nice if there was an easy way to tell btrfs to allocate
another metadata chunk. For example, the below fs is full due to
exhausted metadata:
Device size:1013.28GiB
Device allocated: 1013.28GiB
Device unallocated:
On 2017-02-16 15:36, Chris Murphy wrote:
Hi,
This man page contains a list for pretty much every other file system,
with a oneliner description: ext4, XFS is in there, and even NTFS, but
not Btrfs.
Also, /etc/filesystems doesn't contain Btrfs. Anyone know if either,
or both, ought to contain
It would be nice if there was an easy way to tell btrfs to allocate
another metadata chunk. For example, the below fs is full due to
exhausted metadata:
Device size:1013.28GiB
Device allocated: 1013.28GiB
Device unallocated:2.00MiB
Device
On Wed, Feb 15, 2017 at 04:28:26PM -0500, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Hi all -
>
> Here's another around of cleanup patches. The first 7 cleanup API
> blemishes with unused arguments and/or root -> fs_info conversion. The
> last converts the pr_debug in
On 2/16/17 1:23 PM, Goffredo Baroncelli wrote:
> On 2017-02-16 14:00, Ilan Schwarts wrote:
>> Hi,
>> Found the solution at: https://patchwork.kernel.org/patch/2825842/
>
> The patches below provided by suse seem more general
>
>
>
From: Omar Sandoval
This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()".
It fails for zlib on v4.10-rc[1-7].
Signed-off-by: Omar Sandoval
---
Changed from v1:
- Remove from quick group
- Handle compress features in sysfs generically
- Require
From: Omar Sandoval
Signed-off-by: Omar Sandoval
---
Identical to v1
common/rc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/rc b/common/rc
index 76515e2b..6304d690 100644
--- a/common/rc
+++ b/common/rc
@@ -2417,7 +2417,7 @@ _die()
33 matches
Mail list logo