Hi Eric,
On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote:
> On Thu, Aug 08, 2019 at 12:26:42PM +0800, Gao Xiang wrote:
> > >
> > > > > That's why I don't like this hook - I think hiding data operations
> > > > > and/or custom bio manipulations in opaque filesystem callouts is
> > > >
[...]
>>>
>>> Fundamentally, logical address space has no relevance in the user context,
>>> so also I don’t understand your view on how anyone shall use the
>>> range::start
>>> even if there is no check?
>>
>> range::start == bg_bytenr, range::len = bg_len to trim only a bg.
>>
>
> Thanks for
On Thu, Aug 08, 2019 at 12:26:42PM +0800, Gao Xiang wrote:
> >
> > > > That's why I don't like this hook - I think hiding data operations
> > > > and/or custom bio manipulations in opaque filesystem callouts is
> > > > completely the wrong approach to be taking. We need to do these
> > > > things
On Thu, Aug 08, 2019 at 12:26:42PM +0800, Gao Xiang wrote:
> On Tue, Aug 06, 2019 at 07:54:58AM +1000, Dave Chinner wrote:
> > On Mon, Aug 05, 2019 at 04:08:43PM +, Goldwyn Rodrigues wrote:
> > > On Mon, 2019-08-05 at 09:43 +1000, Dave Chinner wrote:
> > > > On Fri, Aug 02, 2019 at 05:00:45PM -
The BTRFS_DEV_REPLACE_ITEM_STATE_x defines, as shown in [1], are
unused in both kernel and btrfs-progs (except for one instance of
BTRFS_DEV_REPLACE_ITEM_STATE_NEVER_STARTED in kernel).
[1]
btrfs.h:#define BTRFS_IOCTL_DEV_REPLACE_STATE_FINISHED2
btrfs.h:#define BTRFS_IOCTL_DEV_REPLACE_STAT
The BTRFS_DEV_REPLACE_ITEM_STATE_x series defines as shown in [1] are
unused in both kernel and btrfs-progs.
[1]
btrfs.h:#define BTRFS_IOCTL_DEV_REPLACE_STATE_FINISHED2
btrfs.h:#define BTRFS_IOCTL_DEV_REPLACE_STATE_CANCELED3
btrfs.h:#define BTRFS_IOCTL_DEV_REPLACE_STATE_SUSPENDED
On Tue, Aug 06, 2019 at 07:54:58AM +1000, Dave Chinner wrote:
> On Mon, Aug 05, 2019 at 04:08:43PM +, Goldwyn Rodrigues wrote:
> > On Mon, 2019-08-05 at 09:43 +1000, Dave Chinner wrote:
> > > On Fri, Aug 02, 2019 at 05:00:45PM -0500, Goldwyn Rodrigues wrote:
> > > > From: Goldwyn Rodrigues
> >
> On 7 Aug 2019, at 7:15 PM, Qu Wenruo wrote:
>
>
>
> On 2019/8/7 下午5:43, Anand Jain wrote:
>>
>>
>>> On 7 Aug 2019, at 4:55 PM, Qu Wenruo wrote:
>>>
>>>
>>>
>>> On 2019/8/7 下午4:44, Filipe Manana wrote:
On Wed, Aug 7, 2019 at 9:35 AM Anand Jain wrote:
>
> Commit 6ba9fc8e
On Tue, Aug 06, 2019 at 10:05:07PM +0800, Qu Wenruo wrote:
> When we try to delete qgroups, we're pretty cautious, we make sure both
> qgroups exist and there is a relationship between them, then try to
> delete the relation.
>
> This behavior is OK, but the problem is we need to two relation item
On Wed, Aug 07, 2019 at 10:17:26AM +0300, Nikolay Borisov wrote:
>
>
> On 6.08.19 г. 20:34 ч., Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > We hit a the following very strange deadlock on a system with Btrfs on a
> > loop device backed by another Btrfs filesystem:
> >
> > 1. The top (l
On Tue, Aug 06, 2019 at 12:28:22PM -0400, Josef Bacik wrote:
> This is the rebased set of the much larger group of patches I sent last month.
> The first 10 patches are already merged, these just didn't apply cleanly. I
> went through and applied each one, deleted and re-copied anything that didn'
On Wed, Aug 7, 2019 at 3:33 AM Jon Ander MB wrote:
>
> Hi! Thanks for the reply!
> First: I am (g)root,, yes :)
> Second: The snapshot was taken in ro mode, the fs is not ro and the
> rest of the snapshots and volumes work as intended (rw)
>
> Thanks
>
> On Wed, Aug 7, 2019 at 11:04 AM Hugo Mills
On Tue, Aug 06, 2019 at 12:28:37PM -0400, Josef Bacik wrote:
> Commit "btrfs: convert snapshot/nocow exlcusion to drw lock" removed
> this code, but didn't remove the comment or the definitions, do that
> now.
The DRW lock patchset is in for-next just as a preview and for early
testing so any fixu
On Wed, Aug 07, 2019 at 04:21:19PM +0800, Anand Jain wrote:
> btrfs_dev_stat_reset() is an overdo in terms of wrapping. So this patch
> open codes btrfs_dev_stat_reset().
> Signed-off-by: Anand Jain
Reviewed-by: David Sterba
for both patches.
On Wed, Aug 07, 2019 at 11:21:46AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
...
> Fixes: 75cb379d263521 ("btrfs: defer adding raid type kobject until after
> chunk relocation")
> Fixes: 7c7e301406d0a9 ("btrfs: sysfs: Replace default_attrs in ktypes with
> groups")
> Signed-off-by
On Tue, Jul 30, 2019 at 07:19:04PM +0200, David Sterba wrote:
> On Thu, Jul 25, 2019 at 11:33:51AM +0200, Johannes Thumshirn wrote:
> > From: David Sterba
> >
> > Export supported checksum algorithms via sysfs.
>
> I wonder if we should also export the implementation that would be used.
> This c
For TREE_BLOCK_REF, SHARED_DATA_REF and SHARED_BLOCK_REF we need to
check:
| TREE_BLOCK_REF | SHARED_BLOCK_REF | SHARED_BLOCK_REF
--++-+--
key->objectid |Alignment | Alignment|Alignment
key->offset |An
EXTENT_DATA_REF is a little like DIR_ITEM which contains hash in its
key->offset.
This patch will check the following contents:
- Key->objectid
Basic alignment check.
- Hash
Hash of each extent_data_ref item must match key->offset.
- Offset
Basic alignment check.
Signed-off-by: Qu Wenruo
This patch introduces the ability to check extent items.
This check involves:
- key->objectid check
Basic alignment check.
- key->type check
Against btrfs_extent_item::type and SKINNY_METADATA feature.
- key->offset alignment check for EXTENT_ITEM
- key->offset check for METADATA_ITEM
- it
Finally, we are going to add tree-checker support for extent items,
which includes:
- EXTENT_ITEM/METADATA_ITEM
Which futher contains inline backrefs of:
* TREE_BLOCK_REF
* SHARED_BLOCK_REF
* EXETNT_DATA_REF
* SHARED_DATA_REF
- TREE_BLOCK_REF
- SHARED_BLOCK_REF
- EXTENT_DATA_REF
- SHARED
On Wed, Aug 07, 2019 at 12:51:26PM +0200, Greg KH wrote:
> On Wed, Aug 07, 2019 at 11:47:59AM +0200, David Sterba wrote:
> > On Tue, Aug 06, 2019 at 05:35:00PM -0400, Sasha Levin wrote:
> > > From: Filipe Manana
> > >
> > > [ Upstream commit a6d155d2e363f26290ffd50591169cb96c2a609e ]
> > >
> > >
On Wed, Aug 07, 2019 at 04:29:45PM +0800, Anand Jain wrote:
> On 7/8/19 12:46 AM, David Sterba wrote:
> > On Tue, Aug 06, 2019 at 11:17:09PM +0800, Anand Jain wrote:
> >> On 7/31/19 1:10 AM, David Sterba wrote:
> >>> Export the potential debugging data in the per-filesystem directories we
> >>> alr
On Wed, Aug 07, 2019 at 08:03:41PM +0800, Qu Wenruo wrote:
> Gentle ping?
>
> Thanks to the discussion with Anand, I find this patch is not merged yet.
I had the patch marked as dropped as it was during the trim range
changes. Reading the discussion again it's ok to merge and I'll add it
to the q
Gentle ping?
Thanks to the discussion with Anand, I find this patch is not merged yet.
Thanks,
Qu
On 2019/5/28 下午4:21, Qu Wenruo wrote:
> Normally the range->len is set to default value (U64_MAX), but when it's
> not default value, we should check if the range overflows.
>
> And if overflows, r
On 2019/8/7 下午5:43, Anand Jain wrote:
>
>
>> On 7 Aug 2019, at 4:55 PM, Qu Wenruo wrote:
>>
>>
>>
>> On 2019/8/7 下午4:44, Filipe Manana wrote:
>>> On Wed, Aug 7, 2019 at 9:35 AM Anand Jain wrote:
Commit 6ba9fc8e628b (btrfs: Ensure btrfs_trim_fs can trim the whole
filesystem) mak
On Wed, Aug 07, 2019 at 11:47:59AM +0200, David Sterba wrote:
> On Tue, Aug 06, 2019 at 05:35:00PM -0400, Sasha Levin wrote:
> > From: Filipe Manana
> >
> > [ Upstream commit a6d155d2e363f26290ffd50591169cb96c2a609e ]
> >
> > Fixes: 03628cdbc64db6 ("Btrfs: do not start a transaction during fiema
From: Filipe Manana
In the 5.3 merge window, commit 7c7e301406d0a9 ("btrfs: sysfs: Replace
default_attrs in ktypes with groups"), we started using the member
"defaults_groups" for the kobject type "btrfs_raid_ktype". That leads
to a series of warnings when running some test cases of fstests, such
On Tue, Aug 06, 2019 at 05:35:00PM -0400, Sasha Levin wrote:
> From: Filipe Manana
>
> [ Upstream commit a6d155d2e363f26290ffd50591169cb96c2a609e ]
>
> Fixes: 03628cdbc64db6 ("Btrfs: do not start a transaction during fiemap")
The commit is a regression fix during the 5.2 cycle, how it could end
> On 7 Aug 2019, at 4:55 PM, Qu Wenruo wrote:
>
>
>
> On 2019/8/7 下午4:44, Filipe Manana wrote:
>> On Wed, Aug 7, 2019 at 9:35 AM Anand Jain wrote:
>>>
>>> Commit 6ba9fc8e628b (btrfs: Ensure btrfs_trim_fs can trim the whole
>>> filesystem) makes sure we always trim starting from the first b
Hi! Thanks for the reply!
First: I am (g)root,, yes :)
Second: The snapshot was taken in ro mode, the fs is not ro and the
rest of the snapshots and volumes work as intended (rw)
Thanks
On Wed, Aug 7, 2019 at 11:04 AM Hugo Mills wrote:
>
> On Wed, Aug 07, 2019 at 10:37:43AM +0200, Jon Ander MB w
On Wed, Aug 07, 2019 at 10:37:43AM +0200, Jon Ander MB wrote:
> Hi!
> I have a snapshot with the read only flag set and I'm currently unable
> to delete it or change the ro setting
> btrfs property set -ts /path/t/snapshot ro false
> ERROR: failed to set flags for /path/t/snapshot: Operation not pe
On 2019/8/7 下午4:44, Filipe Manana wrote:
> On Wed, Aug 7, 2019 at 9:35 AM Anand Jain wrote:
>>
>> Commit 6ba9fc8e628b (btrfs: Ensure btrfs_trim_fs can trim the whole
>> filesystem) makes sure we always trim starting from the first block group.
>> However it also removed the range.start validity
On Wed, Aug 7, 2019 at 9:35 AM Anand Jain wrote:
>
> Commit 6ba9fc8e628b (btrfs: Ensure btrfs_trim_fs can trim the whole
> filesystem) makes sure we always trim starting from the first block group.
> However it also removed the range.start validity check which is set in the
> context of the user,
Hi!
I have a snapshot with the read only flag set and I'm currently unable
to delete it or change the ro setting
btrfs property set -ts /path/t/snapshot ro false
ERROR: failed to set flags for /path/t/snapshot: Operation not permitted
Deleting the snapshot is also a no-go:
btrfs subvolume delete
On 7/8/19 12:46 AM, David Sterba wrote:
On Tue, Aug 06, 2019 at 11:17:09PM +0800, Anand Jain wrote:
On 7/31/19 1:10 AM, David Sterba wrote:
Export the potential debugging data in the per-filesystem directories we
already have, so we can drop debugfs. The new directories depend on
CONFIG_BTRFS_D
On Wed, Aug 7, 2019 at 9:16 AM Nikolay Borisov wrote:
>
>
>
> On 6.08.19 г. 13:09 ч., Filipe Manana wrote:
> > On Mon, Aug 5, 2019 at 3:48 PM Nikolay Borisov wrote:
>
>
>
> >> @@ -1371,23 +1376,39 @@ static noinline int run_delalloc_nocow(struct
> >> inode *inode,
> >>
> >> btrf
__btrfs_reset_dev_stats() is a small helper function to reset devices stat
values, and is used only once, instead just open code it.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/vo
btrfs_dev_stat_reset() is an overdo in terms of wrapping. So this patch
open codes btrfs_dev_stat_reset().
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 6 +++---
fs/btrfs/volumes.h | 6 --
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volu
Commit 6ba9fc8e628b (btrfs: Ensure btrfs_trim_fs can trim the whole
filesystem) makes sure we always trim starting from the first block group.
However it also removed the range.start validity check which is set in the
context of the user, where its range is from 0 to maximum of filesystem
totalbyte
On 6.08.19 г. 13:34 ч., Filipe Manana wrote:
> On Mon, Aug 5, 2019 at 3:47 PM Nikolay Borisov wrote:
>>
>> Correctly handle failure cases when adding an ordered extents in case
>> of REGULAR or PREALLOC extents.
>>
>> Signed-off-by: Nikolay Borisov
>
> Reviewed-by: Filipe Manana
>
> It's co
On 6.08.19 г. 13:09 ч., Filipe Manana wrote:
> On Mon, Aug 5, 2019 at 3:48 PM Nikolay Borisov wrote:
>> @@ -1371,23 +1376,39 @@ static noinline int run_delalloc_nocow(struct inode
>> *inode,
>>
>> btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]);
>>
>> +
On 6.08.19 г. 20:34 ч., Omar Sandoval wrote:
> From: Omar Sandoval
>
> We hit a the following very strange deadlock on a system with Btrfs on a
> loop device backed by another Btrfs filesystem:
>
> 1. The top (loop device) filesystem queues an async_cow work item from
>cow_file_range_asyn
42 matches
Mail list logo
