On 2014/06/20 8:21, Waiman Long wrote:
On 06/19/2014 05:50 PM, Chris Mason wrote:
I would like to take back my comments. I took out the read_lock, but the
process still hang while doing file activities on btrfs filesystem. So
the problem is trickier than I thought. Below are the stack backtrace
Btrfs has global block reservation, so even mkfs.btrfs can execute
without problem, there is still a possibility that the filesystem can't
be mounted.
For example when mkfs.btrfs on a 8M file on x86_64 platform, kernel will
refuse to mount due to ENOSPC, since system block group takes 4M and
mixed
On Thu, Jun 19, 2014 at 03:50:16PM -0700, Josef Bacik wrote:
> Ok same drill as before, reset and apply this, hopefully no panic this time
>
>
> diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
> index 65245a0..bca5240 100644
Here's the output
BTRFS info (device sdb1): disk space cachi
On 06/19/2014 02:50 PM, Tamas Papp wrote:
On 06/16/2014 04:02 PM, Tamas Papp wrote:
On 06/16/2014 03:26 PM, Tamas Papp wrote:
hi All,
There is a Dell XPS 13 laptop with and SSD.
System:
Ubuntu 14.04 amd64
Kernel is from the daily ppa, like 3.15rcX.
Now, it's running live system:
Linux ub
Hi David,
(2014/06/19 22:28), David Sterba wrote:
On Thu, Jun 19, 2014 at 10:10:55AM +0900, Satoru Takeuchi wrote:
It's fixed at 430d275a399.
===
commit 430d275a399175c7c0673459738979287ec1fd22
Author: Peter Lund
Date
On 06/19/2014 05:50 PM, Chris Mason wrote:
I would like to take back my comments. I took out the read_lock, but the
process still hang while doing file activities on btrfs filesystem. So
the problem is trickier than I thought. Below are the stack backtraces
of some of the relevant processes.
Y
On 06/19/2014 04:16 PM, Mark Fasheh wrote:
Thanks for the review Josef, I will implement everything you mentioned. I
have one question below though:
On Thu, Jun 19, 2014 at 03:25:12PM -0700, Josef Bacik wrote:
On 06/19/2014 02:49 PM, Mark Fasheh wrote:
diff --git a/fs/btrfs/extent-tree.c b/f
Thanks for the review Josef, I will implement everything you mentioned. I
have one question below though:
On Thu, Jun 19, 2014 at 03:25:12PM -0700, Josef Bacik wrote:
> On 06/19/2014 02:49 PM, Mark Fasheh wrote:
>> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
>> index 46f39bf..672d
On 06/19/2014 03:25 PM, Marc MERLIN wrote:
On Thu, Jun 19, 2014 at 09:12:13AM -0700, Josef Bacik wrote:
Ok undo what you did and apply this and re-run. It is going spit out a
metric
shittone of data, but all I want is the last chunk of stuff between
running build_backref_tree
block wasn't
On Thu, Jun 19, 2014 at 09:12:13AM -0700, Josef Bacik wrote:
> Ok undo what you did and apply this and re-run. It is going spit out a
> metric
> shittone of data, but all I want is the last chunk of stuff between
>
> running build_backref_tree
>
> block wasn't checked
> done building backref t
On 06/19/2014 02:49 PM, Mark Fasheh wrote:
During it's tree walk, btrfs_drop_snapshot() will skip any shared
subtrees it encounters. This is incorrect when we have qgroups
turned on as those subtrees need to have their contents
accounted. In particular, the case we're concerned with is when
remov
On 06/19/2014 02:49 PM, Mark Fasheh wrote:
We want this to debug qgroup changes on live systems.
Signed-off-by: Mark Fasheh
---
Reviewed-by: Josef Bacik
Thanks,
Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kern
During it's tree walk, btrfs_drop_snapshot() will skip any shared
subtrees it encounters. This is incorrect when we have qgroups
turned on as those subtrees need to have their contents
accounted. In particular, the case we're concerned with is when
removing our snapshot root leaves the subtree with
We want this to debug qgroup changes on live systems.
Signed-off-by: Mark Fasheh
---
fs/btrfs/qgroup.c| 3 +++
fs/btrfs/super.c | 1 +
include/trace/events/btrfs.h | 56
3 files changed, 60 insertions(+)
diff --git a/fs/btrf
Hi, the following patches try to fix a long outstanding issue with qgroups
and snapshot deletion. The core problem is that btrfs_drop_snapshot will
skip shared extents during it's tree walk. This results in an inconsistent
qgroup state once the drop is processed.
The first patch adds some tracing
On 06/16/2014 04:02 PM, Tamas Papp wrote:
On 06/16/2014 03:26 PM, Tamas Papp wrote:
hi All,
There is a Dell XPS 13 laptop with and SSD.
System:
Ubuntu 14.04 amd64
Kernel is from the daily ppa, like 3.15rcX.
Now, it's running live system:
Linux ubuntu 3.13.0-24-generic #46-Ubuntu SMP Thu A
On 06/19/2014 04:10 PM, Chris Mason wrote:
> On 06/19/2014 01:52 PM, Waiman Long wrote:
>> On 06/19/2014 12:51 PM, Chris Mason wrote:
>>> On 06/18/2014 11:21 PM, Waiman Long wrote:
On 06/18/2014 10:11 PM, Chris Mason wrote:
> On 06/18/2014 10:03 PM, Marc Dionne wrote:
>> On Wed, Jun 18
On 06/19/2014 01:52 PM, Waiman Long wrote:
> On 06/19/2014 12:51 PM, Chris Mason wrote:
>> On 06/18/2014 11:21 PM, Waiman Long wrote:
>>> On 06/18/2014 10:11 PM, Chris Mason wrote:
On 06/18/2014 10:03 PM, Marc Dionne wrote:
> On Wed, Jun 18, 2014 at 8:41 PM, Marc
> Dionne wrote:
I have a few questions about the BTRFS_IOC_FILE_EXTENT_SAME ioctl, and
was hoping that I could get answers here without having to go source
diving or trying to test things myself:
1. What kind of overhead is there when it is called on a group of
extents that aren't actually the same (aside from th
On 06/19/2014 12:51 PM, Chris Mason wrote:
On 06/18/2014 11:21 PM, Waiman Long wrote:
On 06/18/2014 10:11 PM, Chris Mason wrote:
On 06/18/2014 10:03 PM, Marc Dionne wrote:
On Wed, Jun 18, 2014 at 8:41 PM, Marc
Dionne wrote:
On Wed, Jun 18, 2014 at 8:08 PM, Waiman Long
wrote:
On 06/18/2014
On Jun 19, 2014, at 2:56 AM, Konstantinos Skarlatos
wrote:
>
> My filesystem that consistently kernel panics when a specific logical address
> is read, passes scrub without anything bad reported. What's the use of scrub
> if it cant deal with this?
The myriad repair tools: automatic at mount
On 06/18/2014 11:21 PM, Waiman Long wrote:
> On 06/18/2014 10:11 PM, Chris Mason wrote:
>> On 06/18/2014 10:03 PM, Marc Dionne wrote:
>>> On Wed, Jun 18, 2014 at 8:41 PM, Marc
>>> Dionne wrote:
On Wed, Jun 18, 2014 at 8:08 PM, Waiman Long
wrote:
> On 06/18/2014 08:03 PM, Marc Dionne
On 06/18/2014 01:21 PM, Marc MERLIN wrote:
First thanks for your answer and patch. While they didn't help, I'm happy to
try another one or two if you'd like before I wipe the FS to recover.
On Wed, Jun 18, 2014 at 08:26:46AM -0700, Josef Bacik wrote:
2) is your guess that the BUG_ON I'm getti
Duncan posted on Thu, 19 Jun 2014 15:06:00 + as excerpted:
> Scrub detects (and potentially fixes) exactly one sort of problem (tho
> that one can definitely cause others), and that's not it.
Hmm. Last phrase was ambiguous.
What I meant was, that problem (your problem) is not the sort of pro
On Wed, Jun 18, 2014 at 09:22:50PM +, Duncan wrote:
> Tho at least in Marc's case, he's running kernels a couple back in some
> cases and they may still have BUGONs already replaced in the most current
> kernel.
The machine I originally has that one last bug on (balance crash) was an
ubuntu
Konstantinos Skarlatos posted on Thu, 19 Jun 2014 11:56:59 +0300 as
excerpted:
> Thats good to hear. But we should have a way to recover from these kinds
> of problems, first of all having btrfs report the exact location, disk
> and file name that is affected, and then make scrub fix or at least
>
On Thu, Jun 19, 2014 at 10:10:55AM +0900, Satoru Takeuchi wrote:
> It's fixed at 430d275a399.
>
> ===
> commit 430d275a399175c7c0673459738979287ec1fd22
> Author: Peter Lund
> Date: Tue Oct 16 23:29:35 2007 -0700
>
>
On Thu, Jun 19, 2014 at 08:43:36AM +0100, WorMzy Tykashi wrote:
> > You're right, sorry. The file was not added after a conflict with
> > git-am and I did not check afterwards. Local build test passed.
> > Updated integration pushed, though it's a bit reduced. The 'next'
> > sub-branch rebase had s
On Fri, Apr 25, 2014 at 10:14 PM, Hugo Mills wrote:
> On Fri, Apr 25, 2014 at 02:12:17PM -0400, Austin S Hemmelgarn wrote:
>> On 2014-04-25 13:24, Chris Murphy wrote:
>> >
>> > On Apr 25, 2014, at 8:57 AM, Steve Leung wrote:
>> >
>> >>
>> >> Hi list,
>> >>
>> >> I've got a 3-device RAID1 btrfs fi
On 2014-06-18 16:10, Chris Murphy wrote:
>
> On Jun 18, 2014, at 1:29 PM, Daniel Cegiełka
> wrote:
>
>> Hi,
>> I created btrfs directly to disk using such a scheme (no partitions):
>>
>> dd if=/dev/zero of=/dev/sda bs=4096
>> mkfs.btrfs -L dev_sda /dev/sda
>> mount /dev/sda /mnt
>>
>> cd /mnt
>
On Thu, 19 Jun 2014 06:47:27 -0400
Zack Coffey wrote:
> I tried to create a simple RAID1 for metadata and somehow lost access
> to everything on the drive. The RAID1 for just metadata created just
> fine, everything was fine for a day, so I turned off the drive that
> was just holding the RAID1 o
I am not sure this is related with the other reports for lockups etc on
3.16-rc1, so i am sending it. full dmesg attached. this is after some
heavy io on a multi disk btrfs filesystem.
[69932.966704] INFO: task btrfs-transacti:516 blocked for more than 120
seconds.
[69932.966837] Not ta
Hi Josef,
thanks for the detailed description of how the extent tree works!
When I was digging through that in the past, I made some slides to
remember all the call chains. Maybe somebody finds that useful to
accompany your notes.
https://drive.google.com/file/d/0ByBy89zr3kJNNmM5OG5wXzQ3LUE/edit?us
On Thu, Jun 19, 2014 at 10:42:54AM +0800, Miao Xie wrote:
> The deadlock happened when we mount degraded filesystem, the reproduced
> steps are following:
> # mkfs.btrfs -f -m raid1 -d raid1
> # echo 1 > /sys/block/`basename `/device/delete
> # mount -o degraded
>
> The reason was that the
On 6/19/14, Russell Coker wrote:
> On Wed, 18 Jun 2014 21:29:39 Daniel Cegiełka wrote:
>> Everything works fine. Is such a solution is recommended? In my
>> opinion, the creation of the partitions seems to be completely
>> unnecessary if you can use btrfs.
> If you don't need to have a boot loade
On 6/19/14, Russell Coker wrote:
> On Wed, 18 Jun 2014 21:29:39 Daniel Cegiełka wrote:
>> Everything works fine. Is such a solution is recommended? In my
>> opinion, the creation of the partitions seems to be completely
>> unnecessary if you can use btrfs.
> If you don't need to have a boot loade
On 19/6/2014 12:22 πμ, Duncan wrote:
Konstantinos Skarlatos posted on Wed, 18 Jun 2014 16:23:04 +0300 as
excerpted:
I guess that btrfs developers have put these BUG_ONs so that they get
reports from users when btrfs gets in these unexpected situations. But
if most of these reports are ignored o
On 19 June 2014 00:05, David Sterba wrote:
> On Wed, Jun 18, 2014 at 09:59:50PM +0100, WorMzy Tykashi wrote:
>> I think you forgot to apply the patch that adds
>> Documentation/btrfs-mount.5.txt before you tagged
>> integration-20140618, man5 (and consequently Documentation) can't be
>> made witho
38 matches
Mail list logo
