Re: [PATCH] fstests: common: Make _test_mount to include MOUNT_OPTIONS to allow consistent _test_cycle_mount

At 05/24/2017 01:08 PM, Eryu Guan wrote: On Wed, May 24, 2017 at 12:28:34PM +0800, Qu Wenruo wrote: At 05/24/2017 12:24 PM, Eryu Guan wrote: On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote: At 05/23/2017 07:13 PM, Eryu Guan wrote: On Tue, May 23, 2017 at 04:02:05PM +0800, Qu

Re: [PATCH] fstests: common: Make _test_mount to include MOUNT_OPTIONS to allow consistent _test_cycle_mount

On Wed, May 24, 2017 at 12:28:34PM +0800, Qu Wenruo wrote: > > > At 05/24/2017 12:24 PM, Eryu Guan wrote: > > On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote: > > > > > > > > > At 05/23/2017 07:13 PM, Eryu Guan wrote: > > > > On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote:

Re: [PATCH] fstests: common: Make _test_mount to include MOUNT_OPTIONS to allow consistent _test_cycle_mount

At 05/24/2017 12:24 PM, Eryu Guan wrote: On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote: At 05/23/2017 07:13 PM, Eryu Guan wrote: On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote: [BUG] If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142 generic/143 and

Re: [PATCH] fstests: common: Make _test_mount to include MOUNT_OPTIONS to allow consistent _test_cycle_mount

On Wed, May 24, 2017 at 08:22:25AM +0800, Qu Wenruo wrote: > > > At 05/23/2017 07:13 PM, Eryu Guan wrote: > > On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote: > > > [BUG] > > > If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142 > > > generic/143 and generic/154, it will

Re: BTRFS converted from EXT4 becomes read-only after reboot

24.05.2017 00:49, Marc MERLIN пишет: > On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote: >>> I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it >>> never worked properly any of those times, sadly. >> >> Since the 4.6 total rewrite? There are also recent bug fixes

Re: [PATCH v3 00/19] Btrfs-progs offline scrub

> > Only recovery needs to be implemented now. > > Thanks, > Qu > Once recovery is implemented, I'll try again. Just one suggestion: Optionally, It is possible to print filename for these detected blocks. For ex, if corruption happened on a old/unwanted archived log file

Re: [PATCH v5] qgroup: Retry after commit on getting EDQUOT

At 03/28/2017 02:13 AM, Goldwyn Rodrigues wrote: On 03/27/2017 12:36 PM, David Sterba wrote: On Mon, Mar 27, 2017 at 12:29:57PM -0500, Goldwyn Rodrigues wrote: From: Goldwyn Rodrigues We are facing the same problem with EDQUOT which was experienced with ENOSPC. Not

[PATCH] btrfs: add compression trace points

This patch adds compression and decompression trace points for the purpose of debugging. Signed-off-by: Anand Jain --- Note: I have used same trace function for both compress and decompress as I wanted to maintain compress and decompress debug data aligned.

[PATCH] btrfs: btrfs_decompress_bio() could accept compressed_bio instead

Instead of sending each argument of struct compressed_bio, send the compressed_bio itself. Also by having struct compressed_bio in btrfs_decompress_bio() it would help tracing. Signed-off-by: Anand Jain --- This patch is preparatory for the up coming patch btrfs: add

[PATCH] btrfs: tree-log.c: Wrong printk information about namelen

In verify_dir_item, it wants to printk name_len of dir_item but printk data_len acutally. Fix it by calling btrfs_dir_name_len instead of btrfs_dir_data_len. Signed-off-by: Su Yue --- fs/btrfs/dir-item.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] fstests: common: Make _test_mount to include MOUNT_OPTIONS to allow consistent _test_cycle_mount

At 05/23/2017 07:13 PM, Eryu Guan wrote: On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote: [BUG] If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142 generic/143 and generic/154, it will cause false alert like: cp: failed to clone '/mnt/test/test-154/file2' from

Re: BTRFS converted from EXT4 becomes read-only after reboot

On Tue, May 23, 2017 at 02:53:21PM -0700, Marc MERLIN wrote: > On Tue, May 23, 2017 at 03:51:43PM -0600, Chris Murphy wrote: > > On Tue, May 23, 2017 at 3:49 PM, Marc MERLIN wrote: > > > On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote: > > >> > I've tried an ext4 to

Re: BTRFS converted from EXT4 becomes read-only after reboot

On Tue, May 23, 2017 at 03:51:43PM -0600, Chris Murphy wrote: > On Tue, May 23, 2017 at 3:49 PM, Marc MERLIN wrote: > > On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote: > >> > I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it > >> > never worked

Re: BTRFS converted from EXT4 becomes read-only after reboot

On Tue, May 23, 2017 at 02:49:43PM -0700, Marc MERLIN wrote: > On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote: > > > I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it > > > never worked properly any of those times, sadly. > > > > Since the 4.6 total rewrite?

Re: BTRFS converted from EXT4 becomes read-only after reboot

On Tue, May 23, 2017 at 3:49 PM, Marc MERLIN wrote: > On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote: >> > I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it >> > never worked properly any of those times, sadly. >> >> Since the 4.6 total

Re: BTRFS converted from EXT4 becomes read-only after reboot

On Tue, May 23, 2017 at 03:38:01PM -0600, Chris Murphy wrote: > > I've tried an ext4 to btrfs conversion 3 times in the last 3 years, it > > never worked properly any of those times, sadly. > > Since the 4.6 total rewrite? There are also recent bug fixes related > to convert in the changelog, it

Re: BTRFS converted from EXT4 becomes read-only after reboot

On Tue, May 23, 2017 at 11:00 AM, Marc MERLIN wrote: > On Thu, May 04, 2017 at 03:55:28AM +, Duncan wrote: >> > But that alone may not fix it, I think you need a newer kernel... >> >> Well, while the 4.4 LTS kernel series /is/ getting a bit long in the >> tooth by now, it's

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

Am Tue, 23 May 2017 07:21:33 -0400 schrieb "Austin S. Hemmelgarn" : > On 2017-05-22 22:07, Chris Murphy wrote: > > On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN > > wrote: > >> On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote: > [...] >

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Mon, May 22, 2017 at 09:19:34AM +, Duncan wrote: > btrfs check is userspace, not kernelspace. The btrfs-transacti threads That was my understanding, yes, but since I got it to starve my system, including in kernel OOM issues I pasted in my last message and just referenced in

Re: BTRFS converted from EXT4 becomes read-only after reboot

On Thu, May 04, 2017 at 03:55:28AM +, Duncan wrote: > > But that alone may not fix it, I think you need a newer kernel... > > Well, while the 4.4 LTS kernel series /is/ getting a bit long in the > tooth by now, it's still the second newest LTS series available, 4.9 > being the newest. > >

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

On Tue, May 02, 2017 at 05:01:02AM +, Duncan wrote: > Marc MERLIN posted on Mon, 01 May 2017 20:23:46 -0700 as excerpted: > > > Also, how is --mode=lowmem being useful? > > FWIW, I just watched your talk that's linked from the wiki, and wondered > what you were doing these days as I hadn't

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On Tue, May 23, 2017 at 07:21:33AM -0400, Austin S. Hemmelgarn wrote: > > Yeah although I have no idea how much swap is needed for it to > > succeed. I'm not sure what the relationship is to fs metadata chunk > > size to btrfs check RAM requirement is; but if it wants all of the > > metadata in

Re: [PATCH v3 00/19] Btrfs-progs offline scrub

Okay, I did multiple (upto 11) corruption on the same file. Seems like it says 'CORRUPTED' when we corrupt two continuous data stripes and reports 'RECOVERABLE' whenever possible.It looks fine. You can find the logs and test-scripts on below link. thanks.

Re: 4.11.1: cannot btrfs check --repair a filesystem, causes heavy memory stalls

On 2017-05-22 22:07, Chris Murphy wrote: On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN wrote: On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote: On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote: I already have 24GB of RAM in that machine,

Re: [PATCH] fstests: common: Make _test_mount to include MOUNT_OPTIONS to allow consistent _test_cycle_mount

On Tue, May 23, 2017 at 04:02:05PM +0800, Qu Wenruo wrote: > [BUG] > If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142 > generic/143 and generic/154, it will cause false alert like: > cp: failed to clone '/mnt/test/test-154/file2' from > '/mnt/test/test-154/file1': Invalid

Re: [PATCH] Btrfs: skip commit transaction if we don't have enough pinned bytes

On 19.05.2017 20:39, Liu Bo wrote: > We commit transaction in order to reclaim space from pinned bytes because > it could process delayed refs, and in may_commit_transaction(), we check > first if pinned bytes are enough for the required space, we then check if > that plus bytes reserved for

[PATCH] fstests: common: Make _test_mount to include MOUNT_OPTIONS to allow consistent _test_cycle_mount

[BUG] If using MOUNT_OPTIONS="-o nodatasum" and btrfs to run genierc/142 generic/143 and generic/154, it will cause false alert like: cp: failed to clone '/mnt/test/test-154/file2' from '/mnt/test/test-154/file1': Invalid argument [REASON] It is caused by _test_cycle_mount function, which

Re: QGroups Semantics

Hit "Send" a little too early: More complete workaround would be delayed cleanup. What about (re-)mount time? (Should also handle qgroups remaining ... after subvolumes deleted on previous kernels.) -- With Best Regards, Marat Khalili On 23/05/17 08:38, Marat Khalili wrote: Just some

Re: [PATCH 7/8] btrfs: Add code to prevent qgroup creation for a non-existent subvol

-Dhillon/BtrFS-QGroups-uapi-improvements/20170523-111746 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) include/linux/compiler.h:264:8: sparse: attribute 'no_sanitize_a

Re: [PATCH v2 2/2] Btrfs: compression must free at least PAGE_SIZE

-pr_debug-deflate-lzo/20170523-110651 config: x86_64-kexec (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): fs/btrfs/lzo.c: In fu