linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Nikolay Borisov <nborisov@suse.com>, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org
Cc: dsterba@suse.cz
Subject: Re: [PATCH v2 4/7] btrfs-progs: check/original mode: Check inline extent size
Date: Tue, 13 Mar 2018 17:06:41 +0800	[thread overview]
Message-ID: <4b39d6d3-28ab-4025-bb06-19c208d34723@gmx.com> (raw)
In-Reply-To: <2d0c3fac-7a3b-e3cf-4cef-d7415608382e@suse.com>


[-- Attachment #1.1: Type: text/plain, Size: 3986 bytes --]



On 2018年03月13日 16:40, Nikolay Borisov wrote:
> 
> 
> On 13.03.2018 03:56, Qu Wenruo wrote:
>> For inline compressed file extent, kernel doesn't allow inline extent
>> ram size larger than sector size and on-disk inline extent size should
>> not exceed BTRFS_MAX_INLINE_DATA_SIZE().
>>
>> For inline uncompressed file extent, kernel doesn't allow inline extent
>> ram and on-disk size larger than either BTRFS_MAX_INLINE_DATA_SIZE() or
>> sector size.
>>
>> Check it in original mode.
>>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>  check/main.c          | 16 ++++++++++++++++
>>  check/mode-original.h |  1 +
>>  2 files changed, 17 insertions(+)
>>
>> diff --git a/check/main.c b/check/main.c
>> index 97baae583f04..7821faa929a3 100644
>> --- a/check/main.c
>> +++ b/check/main.c
>> @@ -560,6 +560,8 @@ static void print_inode_error(struct btrfs_root *root, struct inode_record *rec)
>>  		fprintf(stderr, ", bad file extent");
>>  	if (errors & I_ERR_FILE_EXTENT_OVERLAP)
>>  		fprintf(stderr, ", file extent overlap");
>> +	if (errors & I_ERR_FILE_EXTENT_TOO_LARGE)
>> +		fprintf(stderr, ", inline file extent too large");
> 
> offtopic:
> 
> So in lowmem mode when the error is printed the user is informed what is
> the maximum expected size, but in normal mode this is not case? Why is
> that? I can see other error messages also don't print out expected values?

The difference is in how different mode handles error.

For normal mode, we use bitmap to indicate error, which can only tell us
what's wrong, but without extra info.

In lowmem mode, we just output the error when we found it, so we have
extra info.

I'm not sure the difference makes sense or not, but at least lowmem mode
is a little more friendly for developer. (For end user, I don't know if
such detailed output would help)


Thanks,
Qu

> 
>>  	if (errors & I_ERR_FILE_EXTENT_DISCOUNT)
>>  		fprintf(stderr, ", file extent discount");
>>  	if (errors & I_ERR_DIR_ISIZE_WRONG)
>> @@ -1433,6 +1435,8 @@ static int process_file_extent(struct btrfs_root *root,
>>  	u64 disk_bytenr = 0;
>>  	u64 extent_offset = 0;
>>  	u64 mask = root->fs_info->sectorsize - 1;
>> +	u32 max_inline_size = min_t(u32, mask,
>> +				BTRFS_MAX_INLINE_DATA_SIZE(root->fs_info));
>>  	int extent_type;
>>  	int ret;
>>  
>> @@ -1458,9 +1462,21 @@ static int process_file_extent(struct btrfs_root *root,
>>  	extent_type = btrfs_file_extent_type(eb, fi);
>>  
>>  	if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
>> +		u8 compression = btrfs_file_extent_compression(eb, fi);
>> +		struct btrfs_item *item = btrfs_item_nr(slot);
>> +
>>  		num_bytes = btrfs_file_extent_inline_len(eb, slot, fi);
>>  		if (num_bytes == 0)
>>  			rec->errors |= I_ERR_BAD_FILE_EXTENT;
>> +		if (compression) {
>> +			if (btrfs_file_extent_inline_item_len(eb, item) >
>> +			    max_inline_size ||
>> +			    num_bytes > root->fs_info->sectorsize)
>> +				rec->errors |= I_ERR_FILE_EXTENT_TOO_LARGE;
>> +		} else {
>> +			if (num_bytes > max_inline_size)
>> +				rec->errors |= I_ERR_FILE_EXTENT_TOO_LARGE;
>> +		}
>>  		rec->found_size += num_bytes;
>>  		num_bytes = (num_bytes + mask) & ~mask;
>>  	} else if (extent_type == BTRFS_FILE_EXTENT_REG ||
>> diff --git a/check/mode-original.h b/check/mode-original.h
>> index f859af478f0f..368de692fdd1 100644
>> --- a/check/mode-original.h
>> +++ b/check/mode-original.h
>> @@ -185,6 +185,7 @@ struct file_extent_hole {
>>  #define I_ERR_SOME_CSUM_MISSING		(1 << 12)
>>  #define I_ERR_LINK_COUNT_WRONG		(1 << 13)
>>  #define I_ERR_FILE_EXTENT_ORPHAN	(1 << 14)
>> +#define I_ERR_FILE_EXTENT_TOO_LARGE	(1 << 15)
>>  
>>  struct inode_record {
>>  	struct list_head backrefs;
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

  reply	other threads:[~2018-03-13  9:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13  1:56 [PATCH v2 0/7] Fix long standing -EOPNOTSUPP problem caused by large inline extent Qu Wenruo
2018-03-13  1:56 ` [PATCH v2 1/7] btrfs-progs: convert/ext2: Fix inline extent creation check Qu Wenruo
2018-03-19 13:20   ` David Sterba
2018-03-13  1:56 ` [PATCH v2 2/7] btrfs-progs: convert/reiserfs: Fix inline file " Qu Wenruo
2018-03-13  1:56 ` [PATCH v2 3/7] btrfs-progs: mkfs/rootdir: Fix inline " Qu Wenruo
2018-03-13  1:56 ` [PATCH v2 4/7] btrfs-progs: check/original mode: Check inline extent size Qu Wenruo
2018-03-13  8:40   ` Nikolay Borisov
2018-03-13  9:06     ` Qu Wenruo [this message]
2018-03-13  1:56 ` [PATCH v2 5/7] btrfs-progs: check/lowmem " Qu Wenruo
2018-03-13  8:39   ` Nikolay Borisov
2018-03-13  9:04     ` Qu Wenruo
2018-03-13  1:56 ` [PATCH v2 6/7] btrfs-progs: test/convert: Add test case for invalid large inline data extent Qu Wenruo
2018-03-13  1:56 ` [PATCH v2 7/7] btrfs-progs: test/mkfs: Add test case for rootdir inline extent size Qu Wenruo
2018-03-19 13:25   ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b39d6d3-28ab-4025-bb06-19c208d34723@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).