[PATCH] btrfs: Remove root argument from cow_file_range_inline

This argument is always set to the root of the inode, which is also passed. So let's get a reference inside the function and simplify the arg list. Signed-off-by: Nikolay Borisov --- fs/btrfs/inode.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff

Re: [PATCH 0/4] Fix long standing -EOPNOTSUPP problem caused by

On 2018年03月01日 22:53, David Sterba wrote: > On Thu, Mar 01, 2018 at 10:47:43AM +0800, Qu Wenruo wrote: >> Kernel doesn't support dropping range inside inline extent, and prevents >> such thing happening by limiting max inline extent size to >> min(max_inline, sectorsize - 1) in

[PATCH 3/5] btrfs: Embed sector size check into BTRFS_MAX_INLINE_DATA_SIZE()

We have extra sector size check in cow_file_range_inline(), but doesn't implement it in BTRFS_MAX_INLINE_DATA_SIZE(). The biggest reason is that btrfs_symlink() also uses this macro to check name length. In fact such behavior makes max_inline calculation quite confusing, and cause unexpected

[PATCH 5/5] btrfs: Show more accurate max_inline

Btrfs shows max_inline option into kernel message, but for max_inline=4096, btrfs won't really inline 4096 bytes inline data if it's not compressed. Since we have unified the behavior and now BTRFS_MAX_INLINE_DATA_SIZE() should handle most of the condition check, just limit fs_info->max_inline to

[PATCH 1/5] btrfs: Parse options after node/sector size initialized

This provides the basis for later max_inline enhancement, which needs to access fs_info->nodesize. Signed-off-by: Qu Wenruo --- fs/btrfs/disk-io.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index

[PATCH 2/5] btrfs: Always limit inline extent size by uncompressed size

Normally when specifying max_inline, we should normally limit it by uncompressed extent size, as it's the only thing user can control. (Control the algorithm and compressed data is almost impossible) Since btrfs is providing *TRANSPARENT* compression, max_inline should behave the same for both

[PATCH 4/5] btrfs: Unify inline extent creation condition for plain and compressed data

cow_file_range_inline() used different condition for plain and compressed data. For compressed data, it's allowed to have inline extent equal to sectorsize, while for plain data, it's not allowed to have inline extent equal to sectorsize. However we limited BTRFS_MAX_INLINE_DATA_SIZE() to

[PATCH 0/5] max_inline related enhancement

This patchset intends to reduce confusion about "max_inline" mount option. The max_inline mount option has the following problems: 1) Different behavior for plain and compressed data extent For plain data extent, it's limiting the extent data size, and will never reach sector size. For

Re: Ongoing Btrfs stability issues

On 2018年03月02日 03:04, Alex Adriaanse wrote: > On Feb 16, 2018, at 1:44 PM, Austin S. Hemmelgarn > wrote: >> I would suggest changing this to eliminate the balance with '-dusage=10' >> (it's redundant with the '-dusage=20' one unless your filesystem is in >>

Re: [PATCH 1/3] btrfs: Embed sector size check into BTRFS_MAX_INLINE_DATA_SIZE()

This patch along with any one uses sector/node size in btrfs_parse_options() should only use them after it get initialized. Unfortunately at this point, nodesize is not initialized in open_ctree(). So unfortunately, this patch needs extra work to move btrfs_parse_options() after basic fs_info

[PATCH 1/3] btrfs: Embed sector size check into BTRFS_MAX_INLINE_DATA_SIZE()

We have extra sector size check in cow_file_range_inline(), but doesn't implement it in BTRFS_MAX_INLINE_DATA_SIZE(). The biggest reason is that btrfs_symlink() also uses this macro to check name length. In fact such behavior makes max_inline calculation quite confusing, and cause unexpected

[PATCH 3/3] btrfs: Show more accurate max_inline

Btrfs shows max_inline option into kernel message, but for max_inline=4096, btrfs won't really inline 4096 bytes inline data if it's not compressed. Since we have unified the behavior and now BTRFS_MAX_INLINE_DATA_SIZE() should handle most of the condition check, just limit fs_info->max_inline to

[PATCH 2/3] btrfs: Unify inline extent creation condition for plain and compressed data

cow_file_range_inline() used different condition for plain and compressed data. For compressed data, it's allowed to have inline extent equal to sectorsize, while for plain data, it's not allowed to have inline extent equal to sectorsize. But since we limit BTRFS_MAX_INLINE_DATA_SIZE() to

Re: [PATCH 1/4] btrfs-progs: Limit inline extent below page size

On 2018年03月02日 01:47, Nikolay Borisov wrote: > > > On 1.03.2018 04:47, Qu Wenruo wrote: >> Kernel doesn't support to drop extent inside an inlined extent. >> And kernel tends to limit inline extent just below sectorsize, so also >> limit it in btrfs-progs. >> >> This fixes unexpected

Re: Ongoing Btrfs stability issues

On 1.03.2018 21:04, Alex Adriaanse wrote: > On Feb 16, 2018, at 1:44 PM, Austin S. Hemmelgarn > wrote: >> I would suggest changing this to eliminate the balance with '-dusage=10' >> (it's redundant with the '-dusage=20' one unless your filesystem is in >>

Re: Ongoing Btrfs stability issues

On Feb 16, 2018, at 1:44 PM, Austin S. Hemmelgarn wrote: > I would suggest changing this to eliminate the balance with '-dusage=10' > (it's redundant with the '-dusage=20' one unless your filesystem is in > pathologically bad shape), and adding equivalent filters for

Re: [PATCH 1/4] btrfs-progs: Limit inline extent below page size

On 1.03.2018 04:47, Qu Wenruo wrote: > Kernel doesn't support to drop extent inside an inlined extent. > And kernel tends to limit inline extent just below sectorsize, so also > limit it in btrfs-progs. > > This fixes unexpected -EOPNOTSUPP error from __btrfs_drop_extents() on > converted

Re: [PATCH 0/4] Fix long standing -EOPNOTSUPP problem caused by

On Thu, Mar 01, 2018 at 10:47:43AM +0800, Qu Wenruo wrote: > Kernel doesn't support dropping range inside inline extent, and prevents > such thing happening by limiting max inline extent size to > min(max_inline, sectorsize - 1) in cow_file_range_inline(). > > However btrfs-progs only inherit the

Re: [PATCH] Btrfs: dev-replace: skip prealloc extents when copy nocow pages

On Thu, Mar 01, 2018 at 12:52:11PM +, Filipe Manana wrote: > On Wed, Feb 28, 2018 at 1:10 AM, Liu Bo wrote: > > It doens't make sense to process prealloc extents as pages will be > > filled with zero when reading prealloc extents. > > > > Signed-off-by: Liu Bo

Re: [PATCH] Btrfs: dev-replace: skip prealloc extents when copy nocow pages

On Wed, Feb 28, 2018 at 1:10 AM, Liu Bo wrote: > It doens't make sense to process prealloc extents as pages will be > filled with zero when reading prealloc extents. > > Signed-off-by: Liu Bo Reviewed-by: Filipe Manana Makes sense.

Open invoices

Hello , I am in need of a copy of receipt # 69838940 for $3,526.76. If you could please e-mail or fax it to me today I would be eternally grateful. Email is: Or fax # 352-168-3330. >> http://condosiesta.com/New-order/ Best wishes, Open Past Due Orders.pdf Description: Adobe PDF

Re: btrfs space used issue

On 2018-03-01 05:18, Andrei Borzenkov wrote: On Thu, Mar 1, 2018 at 12:26 PM, vinayak hegde wrote: No, there is no opened file which is deleted, I did umount and mounted again and reboot also. I think I am hitting the below issue, lot of random writes were happening

Re: [PATCH 1/1] btrfs: introduce feature to forget a btrfs device

On 02/28/2018 08:57 AM, Liu Bo wrote: On Thu, Jan 11, 2018 at 09:25:50AM +0800, Anand Jain wrote: Support for a new command 'btrfs dev forget [dev]' is proposed here, to undo the effects of 'btrfs dev scan [dev]'. For this purpose, this patch proposes to use ioctl #5 as it was empty.

Re: [PATCH v3] btrfs: verify max_inline mount parameter

On 02/27/2018 11:45 PM, David Sterba wrote: On Mon, Feb 26, 2018 at 10:47:04AM +0800, Anand Jain wrote: We aren't verifying the parameter passed to the max_inline mount option. So we won't fail the mount if a junk value is specified, for example, -o max_inline=abc. This patch checks if input

Re: btrfs space used issue

On Thu, Mar 1, 2018 at 12:26 PM, vinayak hegde wrote: > No, there is no opened file which is deleted, I did umount and mounted > again and reboot also. > > I think I am hitting the below issue, lot of random writes were > happening and the file is not fully written and

Re: btrfs space used issue

No, there is no opened file which is deleted, I did umount and mounted again and reboot also. I think I am hitting the below issue, lot of random writes were happening and the file is not fully written and its sparse file. Let me try with disabling COW. file offset 0