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 btrfs
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 aw
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
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
mismatc
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 n
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 _any_ error retur
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: device label FSgyroA devid
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 both links for
file
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 directories with multipl
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
> luc
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 enabled, a user can cr
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 us
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 f
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 of
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.
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.
Here is the btrfs-image btw:
https://dl.dropboxusercontent.com/u/19330332/image.bt
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 now change
>> this BUG_ON int
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 follow
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 jumps to the goto
> label, out
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 er
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 t
On Wed, Apr 6, 2016 at 4:46 AM, Bastien Philbert
wrote:
> Greetings All,
> After some tracing I am not certain if this is correct due to being newer to
> the btrfs
> codebase. However if someone more experience can show me if I am missing
> something in
> my traces please let me known:)
> Firstl
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 definition are parity based, so I'd say no that
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
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 btrfs_qgroup_accounting_extents() is
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
> example:
>
> $
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
> inside btrfs_commit_transactio
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 device name is displaye
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 volume?
29 matches
Mail list logo
