[PATCH 1/3] btrfs-progs: test: umount if confirmation failed

When a check in check_inode() failed, the test should umount test target file system. This commit add clean up umount line in failure path. Signed-off-by: Naohiro Aota --- tests/fsck-tests/012-leaf-corruption/test.sh | 4 1 file changed, 4 insertions(+) diff --git

[PATCH 2/3] btrfs-progs: properly reset nlink of multi-linked file

If a file is linked from more than one directory and only one of the links is corrupted, btrfs check dose not reset the nlink properly. Actually it can go into infinite loop to link the broken file into lost+found. This patch fix two part of the code. The first one delay the freeing valid (no

Linux 4.3 call traces for defective disk

I have a defect disk which produced kernel backtraces like (see below). Are you interested in them, what else do you need to know, do you prefer things inline or as attachments? unmodified Linux 4.3 tainted with nvidia driver disk:WDC WD2002FYPS-02W3B0 196 Reallocated_Event_Count 0x0032 200

[PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

This series address an issue of btrfsck to restore infinite number of same file into `lost+found' directory. The issue occur on a file which is linked from two different directory A and B. If links from dir A is corrupted and links from dir B is kept valid, btrfsck won't stop creating a file in

Re: Bug/regression: Read-only mount not read-only

On 2015-12-02 18:40, Qu Wenruo wrote: On 12/03/2015 06:48 AM, Eric Sandeen wrote: On 12/2/15 11:48 AM, Austin S Hemmelgarn wrote: On a side note, do either XFS or ext4 support removing the norecovery option from the mount flags through mount -o remount? Even if they don't, that might be a

3.16.0 Debian kernel hang

One of my test laptops started hanging on mounting the root filesystem. I think that it had experience an unexpected power outage prior to that which may have caused corruption. When I tried to mount the root filesystem the mount process would stick in D state, there would be no disk IO, and

Subvolume UUID, data corruption?

Hello As we know, two file systems with the same UUID (like reported by eg. "blkid") are problematic, especially if both are mounted at the same time it leads to data corruption. So, copying a BTRFS partition with eg. dd to another and use it immediately is bad. To prevent this, "btrfstune -u

Re: btrfs crashing the kernel with Seagate 8TB SMR drives.

As Chris mentioned, check out the Bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=93581 I have a 8TB SMR Drive and the kernel was reporting drive errors. Switching to Kernel 3.16 (Standard Debian Jessie kernel) fixed it for me ( for the moment). >From what I read in that kernel bug

Re: compression disk space saving - what are your results?

On 2015-12-03 01:29, Duncan wrote: Austin S Hemmelgarn posted on Wed, 02 Dec 2015 09:39:08 -0500 as excerpted: On 2015-12-02 09:03, Imran Geriskovan wrote: What are your disk space savings when using btrfs with compression? [Some] posters have reported that for mostly text, compress didn't

Re: 3.16.0 Debian kernel hang

On 2015-12-04 05:00, Russell Coker wrote: One of my test laptops started hanging on mounting the root filesystem. I think that it had experience an unexpected power outage prior to that which may have caused corruption. When I tried to mount the root filesystem the mount process would stick in

Re: 3.16.0 Debian kernel hang

On Sat, 5 Dec 2015 12:53:07 AM Austin S Hemmelgarn wrote: > > The only reason I'm not running Unstable kernels on my Debian systems is > > because I run some Xen servers and upgrading Xen is problemmatic. Linode > > is moving from Xen to KVM so I guess I should consider doing the > > same. If I

Re: compression disk space saving - what are your results?

On 2015-12-03 07:09, Imran Geriskovan wrote: On a side note, I really wish BTRFS would just add LZ4 support. It's a lot more deterministic WRT decompression time than LZO, gets a similar compression ratio, and runs faster on most processors for both compression and decompression. Relative

Re: Bug/regression: Read-only mount not read-only

On 2015-12-02 18:51, Hugo Mills wrote: On Thu, Dec 03, 2015 at 07:40:08AM +0800, Qu Wenruo wrote: On 12/03/2015 06:48 AM, Eric Sandeen wrote: On 12/2/15 11:48 AM, Austin S Hemmelgarn wrote: On a side note, do either XFS or ext4 support removing the norecovery option from the mount flags

Re: BUG: failure at fs/btrfs/ctree.h:337/btrfs_chunk_item_size()!

On Fri, Dec 04, 2015 at 09:21:59AM +0800, Qu Wenruo wrote: > > We do have the alignment check in kernel, but it's in the early phase > > where we don't know if nodesize is reliable and print only a warning. > > > This can be enhanced by the following method: At minimum, we can promote the 4k

Re: [PATCH] Btrfs: disable online scrub repair on ro cases

Hi Liu, [auto build test ERROR on btrfs/next] [also build test ERROR on v4.4-rc3 next-20151203] url: https://github.com/0day-ci/linux/commits/Liu-Bo/Btrfs-disable-online-scrub-repair-on-ro-cases/20151204-205115 base: https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git

Re: 3.16.0 Debian kernel hang

On Sat, 5 Dec 2015 12:08:58 AM Austin S Hemmelgarn wrote: > > I know that there are no plans to backport things to 3.16 and I don't > > think the Debian people are going to be very interested in this. So > > this message is a FYI for users, maybe consider not using the > > Debian/Jessie kernel

Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

On Fri, Dec 04, 2015 at 10:08:35AM +0800, Qu Wenruo wrote: > Liu Bo wrote on 2015/12/03 17:44 -0800: > > On Mon, Nov 23, 2015 at 06:56:09PM +0100, David Sterba wrote: > >> On Mon, Nov 23, 2015 at 08:56:13PM +0800, Anand Jain wrote: > >>> Btrfs-progs is a tool for the btrfs kernel and we hope

Re: [PATCH 04/12] btrfs: change how delay_iput is tracked in btrfs_delalloc_work

On Thu, Dec 03, 2015 at 06:25:37PM -0800, Liu Bo wrote: > > struct inode *inode; > > - int delay_iput; > > struct completion completion; > > struct list_head list; > > struct btrfs_work work; > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > > index

Re: Very various speed of grep operation on btrfs partition

On 2015-12-03 14:36, Михаил Гаврилов wrote: Today on work I needed searching some strings in repository. Only machine with windows was available. I am was using grep from Cygwin for this task and I am was surprised about speed of NTFS partition.I decided to repeat this task on my home Linux

Re: [PATCH] Btrfs: disable online scrub repair on ro cases

Hi Liu, [auto build test WARNING on btrfs/next] [also build test WARNING on v4.4-rc3 next-20151203] url: https://github.com/0day-ci/linux/commits/Liu-Bo/Btrfs-disable-online-scrub-repair-on-ro-cases/20151204-205115 base: https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git

Re: [PATCH 04/12] btrfs: change how delay_iput is tracked in btrfs_delalloc_work

On 12/04/15 13:36, David Sterba wrote: [snip] > As the use of the inode pointer is limited, I don't think this would > cause surprises. And it's commented where used which should help during > debugging. When I read through those bits (mostly pondering portability) I was wondering whether it

Re: Subvolume UUID, data corruption?

On Fri, Dec 04, 2015 at 01:05:28PM +0100, S.J wrote: > Hello > > As we know, two file systems with the same UUID (like reported by eg. > "blkid") are problematic, especially if both are mounted at the same time it > leads to data corruption. So, copying a BTRFS partition with eg. dd to >

Re: 3.16.0 Debian kernel hang

On 2015-12-04 08:42, Russell Coker wrote: On Sat, 5 Dec 2015 12:08:58 AM Austin S Hemmelgarn wrote: I know that there are no plans to backport things to 3.16 and I don't think the Debian people are going to be very interested in this. So this message is a FYI for users, maybe consider not

Re: btrfs crashing the kernel with Seagate 8TB SMR drives.

I did suspect that NCQ may be involved, but I had no clear evidence - until I noticed that my drives had also incremented the 'end to end error' count in SMART, which does match accounts of the NCQ issue. That suggests there are two interlinked issues: The issue with those Seagate drives and

Re: 3.16.0 Debian kernel hang

On 2015-12-04 09:26, Russell Coker wrote: On Sat, 5 Dec 2015 12:53:07 AM Austin S Hemmelgarn wrote: The only reason I'm not running Unstable kernels on my Debian systems is because I run some Xen servers and upgrading Xen is problemmatic. Linode is moving from Xen to KVM so I guess I should

Re: [PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

On 12/04/2015 01:37 PM, Naohiro Aota wrote: This series address an issue of btrfsck to restore infinite number of same file into `lost+found' directory. The issue occur on a file which is linked from two different directory A and B. If links from dir A is corrupted and links from dir B is kept

Re: Subvolume UUID, data corruption?

On Fri, 2015-12-04 at 13:07 +, Hugo Mills wrote: > I don't think it'll cause problems. Is there any guaranteed behaviour when btrfs encounters two filesystems (i.e. not talking about the subvols now) with the same UUID? Given that it's long standing behaviour that people could clone

Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

David, the possibility of unloaded module that would remove the access to sysfs, as you point out. Kindly note, the patch below made /dev/btrfs-control a static node, - commit 578454ff7eab61d13a26b568f99a89a2c9edc881 Author: Kay Sievers Date: Thu May 20 18:07:20

Re: attacking btrfs filesystems via UUID collisions? (was: Subvolume UUID, data corruption?)

Thinking a bit more I that, I came to the conclusion that it's actually security relevant that btrfs deals gracefully with filesystems having the same UUID: Getting to know someone else's filesystem's UUID may be more easily possible than one may think. It's usually not considered secret and

Re: [PATCH 06/15] btrfs: Cleanup num_tolerated_disk_barrier_failures

Hi Anand, Would you please push patch 1~6 in your hot spare patchset to Chris first? In my opinion, it will need some time before some details like whether to do hot-spare in kernel or in user-space are settled. And all these 6 patches are quite independent from the hot spare patchset. So it

Re: BUG: failure at fs/btrfs/ctree.h:337/btrfs_chunk_item_size()!

On 12/04/2015 09:12 PM, David Sterba wrote: On Fri, Dec 04, 2015 at 09:21:59AM +0800, Qu Wenruo wrote: We do have the alignment check in kernel, but it's in the early phase where we don't know if nodesize is reliable and print only a warning. This can be enhanced by the following method:

[PATCH V2] Btrfs: disable online scrub repair on ro cases

This disables repair process on ro cases as it can cause system to be unresponsive on the ASSERT() in repair_io_failure(). This can happen when scrub is running and a hardware error pops up, we should fallback to ro mounts gracefully instead of being unresponsive. Reported-by: Codebird

Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

On Fri, Dec 04, 2015 at 11:57:55AM +0800, Qu Wenruo wrote: > > > Liu Bo wrote on 2015/12/03 18:53 -0800: > >On Fri, Dec 04, 2015 at 10:08:35AM +0800, Qu Wenruo wrote: > >> > >> > >>Liu Bo wrote on 2015/12/03 17:44 -0800: > >>>On Mon, Nov 23, 2015 at 06:56:09PM +0100, David Sterba wrote: > On