Re: I'd like a -r flag on btrfs subvolume delete

On Thu, Jul 16, 2015 at 01:12:03PM +1000, Paul Harvey wrote: > On 16 July 2015 at 11:35, Chris Murphy wrote: > > On Wed, Jul 15, 2015 at 6:11 PM, Johannes Ernst > > wrote: > > > >> Cleaning this all up is a bit of pain, and > >> btrfs subvolume delete -r dir > >> would solve it nicely. >

[PATCH] btrfs: Show detail information when mount failed on missing devices

From: Zhao Lei When mount failed because missing device, we can see following dmesg: [ 1060.267743] BTRFS: too many missing devices, writeable mount is not allowed [ 1060.273158] BTRFS: open_ctree failed This patch add missing_device_number and tolerated_missing_device_number to above output,

[PATCH] btrfs: Cleanup for btrfs_calc_num_tolerated_disk_barrier_failures()

From: Zhao Lei 1: Use ARRAY_SIZE(types) to replace a static-value variant: int num_types = 4; 2: Use 'continue' on condition to reduce one level tab if (!XXX) { code; ... } -> if (XXX) continue; code; ... 3: Put setting 'num_tolerated_disk_barrier_failu

[PATCH] Btrfs: fix stale directory entries after fsync log replay

From: Filipe Manana We have another case where after an fsync log replay we get an inode with a wrong link count (smaller than it should be) and a number of directory entries greater than its link count. This happens when we add a new link hard link to our inode A and then we fsync some other ino

[PATCH] fstests: generic test for fsync after adding hard links

From: Filipe Manana Test that if we add hard links (in the same directory) to two files and then fsync only one of the files, after the fsync log/journal is replayed all the links exist and the filesystem metadata (directory and file inodes) is in a consistent state. This test is motivated by a

Re: [PATCH] fstests: generic test for fsync after adding hard links

On Wed, Jul 15, 2015 at 11:59:27PM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > Test that if we add hard links (in the same directory) to two files and > then fsync only one of the files, after the fsync log/journal is replayed > all the links exist and the filesystem metadata (dir

Re: [PATCH] btrfs: Fix lockdep warning of btrfs_run_delayed_iputs()

On Wed, Jul 15, 2015 at 11:48:14AM +0800, Zhaolei wrote: > From: Zhao Lei > > Liu Bo reported a lockdep warning of > delayed_iput_sem in xfstests generic/241: > [ 2061.345955] = > [ 2061.346027] [ INFO: possible recursive locking detected ] > [ 2

Re: BTRFS raid6 unmountable after a couple of days of usage.

On 2015-07-15 17:29, Chris Murphy wrote: On Wed, Jul 15, 2015 at 10:15 AM, Hugo Mills wrote: There is at least one superblock on every device, usually two, and often three. Each superblock contains the virtual address of the roots of the root tree, the chunk tree and the log tree. Those ar

Re: BTRFS raid6 unmountable after a couple of days of usage.

On 2015-07-14 07:49, Austin S Hemmelgarn wrote: So, after experiencing this same issue multiple times (on almost a dozen different kernel versions since 4.0) and ruling out the possibility of it being caused by my hardware (or at least, the RAM, SATA controller and disk drives themselves), I'v

[PATCH] btrfs: Add raid56 support for updating num_tolerated_disk_barrier_failures in btrfs_balance()

From: Zhao Lei Code for updating fs_info->num_tolerated_disk_barrier_failures in btrfs_balance() lacks raid56 support. Reason: Above code was wroten in 2012-08-01, together with btrfs_calc_num_tolerated_disk_barrier_failures()'s first version. Then, btrfs_calc_num_tolerated_disk_barrier_fail

Re: I'd like a -r flag on btrfs subvolume delete

On 16 July 2015 at 17:59, Hugo Mills wrote: > On Thu, Jul 16, 2015 at 01:12:03PM +1000, Paul Harvey wrote: >> I for one would love to see authoritative documentation on "proper" >> subvolume organization. I was completely lost when writing snazzer and >> have so far received very little guidance o

Re: I'd like a -r flag on btrfs subvolume delete

On Thu, Jul 16, 2015 at 4:06 AM, Paul Harvey wrote: > On Thu, 16 Jul 2015 17:59 Hugo Mills wrote: > > >> >> On Thu, Jul 16, 2015 at 01:12:03PM +1000, Paul Harvey wrote: >> > On 16 July 2015 at 11:35, Chris Murphy wrote: >> > > On Wed, Jul 15, 2015 at 6:11 PM, Johannes Ernst >> > > wrote: >> > >

Strange data backref offset?

Hi all, While I'm developing a new btrfs inband dedup mechanism, I found btrfsck and kernel doing strange behavior for clone. [Reproducer] # mount /dev/sdc -t btrfs /mnt/test # dd if=/dev/zero of=/mnt/test/file1 bs=4K count=4 # sync # ~/xfstests/src/cloner -s 4096 -l 4096 /mnt/test/file1 /mnt/

Re: [PATCH] Btrfs: incremental send, fix clone operations for compressed extents

On Sun, May 3, 2015 at 2:56 AM, Filipe Manana wrote: > Marc reported a problem where the receiving end of an incremental send > was performing clone operations that failed with -EINVAL. This happened > because, unlike for uncompressed extents, we were not checking if the > source clone offset and

[PATCH] generic/311: Disable dmesg check

When running generic/311 on Btrfs' subpagesize-blocksize patchset (on ppc64 with 4k sectorsize and 16k node/leaf size) I noticed the following call trace, BTRFS (device dm-0): parent transid verify failed on 29720576 wanted 160 found 158 BTRFS (device dm-0): parent transid verify failed on 297205