Entrance function copy_nocow_pages() is no longer used, and remove all
its children functions, since they can't handle compressed nodatasum
extent properly and in fact the "optimization" is pretty niche, using
the unified scrub_pages() would be a much better idea.
Signed-off-by: Qu Wenruo
---
[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 one.
Test case already submitted to fstests:
On 06/04/2018 11:30 PM, Qu Wenruo wrote:
On 2018年05月29日 22:58, Steve Leung wrote:
Qu Wenruo writes:
On 2018年05月28日 11:47, Steve Leung wrote:
On 05/26/2018 06:57 PM, Qu Wenruo wrote:
[snip]
Still nope.
What about encrypt it and upload it to some public storage provider like
google
Only works when device(s) not specified.
At verbose level 1, for each registered btrfs filesystem, compactly show fs
uuid, and for each of its devices, the device id, name, and uuid.
At verbose level 2, show everything for the fs and its devices.
Previous behavior of print_all_devices(), which
On Tue, Jun 5, 2018 at 10:52 PM, james harvey wrote:
> Only works when device(s) not specified.
> ...
Pretend the original email subject was:
[PATCH] btrfs-progs: device: Added verbose option to scan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a
Only works when device(s) not specified.
At verbose level 1, for each registered btrfs filesystem, compactly show fs
uuid, and for each of its devices, the device id, name, and uuid.
At verbose level 2, show everything for the fs and its devices.
Previous behavior of print_all_devices(), which
On 06/05/2018 07:39 PM, Nikolay Borisov wrote:
> When btrfs check detects a freespace tree extent which ends beyond the
> blockgroup containing it a misleading error messages is printed. For
> example if we have the following extent in the freespace tree:
>
> item 5 key (30408704
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:
https://bugzilla.kernel.org/show_bug.cgi?id=199931
On Tue, Jun 5, 2018 at 4:03 PM, Andrew Morton wrote:
> On Tue, 05 Jun 2018 18:01:36 + bugzilla-dae...@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=199931
>>
>> Bug ID: 199931
>>Summary: systemd/rtorrent file data corruption when using
On Wed, 6 Jun 2018 06:22:25 +0900 Tetsuo Handa
wrote:
> On 2018/06/06 5: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
> >
On 2018/06/06 5: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:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=199931
>>
>>
(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:
> https://bugzilla.kernel.org/show_bug.cgi?id=199931
>
> Bug ID: 199931
>Summary:
On 5.06.2018 17:24, David Sterba wrote:
> On Tue, Jun 05, 2018 at 10:14:51PM +0800, Qu Wenruo wrote:
The previous version (a completely different direction though) is much
smaller.
https://patchwork.kernel.org/patch/10440541/
However personally speaking, I still prefer
On Tue, Jun 05, 2018 at 10:14:51PM +0800, Qu Wenruo wrote:
> >> The previous version (a completely different direction though) is much
> >> smaller.
> >> https://patchwork.kernel.org/patch/10440541/
> >>
> >> However personally speaking, I still prefer this one, as it's much simpler.
> >
> > As
On 2018年06月05日 22:07, David Sterba wrote:
> On Tue, Jun 05, 2018 at 09:47:46PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018年06月05日 21:42, David Sterba wrote:
>>> On Tue, Jun 05, 2018 at 01:34:03PM +0800, Qu Wenruo wrote:
Hi David,
It would be pretty nice if we could get this fix (or
On Mon, Jun 04, 2018 at 04:41:07PM +0900, Misono Tomohiro wrote:
> Signed-off-by: Misono Tomohiro
> ---
>
> Hi david,
>
> It seems that v8 patch I sent last week is missed and commit in misc-next
> tree is also a bit updated from v7, so I resend the fix as a separate patch.
>
> Please fold
On Tue, Jun 05, 2018 at 09:47:46PM +0800, Qu Wenruo wrote:
>
>
> On 2018年06月05日 21:42, David Sterba wrote:
> > On Tue, Jun 05, 2018 at 01:34:03PM +0800, Qu Wenruo wrote:
> >> Hi David,
> >>
> >> It would be pretty nice if we could get this fix (or previous RFC patch)
> >> to get into current
On 2018年06月05日 21:42, David Sterba wrote:
> On Tue, Jun 05, 2018 at 01:34:03PM +0800, Qu Wenruo wrote:
>> Hi David,
>>
>> It would be pretty nice if we could get this fix (or previous RFC patch)
>> to get into current release cycle.
>>
>> As it's a unrecoverable data corruption, it would be
On Tue, Jun 05, 2018 at 01:34:03PM +0800, Qu Wenruo wrote:
> Hi David,
>
> It would be pretty nice if we could get this fix (or previous RFC patch)
> to get into current release cycle.
>
> As it's a unrecoverable data corruption, it would be better to get it
> fixed as soon as possible.
That we
On 2018年06月05日 18:42, Anand Jain wrote:
>
>
> On 06/01/2018 09:34 AM, Qu Wenruo wrote:
>> This is a long existing bug (from 2012) but exposed by a reporter
>> recently, that when compressed extent without data csum get written to
>> device-replace target device, the written data is in fact
When btrfs check detects a freespace tree extent which ends beyond the
blockgroup containing it a misleading error messages is printed. For
example if we have the following extent in the freespace tree:
item 5 key (30408704 FREE_SPACE_INFO 1073741824) itemoff 16259 itemsize 8
free
On 06/01/2018 09:34 AM, Qu Wenruo wrote:
This is a long existing bug (from 2012) but exposed by a reporter
recently, that when compressed extent without data csum get written to
device-replace target device, the written data is in fact uncompressed data
other than the original compressed
22 matches
Mail list logo
