[PATCH 3/3] btrfs-progs: fi usage: cleanup unneccessary permission error check

Since BTRFS_IOC_FS_INFO does not require root privilege, there is no need to check EPERM error. Signed-off-by: Tomohiro Misono --- cmds-fi-usage.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/cmds-fi-usage.c b/cmds-fi-usage.c index 7bbc9896..b0721560

[PATCH 1/3] btrfs-progs: fi usage: change warning message more appropriately

"fi usage" shows the warning "RAID5/6 numbers will be incorrect" when runnning without root privilege even if raid5/6 is not used. What happens is it cannot get the per device profile usage info, so change the message more appropriately. Signed-off-by: Tomohiro Misono

[PATCH 0/3] Some fix for fi usage

Patch 1 and 2 aims to fix the "fi du" to include the information of "fi df" even when runnning without root previlege. Patch 3 is a independent cleanup. Tomohiro Misono (3): btrfs-progs: fi usage: change warning message more appropriately btrfs-progs: fi usage: change to output more info

Re: [PATCH 1/5] btrfs-progs: Add location check when process share_data_ref item

On 2017年11月29日 03:02, David Sterba wrote: > On Fri, Nov 24, 2017 at 06:41:28PM +0800, Gu Jinxiang wrote: >> The following test failed becasuse share_data_ref be added into >> extent_cache when deal with root tree node. > > The whole function run_next_block would need to be revisited with >

Re: [PATCH v3 2/3] btrfs-progs: fi defrag: do not exit if defrag range ioctl is unsupported

On 2017年11月30日 14:37, Qu Wenruo wrote: > > > On 2017年11月29日 10:12, Su Yue wrote: >> If ioctl of defrag range is unsupported, defrag will exit immediately. >> >> Since caller can handle the error, let cmd_filesystem_defrag() >> close file, break the loop and return error instead of calling

Re: [PATCH v2 1/3] btrfs-progs: fi defrag: clean up duplicate code if find errors

On 2017年11月28日 17:14, Su Yue wrote: > In function cmd_filesystem_defrag(), lines of code for error handling > are duplicate and hard to expand in further. > > Create a jump label for errors. > > Signed-off-by: Su Yue > --- > Changelog: > v2: Record -errno to return

Re: A partially failing disk in raid0 needs replacement

Hi Chris > > I don't see how you get an IO error in user space without the kernel > reporting the source of that IO error, whatever it is. > I totally agree, so I just retried the deletion. The only thing related I could see in /var/log/messages is this: Nov 30 07:29:57 box kernel: [368193.019160]

Re: [PATCH v3 2/3] btrfs-progs: fi defrag: do not exit if defrag range ioctl is unsupported

On 2017年11月29日 10:12, Su Yue wrote: > If ioctl of defrag range is unsupported, defrag will exit immediately. > > Since caller can handle the error, let cmd_filesystem_defrag() > close file, break the loop and return error instead of calling exit(1). > > Suggested-by: David Sterba

Re: A partially failing disk in raid0 needs replacement

On Wed, Nov 29, 2017 at 10:28 PM, Klaus Agnoletti wrote: > Hi Chris, > >> >> I assume when you get that, either when deleting the device or >> scrubbing, that you also see the device unrecoverable read error in >> dmesg, as originally reported. If the drive must have the

Re: A partially failing disk in raid0 needs replacement

Hi Chris, > > I assume when you get that, either when deleting the device or > scrubbing, that you also see the device unrecoverable read error in > dmesg, as originally reported. If the drive must have the information > on that lost sector, and you can't increase SCT ERC time (as well as > the

Re: [PATCH 6/9] btrfs-progs: mkfs: Fix regression preventing --rootdir to create file

On 2017/11/29 18:16, Qu Wenruo wrote: > Commit 460e93f25754 ("btrfs-progs: mkfs: check the status of file at mkfs") > will try to check the file state before creating fs on it. > > The check is mostly fine for normal mkfs case, while for --rootdir > option, it's allowed to create new file if

Re: [btrfs_mount] general protection fault: 0000 [#1] SMP

On Wed, Nov 29, 2017 at 06:44:43PM -0800, Linus Torvalds wrote: On Wed, Nov 29, 2017 at 6:38 PM, Nick Terrell wrote: The stack trace looks like the bug fixed by Qu Wenruo: btrfs: Fix wild memory access in compression level parser [1] That fix looks to be included in the

Re: [btrfs_mount] general protection fault: 0000 [#1] SMP

On Wed, Nov 29, 2017 at 6:38 PM, Nick Terrell wrote: > > The stack trace looks like the bug fixed by > > Qu Wenruo: > btrfs: Fix wild memory access in compression level parser [1] > > That fix looks to be included in the pull request for 4.15-rc2 [2]. Which got merged

Re: [btrfs_mount] general protection fault: 0000 [#1] SMP

> On Nov 29, 2017, at 6:21 PM, Fengguang Wu wrote: > > Hello, > > FYI this happens in mainline kernel 4.15.0-rc1. > It looks like a new regression. Bisect is in progress. > > It occurs in 11 out of 11 xfstests run. > > [ 1456.361614] > [ 1456.918942] BTRFS info

[PATCH v2.2 2/2] btrfs: Ensure btrfs_trim_fs can trim the whole fs

[BUG] fstrim on some btrfs only trims the unallocated space, not trimming any space in existing block groups. [CAUSE] Before fstrim_range passed to btrfs_trim_fs(), it get truncated to range [0, super->total_bytes). So later btrfs_trim_fs() will only be able to trim block groups in range [0,

Re: [GIT PULL] Btrfs fixes for 4.15-rc2

On Wed, Nov 29, 2017 at 11:28 AM, David Sterba wrote: > > With signed tag: for-4.15-rc2-tag > > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-4.15-rc2 Oh, please actually ask me to pull the signed tag (exact same pull-request, just point git request-pull

Re: A partially failing disk in raid0 needs replacement

On Wed, Nov 29, 2017 at 6:33 AM, Klaus Agnoletti wrote: > Hi list > > Can anyone give me any hints here? If not, my plan right now is to > start updating the server to latest debian stable (it's currently > running Jessie), to get access to a newer btrfs driver and tools, >

Re: [PATCH v2.1 2/2] btrfs: Ensure btrfs_trim_fs can trim the whole fs

On Tue, 28 Nov 2017 15:20:39 +0800, Qu Wenruo wrote: > [BUG] > fstrim on some btrfs only trims the unallocated space, not trimming any > space in existing block groups. > > [CAUSE] > Before fstrim_range passed to btrfs_trim_fs(), it get truncated to > range [0, super->total_bytes). > So later

Re: [PATCH 1/2] btrfs: submit a normal bio for the mirror read

On Wed, Nov 29, 2017 at 03:11:14PM +0800, Anand Jain wrote: > When the fist mirror failed to read we submit bio again to read from the > 2nd mirror, however during this, we also set the flag REQ_FAILFAST_DEV > which indicates to the underlying block device driver not to perform the > default IO

[GIT PULL] Btrfs fixes for 4.15-rc2

Hi, we've collected some fixes in since the pre-merge window freeze. There's technically only one regression fix for 4.15, but the rest seems important and candidates for stable. No merge conflicts, please pull, thanks. - fix missing flush bio puts in error cases (is serious, but rarely happens)

Re: Read before you deploy btrfs + zstd

29.11.2017 16:24, Austin S. Hemmelgarn пишет: > On 2017-11-28 18:49, David Sterba wrote: >> On Tue, Nov 28, 2017 at 09:31:57PM +, Nick Terrell wrote: >>> On Nov 21, 2017, at 8:22 AM, David Sterba wrote: On Wed, Nov 15, 2017 at 08:09:15PM +, Nick Terrell

Re: [PATCHSET v2] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

On 11/29/2017 12:05 PM, Tejun Heo wrote: On Wed, Nov 29, 2017 at 09:03:30AM -0800, Tejun Heo wrote: Hello, On Wed, Nov 29, 2017 at 05:56:08PM +0100, Jan Kara wrote: What has happened with this patch set? No idea. cc'ing Chris directly. Chris, if the patchset looks good, can you please

Re: [PATCH 0/7] retry write on error

On Tue, Nov 28, 2017 at 08:22:36PM +0100, David Sterba wrote: > On Tue, Nov 21, 2017 at 05:35:51PM -0700, Liu Bo wrote: > > If the underlying protocal doesn't support retry and there are some > > transient errors happening somewhere in our IO stack, we'd like to > > give an extra chance for IO.

Re: [PATCH v2 05/11] writeback: convert the flexible prop stuff to bytes

On Wed 22-11-17 16:16:00, Josef Bacik wrote: > From: Josef Bacik > > The flexible proportions were all page based, but now that we are doing > metadata writeout that can be smaller or larger than page size we need > to account for this in bytes instead of number of pages. > >

Re: [PATCHSET v2] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

On Wed, Nov 29, 2017 at 09:03:30AM -0800, Tejun Heo wrote: > Hello, > > On Wed, Nov 29, 2017 at 05:56:08PM +0100, Jan Kara wrote: > > What has happened with this patch set? > > No idea. cc'ing Chris directly. Chris, if the patchset looks good, > can you please route them through the btrfs

Re: [PATCH v2 03/11] lib: make the fprop batch size a multiple of PAGE_SIZE

On Wed 22-11-17 16:15:58, Josef Bacik wrote: > From: Josef Bacik > > We are converting the writeback counters to use bytes instead of pages, > so we need to make the batch size for the percpu modifications align > properly with the new units. Since we used pages before, just

Re: [PATCH v2 04/11] lib: add a __fprop_add_percpu_max

On Wed 22-11-17 16:15:59, Josef Bacik wrote: > From: Josef Bacik > > This helper allows us to add an arbitrary amount to the fprop > structures. > > Signed-off-by: Josef Bacik Looks good to me. You can add: Reviewed-by: Jan Kara

Re: [PATCHSET v2] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

Hello, On Wed, Nov 29, 2017 at 05:56:08PM +0100, Jan Kara wrote: > What has happened with this patch set? No idea. cc'ing Chris directly. Chris, if the patchset looks good, can you please route them through the btrfs tree? Thanks. -- tejun -- To unsubscribe from this list: send the line

Re: [PATCH v2 02/11] writeback: convert WB_WRITTEN/WB_DIRITED counters to bytes

On Wed 22-11-17 16:15:57, Josef Bacik wrote: > From: Josef Bacik > > These are counters that constantly go up in order to do bandwidth > calculations. > It isn't important what the units are in, as long as they are consistent > between > the two of them, so convert them to count

Re: [PATCH v7 1/5] add infrastructure for tagging functions as error injectable

On 11/28/2017 09:02 PM, Josef Bacik wrote: > On Tue, Nov 28, 2017 at 11:58:41AM -0700, Jonathan Corbet wrote: >> On Wed, 22 Nov 2017 16:23:30 -0500 >> Josef Bacik wrote: >>> From: Josef Bacik >>> >>> Using BPF we can override kprob'ed functions and return

Re: [PATCHSET v2] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

Hi Tejun, What has happened with this patch set? Honza On Tue 10-10-17 08:54:36, Tejun Heo wrote: > Changes from the last version are > > * blkcg_root_css exported to fix build breakage on modular btrfs. > > * Use ext4_should_journal_data() test instead of > EXT4_MOUNT_JOURNAL_DATA. > > *

Re: [PATCH 0/7] retry write on error

On Wed, Nov 29, 2017 at 12:09:29PM +0800, Anand Jain wrote: > On 11/29/2017 07:41 AM, p...@btrfs.list.sabi.co.uk wrote: > If the underlying protocal doesn't support retry and there > are some transient errors happening somewhere in our IO > stack, we'd like to give an extra chance

Re: [PATCH 4/4] btrfs: factor __btrfs_open_devices() to create btrfs_open_one_device()

Hi Anand, Applied your fix, now the issue resolved. thanks! Cheers, Lakshmipathi.G http://www.giis.co.in http://www.webminal.org On Mon, Nov 27, 2017 at 5:17 PM, Anand Jain wrote: > > Hi Lakshmipathi, > > Oops I can see the same. I am trying to narrow down. > >

[PATCH 1/2] btrfs-progs: convert: Fix a bug in rollback check which overwrite return value

Commit 1170ac307900 ("btrfs-progs: convert: Introduce function to check if convert image is able to be rolled back") reworked rollback check condition, by checking 1:1 mapping of each file extent. The idea itself has nothing wrong, but error handler is not implemented correctly, which over writes

[PATCH 2/2] btrfs-progs: tests/convert: Introduce test case to ensure btrfs-convert won't rollback the filesystem after balance

Signed-off-by: Qu Wenruo --- .../015-not-to-rollback-after-balance/test.sh | 33 ++ 1 file changed, 33 insertions(+) create mode 100755 tests/convert-tests/015-not-to-rollback-after-balance/test.sh diff --git

Re: A partially failing disk in raid0 needs replacement

Hi list Can anyone give me any hints here? If not, my plan right now is to start updating the server to latest debian stable (it's currently running Jessie), to get access to a newer btrfs driver and tools, hoping that decreases the risk of something screwing up, and then run btrfs check --repair

Re: Read before you deploy btrfs + zstd

On 2017-11-28 18:49, David Sterba wrote: On Tue, Nov 28, 2017 at 09:31:57PM +, Nick Terrell wrote: On Nov 21, 2017, at 8:22 AM, David Sterba wrote: On Wed, Nov 15, 2017 at 08:09:15PM +, Nick Terrell wrote: On 11/15/17, 6:41 AM, "David Sterba"

Re: [PATCH] btrfs: drop btrfs_device::can_discard to query directly

On 29.11.2017 12:53, Anand Jain wrote: > We can query the bdev directly when needed at btrfs_discard_extent() > so drop btrfs_device::can_discard. > > Signed-off-by: Anand Jain > Suggested-by: Nikolay Borisov Reviewed-by: Nikolay Borisov

Re: How about adding an ioctl to convert a directory to a subvolume?

On Tue, Nov 28, 2017 at 07:48:28PM +0100, David Sterba wrote: >On Mon, Nov 27, 2017 at 05:41:56PM +0800, Lu Fengqi wrote: >> As we all know, under certain circumstances, it is more appropriate to >> create some subvolumes rather than keep everything in the same >> subvolume. As the condition of

Re: [PATCH 4/4] btrfs: cleanup device states define BTRFS_DEV_STATE_CAN_DISCARD

On 11/29/2017 05:39 PM, Nikolay Borisov wrote: On 29.11.2017 06:45, Anand Jain wrote: Currently device state is being managed by each individual int variable such as struct btrfs_device::can_discard. Instead of that declare btrfs_device::dev_state BTRFS_DEV_STATE_CAN_DISCARD and use the bit

[PATCH] btrfs: drop btrfs_device::can_discard to query directly

We can query the bdev directly when needed at btrfs_discard_extent() so drop btrfs_device::can_discard. Signed-off-by: Anand Jain Suggested-by: Nikolay Borisov --- fs/btrfs/extent-tree.c | 5 - fs/btrfs/volumes.c | 8

Re: [PATCH 1/4] btrfs: cleanup device states define BTRFS_DEV_STATE_WRITEABLE

On 11/29/2017 05:14 PM, Nikolay Borisov wrote: On 29.11.2017 06:45, Anand Jain wrote: Currently device state is being managed by each individual int variable such as struct btrfs_device::writeable. Instead of that declare device state BTRFS_DEV_STATE_WRITEABLE and use the bit operations.

Re: [PATCH 4/4] btrfs: cleanup device states define BTRFS_DEV_STATE_CAN_DISCARD

On 29.11.2017 06:45, Anand Jain wrote: > Currently device state is being managed by each individual int > variable such as struct btrfs_device::can_discard. Instead of that > declare btrfs_device::dev_state BTRFS_DEV_STATE_CAN_DISCARD and use > the bit operations. > > Signed-off-by: Anand Jain

Re: [PATCH 3/4] btrfs: cleanup device states define BTRFS_DEV_STATE_MISSING

On 29.11.2017 06:45, Anand Jain wrote: > Currently device state is being managed by each individual int > variable such as struct btrfs_device::missing. Instead of that > declare btrfs_device::dev_state BTRFS_DEV_STATE_MISSING and use > the bit operations. > > Signed-off-by: Anand Jain

Re: [PATCH 2/4] btrfs: cleanup device states define BTRFS_DEV_STATE_IN_FS_METADATA

On 29.11.2017 06:45, Anand Jain wrote: > Currently device state is being managed by each individual int > variable such as struct btrfs_device::in_fs_metadata. Instead of > that declare device state BTRFS_DEV_STATE_IN_FS_METADATA and use > the bit operations. > > Signed-off-by: Anand Jain

[PATCH 9/9] btrfs-progs: tests/mkfs: Introduce test case to verify if mkfs.btrfs rootdir shrink behaves correctly

Signed-off-by: Qu Wenruo --- tests/mkfs-tests/012-rootdir-no-shrink/test.sh | 38 ++ 1 file changed, 38 insertions(+) create mode 100755 tests/mkfs-tests/012-rootdir-no-shrink/test.sh diff --git a/tests/mkfs-tests/012-rootdir-no-shrink/test.sh

[PATCH 4/9] btrfs-progs: mkfs/rootdir: Shrink fs for rootdir option

Use the new dev extent based shrink method for rootdir option. Signed-off-by: Qu Wenruo --- mkfs/main.c| 5 +++ mkfs/rootdir.c | 111 + mkfs/rootdir.h | 1 + 3 files changed, 117 insertions(+) diff --git

[PATCH 8/9] btrfs-progs: mkfs: Use the whole file or block device to mkfs for rootdir

For --rootdir, even for large existing file or block device, it will always shrink the result filesystem. The problem is, mkfs.btrfs will try to calculate the dir size, and use it as @block_count to mkfs, which makes the result filesystem shrinked. Fix by trying to get the original block device

[PATCH 2/9] btrfs-progs: mkfs: Don't use custom chunk allocator for rootdir

Remove these custom chunk allocator for mkfs. Use generic btrfs chunk allocator instead. Signed-off-by: Qu Wenruo --- mkfs/main.c | 62 - 1 file changed, 62 deletions(-) diff --git a/mkfs/main.c b/mkfs/main.c index

[PATCH 3/9] btrfs-progs: mkfs/rootdir: Use over-reserve method to make size estimate easier

Use an easier method to calculate the estimate device for mkfs.btrfs --rootdir. The new method will over-estimate, but should ensure we won't encounter ENOSPC. It relies on the following data to estimate: 1) number of inodes for metadata chunk size 2) rounded up data size of each regular

[PATCH 5/9] btrfs-progs: mkfs: Separate shrink from rootdir

Make --shrink a separate option for --rootdir, and make it default to off. So this will cause less confusion. Signed-off-by: Qu Wenruo --- Documentation/mkfs.btrfs.asciidoc | 11 +++ mkfs/main.c | 26 -- mkfs/rootdir.c

[PATCH 7/9] btrfs-progs: tests/mkfs: Introduce test case to check if mkfs rootdir can create new file

To test regression 460e93f25754 ("btrfs-progs: mkfs: check the status of file at mkfs"). Signed-off-by: Qu Wenruo --- tests/mkfs-tests/011-rootdir-create-file/test.sh | 14 ++ 1 file changed, 14 insertions(+) create mode 100755

[PATCH 6/9] btrfs-progs: mkfs: Fix regression preventing --rootdir to create file

Commit 460e93f25754 ("btrfs-progs: mkfs: check the status of file at mkfs") will try to check the file state before creating fs on it. The check is mostly fine for normal mkfs case, while for --rootdir option, it's allowed to create new file if destination file doesn't exist. Fix it by allowing

[PATCH 1/9] btrfs-progs: mkfs: Cleanup temporary chunks before filling rootdir

Cleanup those temporary chunks should be as soon as possible, and it should be especially before doing large tree operations, like filling rootdir. Signed-off-by: Qu Wenruo --- mkfs/main.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git

[PATCH 0/9] Remaining part of mkfs --rootdir rework

Can be fetched from my github repo: https://github.com/adam900710/btrfs-progs/tree/mkfs_rootdir_rework Based on the following commit head of David's devel branch: -- commit af322ba5aa1dd0b2a3422e1c4acd8082948efa7b (david/devel) Author: Su Yue Date: Tue Nov 28

Re: [PATCH 1/4] btrfs: cleanup device states define BTRFS_DEV_STATE_WRITEABLE

On 29.11.2017 06:45, Anand Jain wrote: > Currently device state is being managed by each individual int > variable such as struct btrfs_device::writeable. Instead of that > declare device state BTRFS_DEV_STATE_WRITEABLE and use the > bit operations. > > Signed-off-by: Anand Jain