On 2018年07月13日 13:32, Anand Jain wrote:
>
>
>
>
>
>>> But if you are planning to
>>> record and start at transaction [14] then its an overkill because
>>> transaction [19 and [20] are already in the disk.
>>
>> Yes, I'm doing it overkilled.
>
> Ah. Ok.
>
>> But it's already much
But if you are planning to
record and start at transaction [14] then its an overkill because
transaction [19 and [20] are already in the disk.
Yes, I'm doing it overkilled.
Ah. Ok.
But it's already much better than scrub all block groups (my original plan).
That's true.
Omar Sandoval 於 2018-07-13 06:19 寫到:
On Wed, Jul 11, 2018 at 11:59:36PM +0800, Ethan Lien wrote:
In commit b150a4f10d878 ("Btrfs: use a percpu to keep track of
possibly
pinned bytes") we use total_bytes_pinned to track how many bytes we
are
going to free in this transaction. When we are close
On 2018年07月13日 08:20, Qu Wenruo wrote:
>
>
> [snip]
>>> In this case, it depends on when and how we mark the device resilvering.
>>> If we record the generation of write error happens, then just initial a
>>> scrub for generation greater than that generation.
>>
>> If we record all the
Hi, Chris,
Chris Mason writes:
> On 19 Jun 2018, at 23:51, Huang, Ying wrote:
"Huang, Ying" writes:
> Hi, Josef,
>
> Do you have time to take a look at the regression?
>
> kernel test robot writes:
>
>> Greeting,
>>
>> FYI, we noticed a -12.3%
On 2018年07月13日 07:14, Marc MERLIN wrote:
> On Thu, Jul 12, 2018 at 01:26:41PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018年07月12日 01:09, Chris Murphy wrote:
>>> On Tue, Jul 10, 2018 at 12:09 PM, Marc MERLIN wrote:
Thanks to Su and Qu, I was able to get my filesystem to a point that
it's
[snip]
>> In this case, it depends on when and how we mark the device resilvering.
>> If we record the generation of write error happens, then just initial a
>> scrub for generation greater than that generation.
>
> If we record all the degraded transactions then yes. Not just the last
>
Hey.
Better late than never ;-)
Just to confirm: At least since 4.16.1, I could btrfs-restore from the
broken fs image again (that I've described in "spurious full btrfs
corruption" from around mid March).
So the regression in btrfsprogs has in fact been fixed by these
patches, it seems.
On Thu, Jul 12, 2018 at 01:26:41PM +0800, Qu Wenruo wrote:
>
>
> On 2018年07月12日 01:09, Chris Murphy wrote:
> > On Tue, Jul 10, 2018 at 12:09 PM, Marc MERLIN wrote:
> >> Thanks to Su and Qu, I was able to get my filesystem to a point that
> >> it's mountable.
> >> I then deleted loads of
From: Omar Sandoval
We have a build system internally which only needs to build the
libraries out of a repository, not any binaries. I looked at how this
works with other projects, and the best example was util-linux, which
makes it possible to enable or disable everything individually. This is
From: Omar Sandoval
Hi, Dave,
This is a resend of a couple of patches I sent back in April, rebased on
the current devel branch. Patch 1 cleans up some stale build targets,
and patch 2 makes the btrfs-progs build more flexible, so that it's
possible to pick and choose what gets built. Please
From: Omar Sandoval
These don't build anymore and don't appear to be used for anything.
Signed-off-by: Omar Sandoval
---
Makefile | 10 +-
dir-test.c | 518 ---
quick-test.c | 226 --
3 files changed, 1 insertion(+),
On Wed, Jul 11, 2018 at 11:59:36PM +0800, Ethan Lien wrote:
> In commit b150a4f10d878 ("Btrfs: use a percpu to keep track of possibly
> pinned bytes") we use total_bytes_pinned to track how many bytes we are
> going to free in this transaction. When we are close to ENOSPC, we check it
> and know
On 07/12/2018 07:07 PM, Pete wrote:
> On 07/12/2018 08:11 AM, Nikolay Borisov wrote:
>>
>>
>> This one shouldn't have gone RO since it has plenty of unallocated and
>> free space. What was the workload at the time it went RO? Hard to say,
>> it's best if you can provide output with the debug patch
On 07/12/2018 08:11 AM, Nikolay Borisov wrote:
>
>
> This one shouldn't have gone RO since it has plenty of unallocated and
> free space. What was the workload at the time it went RO? Hard to say,
> it's best if you can provide output with the debug patch applied when
> this issue re-appears.
>
Nikolay Borisov 於 2018-07-12 15:07 寫到:
On 11.07.2018 18:59, Ethan Lien wrote:
In commit b150a4f10d878 ("Btrfs: use a percpu to keep track of
possibly
pinned bytes") we use total_bytes_pinned to track how many bytes we
are
going to free in this transaction. When we are close to ENOSPC, we
On 07/12/2018 08:59 PM, Qu Wenruo wrote:
On 2018年07月12日 20:33, Anand Jain wrote:
On 07/12/2018 01:43 PM, Qu Wenruo wrote:
On 2018年07月11日 15:50, Anand Jain wrote:
BTRFS Volume operations, Device Lists and Locks all in one page:
Devices are managed in two contexts, the scan context
On 2018年07月12日 20:33, Anand Jain wrote:
>
>
> On 07/12/2018 01:43 PM, Qu Wenruo wrote:
>>
>>
>> On 2018年07月11日 15:50, Anand Jain wrote:
>>>
>>>
>>> BTRFS Volume operations, Device Lists and Locks all in one page:
>>>
>>> Devices are managed in two contexts, the scan context and the mounted
>>>
On Thu, Jul 12, 2018 at 11:40:54AM +0100, Filipe Manana wrote:
>On Wed, Jul 11, 2018 at 10:02 AM, Lu Fengqi wrote:
>> Hi,
>>
>> When I run generic/041 with v4.18-rc3 (turn on kasan and hung task
>> detection), btrfs-transaction kthread will trigger the hung task timeout
>> (stall at wait_event in
On 07/12/2018 01:43 PM, Qu Wenruo wrote:
On 2018年07月11日 15:50, Anand Jain wrote:
BTRFS Volume operations, Device Lists and Locks all in one page:
Devices are managed in two contexts, the scan context and the mounted
context. In scan context the threads originate from the btrfs_control
From: Qu Wenruo
Add enable subcommand for dedupe commmand group.
Signed-off-by: Qu Wenruo
Signed-off-by: Lu Fengqi
---
v10.4:
1. s/btrfs-dedupe/btrfs-dedupe-inband
2. replace strerror(errno) with %m
Documentation/btrfs-dedupe-inband.asciidoc | 114 +-
btrfs-completion
From: Qu Wenruo
Add basic ioctl header and command group framework for later use.
Alone with basic man page doc.
Signed-off-by: Qu Wenruo
Signed-off-by: Lu Fengqi
---
v10.4:
1. s/btrfs-dedupe/btrfs-dedupe-inband in man page
2. use SZ_* instead of the intermediate number
Patchset can be fetched from github:
https://github.com/littleroad/btrfs-progs.git dedupe_latest
Inband dedupe(in-memory backend only) ioctl support for btrfs-progs.
v7 changes:
Update ctree.h to follow kernel structure change
Update print-tree to follow kernel structure change
V8 changes:
From: Qu Wenruo
Add status subcommand for dedupe command group.
Signed-off-by: Qu Wenruo
Signed-off-by: Lu Fengqi
---
v10.4:
1. s/btrfs-dedupe/btrfs-dedupe-inband
2. replace strerror(errno) with %m
Documentation/btrfs-dedupe-inband.asciidoc | 3 +
btrfs-completion
From: Qu Wenruo
Add disable subcommand for dedupe command group.
Signed-off-by: Qu Wenruo
Signed-off-by: Lu Fengqi
---
v10.4:
1. s/btrfs-dedupe/btrfs-dedupe-inband
2. replace strerror(errno) with %m
Documentation/btrfs-dedupe-inband.asciidoc | 5 +++
btrfs-completion
From: Qu Wenruo
Introduce reconfigure subcommand to co-operate with new kernel ioctl
modification.
Signed-off-by: Qu Wenruo
Signed-off-by: Lu Fengqi
---
v10.4:
1. update btrfs-completion for reconfigure
2. replace strerror(errno) with %m
Documentation/btrfs-dedupe-inband.asciidoc | 7 +++
On Wed, Jul 11, 2018 at 10:02 AM, Lu Fengqi wrote:
> Hi,
>
> When I run generic/041 with v4.18-rc3 (turn on kasan and hung task
> detection), btrfs-transaction kthread will trigger the hung task timeout
> (stall at wait_event in btrfs_commit_transaction). At the same time, you
> can see that
From: Filipe Manana
Test that if we do a buffered write to a file, fsync it, clone a range
from another file into our file that overlaps the previously written
range, fsync the file again and then power fail, after we mount again the
filesystem, no file data was lost or corrupted.
This test is
From: Filipe Manana
When we clone a range into a file we can end up dropping existing
extent maps (or trimming them) and replacing them with new ones if the
range to be cloned overlaps with a range in the destination inode.
When that happens we add the new extent maps to the list of modified
From: Filipe Manana
Test that if we do a buffered write to a file, fsync it, clone a range
from another file into our file that overlaps the previously written
range, fsync the file again and then power fail, after we mount again the
filesystem, no file data was lost or corrupted.
This test is
From: Filipe Manana
When we clone a range into a file we can end up dropping existing
extent maps (or trimming them) and replacing them with new ones if the
range to be cloned overlaps with a range in the destination inode.
When that happens we add the new extent maps to the list of modified
On 10.07.2018 21:22, Anand Jain wrote:
> Move the section of the code which performs the check if the device is
> indelible, move that into a helper function.
>
> Signed-off-by: Anand Jain
> ---
> fs/btrfs/volumes.c | 49 ++---
> 1 file changed, 30
On 10.07.2018 21:22, Anand Jain wrote:
> When the replace is running the fs_devices::num_devices also includes
> the replace device, however in some operations like device delete and
> balance it needs the actual num_devices without the repalce devices, so
> now the function btrfs_num_devices()
On 10.07.2018 21:22, Anand Jain wrote:
> In preparation to de-duplicate a section of code where we deduce the
> num_devices, use warn instead of bug.
>
> Signed-off-by: Anand Jain
> ---
> fs/btrfs/volumes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 12.07.2018 10:04, Peter Chant wrote:
> On 07/12/2018 07:10 AM, Nikolay Borisov wrote:
>>
>>
>> On 10.07.2018 10:04, Pete wrote:
>>> I've just had the error in the subject which caused the file system to
>>> go read-only.
>>>
>>> Further part of error message:
>>> WARNING: CPU: 14 PID: 1351
On 11.07.2018 18:59, Ethan Lien wrote:
> In commit b150a4f10d878 ("Btrfs: use a percpu to keep track of possibly
> pinned bytes") we use total_bytes_pinned to track how many bytes we are
> going to free in this transaction. When we are close to ENOSPC, we check it
> and know if we can make the
On 07/12/2018 07:10 AM, Nikolay Borisov wrote:
>
>
> On 10.07.2018 10:04, Pete wrote:
>> I've just had the error in the subject which caused the file system to
>> go read-only.
>>
>> Further part of error message:
>> WARNING: CPU: 14 PID: 1351 at fs/btrfs/extent-tree.c:3076
>>
On 2018年07月12日 14:27, Nikolay Borisov wrote:
>
>
> On 12.07.2018 09:19, Qu Wenruo wrote:
>> Introduce a new macro based compile time check for ioctl structures.
>>
>> The new macro is BTRFS_ASSERT_SIZE(), which is mostly copied from
>> VMMDEV_ASSERT_SIZE().
>>
>> Such check is only added to
On 11.07.2018 23:59, Pete wrote:
> On 07/10/2018 09:38 AM, Martin Raiber wrote:
>
>> This is probably a known issue. See
>> https://www.spinics.net/lists/linux-btrfs/msg75647.html
>> You could apply the patch in this thread and mount with enospc_debug to
>> confirm it is the same issue.
>> --
On 12.07.2018 09:23, Gu Jinxiang wrote:
> fs_devices is always passed to btrfs_scan_one_device which
> overrides it. And in the call stack below fs_devices is passed to
> btrfs_scan_one_device from btrfs_mount_root.
> And in btrfs_mount_root the output fs_devices of this call stack
> is not
On 12.07.2018 09:23, Gu Jinxiang wrote:
> Instead of pointer to btrfs_fs_devices as an arg in
> btrfs_scan_one_device, better to make it as a return value.
>
> And since btrfs_fs_devices can be get by btrfs_device,
> better to return btrfs_device than fs_btrfs_devices.
>
> Signed-off-by: Gu
Instead of pointer to btrfs_fs_devices as an arg in
btrfs_scan_one_device, better to make it as a return value.
And since btrfs_fs_devices can be get by btrfs_device,
better to return btrfs_device than fs_btrfs_devices.
Signed-off-by: Gu Jinxiang
---
Changelog:
v4: as suggested by Anand,
fs_devices is always passed to btrfs_scan_one_device which
overrides it. And in the call stack below fs_devices is passed to
btrfs_scan_one_device from btrfs_mount_root.
And in btrfs_mount_root the output fs_devices of this call stack
is not used.
btrfs_mount_root
->
On 12.07.2018 09:19, Qu Wenruo wrote:
> Introduce a new macro based compile time check for ioctl structures.
>
> The new macro is BTRFS_ASSERT_SIZE(), which is mostly copied from
> VMMDEV_ASSERT_SIZE().
>
> Such check is only added to structure pended to power of 2.
> And exposed one
Introduce a new macro based compile time check for ioctl structures.
The new macro is BTRFS_ASSERT_SIZE(), which is mostly copied from
VMMDEV_ASSERT_SIZE().
Such check is only added to structure pended to power of 2.
And exposed one structure, btrfs_ioctl_get_dev_stats() is not aligned
well.
The
On 10.07.2018 10:04, Pete wrote:
> I've just had the error in the subject which caused the file system to
> go read-only.
>
> Further part of error message:
> WARNING: CPU: 14 PID: 1351 at fs/btrfs/extent-tree.c:3076
> btrfs_run_delayed_refs*0x163/0x190
>
> 'Screenshot' here:
>
46 matches
Mail list logo
