To Steve,
This patchset should fix your problem.
Would you please have a try?
Thanks,
Qu
On 2018年06月06日 15:27, Qu Wenruo wrote:
> The patchset can be fetched from github (*):
> https://github.com/adam900710/btrfs-progs/tree/inline_ram_bytes
>
> It's based on David's devel branch, whose HEAD
On 2018年06月07日 12:20, Su Yue wrote:
>
>
> On 06/07/2018 11:33 AM, james harvey wrote:
>> =[ NOTE ]=
>>
>> I think I found a buffer over-read error that will come up other places,
>> unless
>> EACH caller checks bounds themselves. See "Bonus bug, LEFT FOR READER"
>> below.
>>
>>
On 2018年06月07日 11:33, james harvey wrote:
> =[ NOTE ]=
>
> I think I found a buffer over-read error that will come up other places,
> unless
> EACH caller checks bounds themselves. See "Bonus bug, LEFT FOR READER" below.
>
> =[ PROBLEM ]=
>
> Using btrfs-progs v4.16:
>
> No
On 06/07/2018 11:33 AM, james harvey wrote:
> =[ NOTE ]=
>
> I think I found a buffer over-read error that will come up other places,
> unless
> EACH caller checks bounds themselves. See "Bonus bug, LEFT FOR READER" below.
>
> =[ PROBLEM ]=
>
> Using btrfs-progs v4.16:
>
>
On 06/07/2018 10:45 AM, Misono Tomohiro wrote:
>
>
> On 2018/05/15 10:33, Su Yue wrote:
>> Define new macro I_ERR_ODD_INODE_FLAGS to represents odd inode flags.
>>
>> Symlinks should never have append/immutable flags.
>> While processing inodes, if found a symlink with append/immutable
>>
=[ NOTE ]=
I think I found a buffer over-read error that will come up other places, unless
EACH caller checks bounds themselves. See "Bonus bug, LEFT FOR READER" below.
=[ PROBLEM ]=
Using btrfs-progs v4.16:
No extent found at range [10955980800,10955984896)
But, this extent
Hey.
Just wondered about the following:
When I have a btrfs which acts as a master and from which I make copies
of snapshots on it via send/receive (with using -p at send) to other
btrfs which acts as copies like this:
master +--> copy1
+--> copy2
\--> copy3
and if now e.g. the
Initialize all filed of btrfs_inode_item to zero in order to prevent
having some garbage, especially for flags field.
Signed-off-by: Misono Tomohiro
---
check/mode-common.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/check/mode-common.c b/check/mode-common.c
index
On 2018/05/15 10:33, Su Yue wrote:
> Define new macro I_ERR_ODD_INODE_FLAGS to represents odd inode flags.
>
> Symlinks should never have append/immutable flags.
> While processing inodes, if found a symlink with append/immutable
> flags, mark the inode record with I_ERR_ODD_INODE_FLAGS.
>
>
Hi Ian,
On Thu, Jun 07, 2018 at 08:47:28AM +0800, Ian Kent wrote:
> On Wed, 2018-06-06 at 23:38 +0200, Mark Fasheh wrote:
> > Hi,
>
> I'm not sure I understand what the problem is.
I'll try to elaborate below.
> > We have an inconsistency in how the kernel is exporting inode number /
> >
On Tue, Jun 5, 2018 at 12:36 AM, Qu Wenruo wrote:
> [BUG]
> Btrfs can easily create compressed extent without checksum (even
> though it shouldn't), and if we then try to replace device containing
> such extent, the result device will contain all the uncompressed data
> instead of the compressed
On Wed, 2018-06-06 at 23:38 +0200, Mark Fasheh wrote:
> Hi,
I'm not sure I understand what the problem is.
>
> We have an inconsistency in how the kernel is exporting inode number /
> device pairs for user space. There's of course stat(2) and statx(2),
> but aside from those we simply dump
Hi,
We have an inconsistency in how the kernel is exporting inode number /
device pairs for user space. There's of course stat(2) and statx(2),
but aside from those we simply dump inode->i_ino and super->s_dev. In
some cases, the dumped values differ from what is returned via stat(2)
or statx(2).
On Wed, Jun 6, 2018 at 3:06 PM, Marc Lehmann wrote:
> On Tue, Jun 05, 2018 at 05:52:38PM -0400, james harvey
> wrote:
>> >> This is not always reproducible, but when deleting our journal, creating
>> >> log
>> >> messages for a few hours and then doing the above manually has a ~50%
>> >>
On Tue, Jun 05, 2018 at 05:52:38PM -0400, james harvey
wrote:
> >> This is not always reproducible, but when deleting our journal, creating
> >> log
> >> messages for a few hours and then doing the above manually has a ~50%
> >> chance of
> >> corrupting the journal.
> ...
>
> My strong bet
%fs_devices can be free-ed by btrfs_free_stale_devices() when the
close_fs_devices() drops fs_devices::opened to zero, but close_fs_devices
tries to access the %fs_devices again without the device_list_mutex.
Fix this by bringing the %fs_devices access with in the device_list_mutex.
Stack trace
On Sat, Jun 02, 2018 at 11:26:41PM +0200, Hans van Kranenburg wrote:
> In case of RAID10, fi usage is reporting half the amount of allocated
> space and twice the amount of unallocated disk space. Let's fix this.
>
> For example, a RAID10 chunk of 3GiB with num_stripes 6, half of the
> stripes
On Sat, Jun 02, 2018 at 11:26:11PM +0300, Yevgeny Popovych wrote:
> When traverse_directory() encounters an inode item that already exists
> and has a normal amount of hardlinks - it just continues with a next one,
> w/o clearing the ret value (set to -EEXIST).
>
> But, if the last file
On Sat, Jun 02, 2018 at 11:30:22PM +0300, Yevgeny Popovych wrote:
> Signed-off-by: Yevgeny Popovych
Applied, thanks.
--
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
On Wed, Jun 6, 2018 at 9:44 PM, Chris Mason wrote:
> On 6 Jun 2018, at 9:38, Liu Bo wrote:
>
>> On Wed, Jun 6, 2018 at 8:18 AM, Chris Mason wrote:
>>>
>>>
>>>
>>> On 5 Jun 2018, at 16:03, Andrew Morton wrote:
>>>
(switched to email. Please respond via emailed reply-to-all, not via
the
On 6 Jun 2018, at 9:38, Liu Bo wrote:
On Wed, Jun 6, 2018 at 8:18 AM, Chris Mason wrote:
On 5 Jun 2018, at 16:03, Andrew Morton wrote:
(switched to email. Please respond via emailed reply-to-all, not
via the
bugzilla web interface).
On Tue, 05 Jun 2018 18:01:36 +
On Wed, Jun 6, 2018 at 8:18 AM, Chris Mason wrote:
>
>
> On 5 Jun 2018, at 16:03, Andrew Morton wrote:
>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Tue, 05 Jun 2018 18:01:36 + bugzilla-dae...@bugzilla.kernel.org
>> wrote:
On Tue, Jun 05, 2018 at 05:30:18PM +0300, Nikolay Borisov wrote:
> On 5.06.2018 17:24, David Sterba wrote:
> > On Tue, Jun 05, 2018 at 10:14:51PM +0800, Qu Wenruo wrote:
> >>> and then the whole callchain of copy_nocow_pages continues.
> >>
> >> Understood.
> >> I could go this method.
> >>
> >>
https://www.spinics.net/lists/linux-btrfs/msg77927.html
Thanks to Hans van Kranenburg and Holger Hoffstätte, the above has the link to
a message with the patch for this which was already included in kernel 4.16.11
which was uploaded to Debian on the 27th of May and got into testing about the
On Tue 05-06-18 13:03:29, Andrew Morton wrote:
[...]
> > As for why we would do something silly as dropping the caches every hour
> > (in a
> > cronjob), we started doing this recently because after kernel 4.4, we got
> > frequent OOM kills despite having gigabytes of available memory (e.g. 12GB
On 06/06/2018 04:26 PM, Qu Wenruo wrote:
> It looks like that around 2014, btrfs kernel has a regression that would
> cause offset-by-one ram_bytes for inline extent.
>
> Add the ability to repair it in original mode.
>
> Reported-by: Steve Leung
> Signed-off-by: Qu Wenruo
Reviewed-by: Su
It looks like that around 2014, btrfs kernel has a regression that would
cause offset-by-one ram_bytes for inline extent.
Add the ability to repair it in original mode.
Reported-by: Steve Leung
Signed-off-by: Qu Wenruo
---
changelog:
v2:
Add extra output for print_inode_error().
Reword the
On 2018年06月06日 16:08, Su Yue wrote:
>
>
> On 06/06/2018 03:27 PM, Qu Wenruo wrote:
>> It looks like that around 2014, btrfs kernel has a regression that would
>> cause offset-by-one ram_bytes for inline extent.
>>
>> Add the ability to repair it in original mode.
>>
>> Reported-by: Steve Leung
On 06/06/2018 03:27 PM, Qu Wenruo wrote:
> It looks like that around 2014, btrfs kernel has a regression that would
> cause offset-by-one ram_bytes for inline extent.
>
> Add the ability to repair it in original mode.
>
> Reported-by: Steve Leung
> Signed-off-by: Qu Wenruo
> ---
>
We used to call btrfs_file_extent_inline_len() to get the uncompressed
data size of an inlined extent.
However this function is hiding evil, for compressed extent, it has no
choice but to directly read out ram_bytes from btrfs_file_extent_item.
While for uncompressed extent, it uses item size to
Current check_file_extent() doesn't support later repair work, since it
doesn't accept btrfs_path structure as parameter, thus it can't modify
btrfs trees, or later check will still use the old and wrong path.
Use btrfs_path to replace btrfs_key, extent_buffer and slot parameters,
so we can
[BUG]
If one uncompressed inline extent has incorrect ram_bytes, neither btrfs
check nor dump-tree could detect such corruption.
[CAUSE]
Every caller tries to read inline extent ram_bytes is using
btrfs_file_extent_inline_len(), other than directly calling
btrfs_file_extent_ram_bytes().
For
Similar to the original mode repair.
Reported-by: Steve Leung
Signed-off-by: Qu Wenruo
---
check/mode-lowmem.c | 73 -
1 file changed, 72 insertions(+), 1 deletion(-)
diff --git a/check/mode-lowmem.c b/check/mode-lowmem.c
index
Signed-off-by: Qu Wenruo
---
.../035-inline-bad-ram-bytes/offset_by_one.img | Bin 0 -> 3072 bytes
.../fsck-tests/035-inline-bad-ram-bytes/test.sh | 11 +++
2 files changed, 11 insertions(+)
create mode 100644 tests/fsck-tests/035-inline-bad-ram-bytes/offset_by_one.img
create mode
When using decompress() in copy_one_inline(), we're passing the
decompressed extent size (ram_bytes) into decompress().
However we only has @inline_item_len read out, the pending data will be
uninitialized data.
Thankfully, all compression methods supported have some extra data in
its header,
It looks like that around 2014, btrfs kernel has a regression that would
cause offset-by-one ram_bytes for inline extent.
Add the ability to repair it in original mode.
Reported-by: Steve Leung
Signed-off-by: Qu Wenruo
---
check/main.c | 44 +--
The patchset can be fetched from github (*):
https://github.com/adam900710/btrfs-progs/tree/inline_ram_bytes
It's based on David's devel branch, whose HEAD is:
commit 0d1c5812e28e286648781c7b35b542311cc01aa4 (david/devel)
Author: Matthias Benkard
Date: Wed Apr 25 16:34:54 2018 +0200
Prevent unnecessary error from failing fsync(), if opened read only.
Performed 'grep "writeable = " *.h *.c' to make sure there were no odd
situations where fsync() might still be desired here. They're all straight-
forward. The only situation where writeable will be 0 is if btrfs_open_devices
38 matches
Mail list logo
