Re: [PATCH] btrfs: qgroup: Fix qgroup accounting when creating snapshot

Hi Qu, On Wed, Apr 06, 2016 at 10:04:54AM +0800, Qu Wenruo wrote: > Current btrfs qgroup design implies a requirement that after calling > btrfs_qgroup_account_extents() there must be a commit root switch. > > Normally this is OK, as btrfs_qgroup_accounting_extents() is only called > inside

Re: unable to mount btrfs pool even with -oro,recovery,degraded, unable to do 'btrfs restore'

Ank Ular posted on Wed, 06 Apr 2016 18:08:53 -0400 as excerpted: > I did read this page: https://btrfs.wiki.kernel.org/index.php/Restore > > But, not understanding the meaning of much of the terminology, I didn't > "get it". > > Your explanation makes the page much clearer. Yeah. It took me

btrfs BUGs

Dear all, (please Cc) since 4.6.0-rc I see regular BUG in btrfs_destroy_inode: Variant 1: [47093.775175] [ cut here ] [47093.775187] WARNING: CPU: 3 PID: 19909 at fs/btrfs/inode.c:9261 btrfs_destroy_inode+0xad/0x224 [47093.775189] Modules linked in: hmac drbg ansi_cprng

Volume stuck after Checking UUID tree

The drive mounts perfectly fine when you mount RO, but when you mount it rw it gives this (and eventually locks up the system as I can't restart it cleanly): kernel: BTRFS info (device sdb1): disk space caching is enabled Apr 06 17:09:16 kernel: BTRFS error (device sdb1): qgroup generation

Re: scrub: Tree block spanning stripes, ignored

Ivan P wrote on 2016/04/06 21:39 +0200: Ok, I'm cautiously optimistic: after running btrfsck --init-extent-tree --repair and running scrub, it finished without errors. Will run a file compare against my backup copy, but it seems the repair was successful. Better run btrfsck again, to ensure

Re: [PATCH] btrfs: test snapshot create with invalid parent qgroup

On Wed, Apr 06, 2016 at 10:40:02PM +0100, Filipe Manana wrote: > On Wed, Apr 6, 2016 at 10:30 PM, Mark Fasheh wrote: > > Test that an invalid parent qgroup does not cause snapshot create to > > force the FS readonly. > > > > In btrfs, create_pending_snapshot() will go readonly on

Re: unable to mount btrfs pool even with -oro,recovery,degraded, unable to do 'btrfs restore'

On Wed, Apr 6, 2016 at 9:34 AM, Ank Ular wrote: > > From the ouput of 'dmesg', the section: > [ 20.998071] BTRFS: device label FSgyroA devid 9 transid 625039 /dev/sdm > [ 20.84] BTRFS: device label FSgyroA devid 10 transid 625039 /dev/sdn > [ 21.004127] BTRFS:

[PATCH] fstests: generic test for fsync after adding a link and moving other inode

From: Filipe Manana Test that if we create a hard link for a file F in some directory A, then move some directory or file B from its parent directory C into directory A, fsync file F, power fail and mount the filesystem, the directory/file B is located only at directory A and

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

From: Filipe Manana If we move a directory to a new parent and later log that parent and don't explicitly log the old parent, when we replay the log we can end up with entries for the moved directory in both the old and new parent directories. Besides being ilegal to have

Re: unable to mount btrfs pool even with -oro,recovery,degraded, unable to do 'btrfs restore'

On Wed, Apr 6, 2016 at 5:02 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Ank Ular posted on Wed, 06 Apr 2016 11:34:39 -0400 as excerpted: > >> I am currently unable to mount nor recover data from my btrfs storage >> pool. >> > With four devices behind by (fortunately only) 26 transactions, and >

Re: [PATCH] btrfs: test snapshot create with invalid parent qgroup

On Wed, Apr 6, 2016 at 10:30 PM, Mark Fasheh wrote: > Test that an invalid parent qgroup does not cause snapshot create to > force the FS readonly. > > In btrfs, create_pending_snapshot() will go readonly on _any_ error return > from > btrfs_qgroup_inherit(). If qgroups are

Re: [PATCH] btrfs: test snapshot create with invalid parent qgroup

On Wed, Apr 06, 2016 at 02:30:34PM -0700, Mark Fasheh wrote: > Test that an invalid parent qgroup does not cause snapshot create to > force the FS readonly. > > In btrfs, create_pending_snapshot() will go readonly on _any_ error return > from > btrfs_qgroup_inherit(). If qgroups are enabled, a

[PATCH] btrfs: test snapshot create with invalid parent qgroup

Test that an invalid parent qgroup does not cause snapshot create to force the FS readonly. In btrfs, create_pending_snapshot() will go readonly on _any_ error return from btrfs_qgroup_inherit(). If qgroups are enabled, a user can crash their fs by just making a snapshot and asking it to inherit

Re: unable to mount btrfs pool even with -oro,recovery,degraded, unable to do 'btrfs restore'

Ank Ular posted on Wed, 06 Apr 2016 11:34:39 -0400 as excerpted: > I am currently unable to mount nor recover data from my btrfs storage > pool. > > To the best of my knowledge, the situation did not arise from hard disk > failure. I believe the sequence of events is: > > One or possibly more

Re: [PATCH] btrfs: handle non-fatal errors in btrfs_qgroup_inherit()

On Wed, Apr 06, 2016 at 10:22:57AM +0100, Filipe Manana wrote: > Mark, did you forgot to submit a patch with the test case for fstests, > or is there any other reason why you didn't do it? No, I was just waiting to see how my fix did in review. I'll be shooting that test over later today.

Re: [PATCH] btrfs:Change BUG_ON to new error path in __clear_extent_bit

On 2016-04-06 12:10 PM, Filipe Manana wrote: > On Wed, Apr 6, 2016 at 4:56 PM, Bastien Philbert > wrote: >> This remove the unnessary BUG_ON if the allocation with >> alloc_extent_state_atomic fails due to this function >> failure not being unrecoverable. Instead we

'btrfs filesystem df /mnt/point/of/btrfs/pool' can report misleadingly

When the mount point for a btrfs pool resides on an existing independent btrfs pool and the first btrfs pool is not mounted, running 'btrfs fi df /unmounted/pool' will show the btrfs df information of the underlying mounted btrfs pool. This is most likely undesirable. The btrfs wiki has the

Re: [PATCH] btrfs:Change BUG_ON to new error path in __clear_extent_bit

On Wed, Apr 6, 2016 at 4:56 PM, Bastien Philbert wrote: > This remove the unnessary BUG_ON if the allocation with > alloc_extent_state_atomic fails due to this function > failure not being unrecoverable. Instead we now change > this BUG_ON into a new error path that

[PATCH] btrfs:Change BUG_ON to new error path in __clear_extent_bit

This remove the unnessary BUG_ON if the allocation with alloc_extent_state_atomic fails due to this function failure not being unrecoverable. Instead we now change this BUG_ON into a new error path that jumps to the goto label, out from freeing previously allocated resources before returning the

unable to mount btrfs pool even with -oro,recovery,degraded, unable to do 'btrfs restore'

I am currently unable to mount nor recover data from my btrfs storage pool. To the best of my knowledge, the situation did not arise from hard disk failure. I believe the sequence of events is: One or possibly more of my external devices had the USB 3.0 communications link fail. I recall seeing

Re: dstat shows unexpected result for two disk RAID1

On 2016-04-05 23:58, Nicholas D Steeves wrote: On 11 March 2016 at 20:20, Chris Murphy wrote: On Fri, Mar 11, 2016 at 5:10 PM, Nicholas D Steeves wrote: P.S. Rather than parity, I mean instead of distributing into stripes, do a copy! raid56 by

Re: [PATCH] [RFC] fix potential access after free: return value of blk_check_plugged() must be used schedule() safe

On Wed, Apr 06, 2016 at 01:10:57PM +1000, NeilBrown wrote: > On Wed, Apr 06 2016, Shaohua Li wrote: > > > On Tue, Apr 05, 2016 at 03:36:57PM +0200, Lars Ellenberg wrote: > >> blk_check_plugged() will return a pointer > >> to an object linked on current->plug->cb_list. > >> > >> That list may "at

Re: [PATCH] btrfs: qgroup: Fix qgroup accounting when creating snapshot

Filipe Manana wrote on 2016/04/06 10:20 +0100: On Wed, Apr 6, 2016 at 3:04 AM, Qu Wenruo wrote: Current btrfs qgroup design implies a requirement that after calling btrfs_qgroup_account_extents() there must be a commit root switch. Normally this is OK, as

Re: [PATCH] btrfs: handle non-fatal errors in btrfs_qgroup_inherit()

On Thu, Mar 31, 2016 at 1:57 AM, Mark Fasheh wrote: > create_pending_snapshot() will go readonly on _any_ error return from > btrfs_qgroup_inherit(). If qgroups are enabled, a user can crash their fs by > just making a snapshot and asking it to inherit from an invalid qgroup. For

Re: [PATCH] btrfs: qgroup: Fix qgroup accounting when creating snapshot

On Wed, Apr 6, 2016 at 3:04 AM, Qu Wenruo wrote: > Current btrfs qgroup design implies a requirement that after calling > btrfs_qgroup_account_extents() there must be a commit root switch. > > Normally this is OK, as btrfs_qgroup_accounting_extents() is only called >

Re: [PATCH] Btrfs: fix missing s_id setting

Am Tue, 5 Apr 2016 17:52:40 +0900 schrieb Tsutomu Itoh : > On 2016/04/05 16:56, Anand Jain wrote: > > On 04/05/2016 08:08 AM, Tsutomu Itoh wrote: > >> When fs_devices->latest_bdev is deleted or is replaced, sb->s_id > >> has not been updated. > >> As a result, the deleted

Re: [PATCH 2/2] btrfs: do not write corrupted metadata blocks to disk

Nicholas D Steeves posted on Wed, 06 Apr 2016 00:04:36 -0400 as excerpted: > Ah, that's exactly what I was looking for! Thank you. It took forever, > and brought me back to what it was like to fsck large ext2 volumes. Is > btrfs check conceptually identical to a read-only fsck of a ext2