On 31.05.19 г. 20:01 ч., David Sterba wrote:
> Lockdep annotations are better than comments about necessary locks.
>
> David Sterba (5):
> btrfs: tests: add locks around add_extent_mapping
> btrfs: assert extent map tree lock in add_extent_mapping
> btrfs: assert tree mod log lock in __tr
I'd merge this patch into the next one, so you only introduce
btrfs_io_geometry when there are actual users for it.
But that's personal preference I guess.
Byte,
Johannes
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de
And maybe this patch should be merged into the next one as well, so one can
see the actual code movement between __btrfs_map_block() and
btrfs_io_geometry()
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
S
On Mon, Jun 03, 2019 at 01:05:59PM +0300, Nikolay Borisov wrote:
> The function has a lot of return values and specific conventions making
> it cumbersome to understand what's returned. Have a go at documenting
> its parameters and return values.
>
> Signed-off-by: Nikolay Borisov
> ---
> fs/btr
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnb
On 2019/6/3 下午6:05, Nikolay Borisov wrote:
> The function has a lot of return values and specific conventions making
> it cumbersome to understand what's returned. Have a go at documenting
> its parameters and return values.
>
> Signed-off-by: Nikolay Borisov
The idea is pretty good, will help
On 2019/6/3 下午6:06, Nikolay Borisov wrote:
> This patch removes support for range parameters of FITRIM ioctl when
> trimming unallocated space on devices. This is necessary since ranges
> passed from user space are generally interpreted as logical addresses,
> whereas btrfs_trim_free_extents use
On 2019/6/3 下午6:06, Nikolay Borisov wrote:
> Currently the first megabyte on a device housing a btrfs filesystem is
> exempt from allocation and trimming. Currently this is not a problem
> since 'start' is set to 1m at the beginning of btrfs_trim_free_extents
> and find_first_clear_extent_bit al
On 2019/6/3 下午6:06, Nikolay Borisov wrote:
> Currently find_first_clear_extent_bit always returns a range whose
> starting value is >= passed 'start'. This implicit trimming behavior is
> somewhat subtle and an implementation detail. Instead, this patch
> modifies the function such that now it a
On 3.06.19 г. 9:40 ч., Qu Wenruo wrote:
> If a filesystem doesn't map its logical address space (normally the
> bytenr/blocknr returned by fiemap) directly to its devices(s), the
> following assumptions used in the test case is no longer true:
> - trim range start beyond the end of fs should fai
On 5.06.19 г. 12:14 ч., Qu Wenruo wrote:
>
>
> On 2019/6/3 下午6:06, Nikolay Borisov wrote:
>> Currently the first megabyte on a device housing a btrfs filesystem is
>> exempt from allocation and trimming. Currently this is not a problem
>> since 'start' is set to 1m at the beginning of btrfs_tr
The function has a lot of return values and specific conventions making
it cumbersome to understand what's returned. Have a go at documenting
its parameters and return values.
Signed-off-by: Nikolay Borisov
---
* Document 'tree' argument to silence error (Johaness)
* Document that if a range is
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnb
On 2019/6/5 下午7:16, Nikolay Borisov wrote:
>
>
> On 3.06.19 г. 9:40 ч., Qu Wenruo wrote:
>> If a filesystem doesn't map its logical address space (normally the
>> bytenr/blocknr returned by fiemap) directly to its devices(s), the
>> following assumptions used in the test case is no longer true:
On 5.06.19 г. 14:53 ч., Qu Wenruo wrote:
>
>
> On 2019/6/5 下午7:16, Nikolay Borisov wrote:
>>
>>
>> On 3.06.19 г. 9:40 ч., Qu Wenruo wrote:
>>> If a filesystem doesn't map its logical address space (normally the
>>> bytenr/blocknr returned by fiemap) directly to its devices(s), the
>>> followin
On Tue, Jun 04, 2019 at 03:43:26PM -0700, Andrew Morton wrote:
> On Mon, 3 Jun 2019 14:32:03 +0530 Maninder Singh
> wrote:
>
> > currently params structure is passed in all functions, which increases
> > stack usage in all the function and lead to stack overflow on target like
> > ARM with kern
On 2019/6/5 下午7:54, Nikolay Borisov wrote:
>
>
> On 5.06.19 г. 14:53 ч., Qu Wenruo wrote:
>>
>>
>> On 2019/6/5 下午7:16, Nikolay Borisov wrote:
>>>
>>>
>>> On 3.06.19 г. 9:40 ч., Qu Wenruo wrote:
If a filesystem doesn't map its logical address space (normally the
bytenr/blocknr returned
On Wed, Jun 05, 2019 at 01:57:03PM +0200, David Sterba wrote:
> On Tue, Jun 04, 2019 at 03:43:26PM -0700, Andrew Morton wrote:
> > On Mon, 3 Jun 2019 14:32:03 +0530 Maninder Singh
> > wrote:
> >
> > > currently params structure is passed in all functions, which increases
> > > stack usage in al
On Wed, Jun 05, 2019 at 09:35:33AM +0200, Johannes Thumshirn wrote:
> I'd merge this patch into the next one, so you only introduce
> btrfs_io_geometry when there are actual users for it.
>
> But that's personal preference I guess.
Yeah 1+2 is a good idea, I'll to that.
On Mon, Jun 03, 2019 at 09:27:54AM +0800, damenly...@gmail.com wrote:
> From: Su Yue
>
> As the link reported, btrfs fi sh may crash while a device is removing.
>
> valgrind reported:
> ==
> ...
> ==883== Invalid write of size 8
On Wed, May 29, 2019 at 03:27:23PM +0800, Qu Wenruo wrote:
> BTRFS_COMPAT_EXTENT_TREE_V0 is introduced for a short time in kernel,
> and it's over 10 years ago.
>
> Nowadays there should be no user for that feature, and kernel has remove
> this support in Jun, 2018. There is no need for btrfs-prog
On Fri, May 17, 2019 at 10:00:03PM +0800, Qu Wenruo wrote:
> In lowmem mode, we check fs roots and free space cache by iterating
> each root item and inode item, using btrfs_next_item() and a path
> pointing to the root tree.
>
> However in repair mode, check_fs_root() can modify the fs root, thus
On Thu, May 16, 2019 at 04:12:50PM +0300, Nikolay Borisov wrote:
> This ensures that 'btrfs filesystem show' can correctly identify a
> filesystem on a newly created local file.
>
> Signed-off-by: Nikolay Borisov
> ---
> tests/cli-tests/010-fi-show-on-new-file/test.sh | 16
Test
On Thu, May 16, 2019 at 04:12:49PM +0300, Nikolay Borisov wrote:
> When btrfs' 'filesystem' subcommand is passed path to an image file it
> currently fails since the code expects the image file is going to be
> recognised by libblkid (called from btrfs_scan_devices()). This is not
> the case since
On Tue, Apr 16, 2019 at 06:21:43PM +0800, Qu Wenruo wrote:
> There is a hidden call loop which can trigger itself:
>
> btrfs_reserve_extent() <--|
> |- do_chunk_alloc() |
>|- btrfs_alloc_chunk() |
> |- btrfs_insert_item() |
>|- b
On Tue, Apr 16, 2019 at 06:21:42PM +0800, Qu Wenruo wrote:
> This patchset will address the github issue #123 to make btrfs-convert
> less possible to report false ENOSPC.
>
> The first patch will try to avoid the nested chunk/extent tree
> modification in a more explicit way.
>
> The 2nd patch w
On Wed, 5 Jun 2019 14:32:53 +0200 David Sterba wrote:
> > >
> > > -static ZSTD_parameters zstd_get_btrfs_parameters(unsigned int level,
> > > +static ZSTD_parameters *zstd_get_btrfs_parameters(unsigned int level,
> > >size_t src_len)
> > > {
> > > -
On 2019/6/6 上午12:32, David Sterba wrote:
> On Tue, Apr 16, 2019 at 06:21:43PM +0800, Qu Wenruo wrote:
>> There is a hidden call loop which can trigger itself:
>>
>> btrfs_reserve_extent() <--|
>> |- do_chunk_alloc() |
>>|- btrfs_alloc_chunk() |
>>
On 2019/6/6 上午12:08, David Sterba wrote:
> On Fri, May 17, 2019 at 10:00:03PM +0800, Qu Wenruo wrote:
>> In lowmem mode, we check fs roots and free space cache by iterating
>> each root item and inode item, using btrfs_next_item() and a path
>> pointing to the root tree.
>>
>> However in repair m
29 matches
Mail list logo
