[added Josef]
Josef: Please queue this patch for rc2, we finally agreed.
On Fri, August 03, 2012 at 05:20 (+0200), Liu Bo wrote:
> On 08/02/2012 10:28 PM, Jan Schmidt wrote:
>> If such a situation doesn't exist, there's no need for this flag. The fact
>> that
>> ext has such a flag doesn't convi
On 08/02/2012 10:28 PM, Jan Schmidt wrote:
> On Thu, August 02, 2012 at 15:46 (+0200), Arne Jansen wrote:
>> On 02.08.2012 13:57, Liu Bo wrote:
>>> Anyway, for now, our error flag has only been stored in memory, so what
>>> about just keep it until we find a graceful way?
>>
>> Yeah, we need this p
On Thu, 2 Aug 2012 13:46:31 +0200, David Sterba wrote:
> Hi,
>
> appologies for late reply,
>
> On Thu, Aug 02, 2012 at 12:40:46PM +0800, Miao Xie wrote:
>> Changelog v1 -> v2:
>> - add comment to explain why we need deal with the delayed items after
>> snapshot creation and why this operation
We got a recursive lock in mksubvol because the caller already held
a lock. I think we got into this due to a merge error. Commit a874a63
removed the mnt_want_write call from btrfs_mksubvol and added a
replacement call to mnt_want_write_file in btrfs_ioctl_snap_create_transid.
Commit e7848683 howev
On Fri, Aug 3, 2012 at 12:16 AM, David Sterba wrote:
> Hi,
>
> top commit (v3.5-9237) fc6bdb59a501740b28ed3b616641a22c8dc5dd31, observed with
> btrfs-next/master as well.
>
> mount:
> /dev/sdb on /mnt/sdb type btrfs (rw,relatime,space_cache)
>
> fresh mkfs, snapshot stresstest, stuck on first snap
Hi,
top commit (v3.5-9237) fc6bdb59a501740b28ed3b616641a22c8dc5dd31, observed with
btrfs-next/master as well.
mount:
/dev/sdb on /mnt/sdb type btrfs (rw,relatime,space_cache)
fresh mkfs, snapshot stresstest, stuck on first snapshot call afaics
[ 113.751610]
On Thu, Aug 02, 2012 at 11:21:51PM +0200, Martin Steigerwald wrote:
> > Yep, my du -sh tests do show that ext4 is 2x faster than btrfs.
> > Obviously it's sending IO in a way that either the IO subsystem, linux
> > driver, or drive prefer.
>
> But only on reads.
Yes. I was focussing on the simple
Am Donnerstag, 2. August 2012 schrieb Marc MERLIN:
> On Thu, Aug 02, 2012 at 10:20:07PM +0200, Martin Steigerwald wrote:
> > Hey, whats this? With Ext4 you have really good random read performance
> > now! Way better than the Intel SSD 320 and…
>
> Yep, my du -sh tests do show that ext4 is 2x fast
On Thu, Aug 02, 2012 at 10:20:07PM +0200, Martin Steigerwald wrote:
> Hey, whats this? With Ext4 you have really good random read performance
> now! Way better than the Intel SSD 320 and…
Yep, my du -sh tests do show that ext4 is 2x faster than btrfs.
Obviously it's sending IO in a way that either
Am Donnerstag, 2. August 2012 schrieb Marc MERLIN:
> On Thu, Aug 02, 2012 at 01:18:07PM +0200, Martin Steigerwald wrote:
> > > I've the the fio tests in:
> > > /dev/mapper/cryptroot /var btrfs
> > > rw,noatime,compress=lzo,nossd,discard,space_cache 0 0
> >
> > … you are still using dm_crypt?
[…]
On Thu, Aug 02, 2012 at 01:18:07PM +0200, Martin Steigerwald wrote:
> > I've the the fio tests in:
> > /dev/mapper/cryptroot /var btrfs
> > rw,noatime,compress=lzo,nossd,discard,space_cache 0 0
>
> … you are still using dm_crypt?
That was my biggest partition and so far I've found no performanc
On 02/08/2012 15:53, David Sterba wrote:
On Thu, Aug 02, 2012 at 03:41:03PM +0200, Olivier Bonvalet wrote:
Yes... it's a copy from my /var/log/kern.log. Is it really "disabled" ?
I was mistaken, it really is enabled unconditionally in ctree.h:55.
Josef says that the V0 extent refs are not used
On Thu, Aug 2, 2012 at 7:46 AM, Arne Jansen wrote:
> On 02.08.2012 13:57, Liu Bo wrote:
>> On 08/02/2012 07:40 PM, Arne Jansen wrote:
>>> On 02.08.2012 13:34, Liu Bo wrote:
On 08/02/2012 07:18 PM, Arne Jansen wrote:
> On 02.08.2012 12:36, Liu Bo wrote:
>> On 08/02/2012 06:30 PM, Stefa
On Thu, August 02, 2012 at 15:46 (+0200), Arne Jansen wrote:
> On 02.08.2012 13:57, Liu Bo wrote:
>> Anyway, for now, our error flag has only been stored in memory, so what
>> about just keep it until we find a graceful way?
>
> Yeah, we need this patch to restore consistency. We can define a fixe
On Thu, Aug 02, 2012 at 03:40:03PM +0200, David Sterba wrote:
> On Tue, Jul 31, 2012 at 06:01:04PM -0700, Marc MERLIN wrote:
> > On Tue, Jul 31, 2012 at 11:04:12AM -0700, Marc MERLIN wrote:
> > > My kernel crashed for some other reason, and now I can't mount my btrfs
> > > filesystem.
> > > I don't
When we close devices we add back empty devices for some reason that escapes
me. In the case of a missing dev we don't allocate an rcu_string for it's
name, so check to see if the device has a name and if it doesn't don't
bother strdup()'ing it. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/
If you do the following
mkfs.btrfs /dev/sdb /dev/sdc
rmmod btrfs
dd if=/dev/zero of=/dev/sdb bs=1M count=1
mount -o degraded /dev/sdc /mnt/btrfs-test
the box will panic trying to deref the name for the missing dev since it is
the lower numbered devid. So fix show_devname to not use missing devic
On 02.08.2012 15:57, David Sterba wrote:
> On Thu, Aug 02, 2012 at 03:46:50PM +0200, Arne Jansen wrote:
>>> Anyway, for now, our error flag has only been stored in memory, so what
>>> about just keep it until we find a graceful way?
>>
>> Yeah, we need this patch to restore consistency. We can defi
On Thu, Aug 02, 2012 at 03:46:50PM +0200, Arne Jansen wrote:
> > Anyway, for now, our error flag has only been stored in memory, so what
> > about just keep it until we find a graceful way?
>
> Yeah, we need this patch to restore consistency. We can define a fixed
> area on disk (e.g. behind the s
On Thu, Aug 02, 2012 at 03:41:03PM +0200, Olivier Bonvalet wrote:
> Yes... it's a copy from my /var/log/kern.log. Is it really "disabled" ?
I was mistaken, it really is enabled unconditionally in ctree.h:55.
Josef says that the V0 extent refs are not used for a long time, so the
question is how di
On 02.08.2012 13:57, Liu Bo wrote:
> On 08/02/2012 07:40 PM, Arne Jansen wrote:
>> On 02.08.2012 13:34, Liu Bo wrote:
>>> On 08/02/2012 07:18 PM, Arne Jansen wrote:
On 02.08.2012 12:36, Liu Bo wrote:
> On 08/02/2012 06:30 PM, Stefan Behrens wrote:
>> On Wed, 01 Aug 2012 16:31:54 +0200,
On 02/08/2012 15:22, David Sterba wrote:
On Wed, Aug 01, 2012 at 09:48:15PM +0200, Olivier Bonvalet wrote:
I have some trouble with a btrfs filesystem.
As you can see in logs, there is lines which are from btrfs (I
supposed), then some warnings at fs/btrfs/extent-tree.c, and finally a
"kernel BU
On Tue, Jul 31, 2012 at 06:01:04PM -0700, Marc MERLIN wrote:
> On Tue, Jul 31, 2012 at 11:04:12AM -0700, Marc MERLIN wrote:
> > My kernel crashed for some other reason, and now I can't mount my btrfs
> > filesystem.
> > I don't care about the data, it's backed up.
> >
> > I'll compile a 3.5 kernel
We need a barrir before calling waitqueue_active otherwise we will miss
wakeups. So in places that do atomic_dec(); then atomic_read() use
atomic_dec_return() which imply a memory barrier (see memory-barriers.txt)
and then add an explicit memory barrier everywhere else that need them.
Thanks,
Sig
On Wed, Aug 01, 2012 at 09:48:15PM +0200, Olivier Bonvalet wrote:
> I have some trouble with a btrfs filesystem.
> As you can see in logs, there is lines which are from btrfs (I
> supposed), then some warnings at fs/btrfs/extent-tree.c, and finally a
> "kernel BUG" at fs/btrfs/extent-tree.c:5038.
On Thu, Aug 02, 2012 at 08:11:58AM -0400, Josef Bacik wrote:
> On Thu, Aug 02, 2012 at 04:46:44AM -0600, Liu Bo wrote:
> > On 08/02/2012 04:25 AM, Josef Bacik wrote:
> > > We need an smb_mb() before waitqueue_active to avoid missing wakeups.
> > > Before Mitch was hitting a deadlock between the ord
On Thu, Aug 2, 2012 at 4:46 AM, Liu Bo wrote:
> On 08/02/2012 04:25 AM, Josef Bacik wrote:
>> We need an smb_mb() before waitqueue_active to avoid missing wakeups.
>> Before Mitch was hitting a deadlock between the ordered flushers and the
>> transaction commit because the ordered flushers were wa
On Thu, Aug 02, 2012 at 04:46:44AM -0600, Liu Bo wrote:
> On 08/02/2012 04:25 AM, Josef Bacik wrote:
> > We need an smb_mb() before waitqueue_active to avoid missing wakeups.
> > Before Mitch was hitting a deadlock between the ordered flushers and the
> > transaction commit because the ordered flus
On Wed, Aug 01, 2012 at 10:29:21PM -0600, Miao Xie wrote:
> On Thu, 2 Aug 2012 10:31:23 +0800, Fengguang Wu wrote:
> > There are new compile warnings show up in
> >
> > tree: git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
> > master
> > head: 8e1163044779e90662e96887cdd692
On 08/02/2012 07:40 PM, Arne Jansen wrote:
> On 02.08.2012 13:34, Liu Bo wrote:
>> On 08/02/2012 07:18 PM, Arne Jansen wrote:
>>> On 02.08.2012 12:36, Liu Bo wrote:
On 08/02/2012 06:30 PM, Stefan Behrens wrote:
> On Wed, 01 Aug 2012 16:31:54 +0200, Stefan Behrens wrote:
>> On Wed, 01 A
Hi,
appologies for late reply,
On Thu, Aug 02, 2012 at 12:40:46PM +0800, Miao Xie wrote:
> Changelog v1 -> v2:
> - add comment to explain why we need deal with the delayed items after
> snapshot creation and why this operation do not corrupt the metadata.
I'm sorry, the comment did not fix the
On 02.08.2012 13:34, Liu Bo wrote:
> On 08/02/2012 07:18 PM, Arne Jansen wrote:
>> On 02.08.2012 12:36, Liu Bo wrote:
>>> On 08/02/2012 06:30 PM, Stefan Behrens wrote:
On Wed, 01 Aug 2012 16:31:54 +0200, Stefan Behrens wrote:
> On Wed, 01 Aug 2012 21:31:58 +0800, Liu Bo wrote:
>> On 08
On 08/02/2012 07:18 PM, Arne Jansen wrote:
> On 02.08.2012 12:36, Liu Bo wrote:
>> On 08/02/2012 06:30 PM, Stefan Behrens wrote:
>>> On Wed, 01 Aug 2012 16:31:54 +0200, Stefan Behrens wrote:
On Wed, 01 Aug 2012 21:31:58 +0800, Liu Bo wrote:
> On 08/01/2012 09:07 PM, Jan Schmidt wrote:
Am Donnerstag, 2. August 2012 schrieb Marc MERLIN:
> So, doctor, is it bad? :)
>
> randomwrite: (g=0): rw=randwrite, bs=2K-16K/2K-16K, ioengine=libaio,
> iodepth=64
> sequentialwrite: (g=1): rw=write, bs=2K-16K/2K-16K, ioengine=libaio,
> iodepth=64
> randomread: (g=2): rw=randread, bs=2K-16K/2K-
Am Donnerstag, 2. August 2012 schrieb Marc MERLIN:
> On Wed, Aug 01, 2012 at 11:57:39PM +0200, Martin Steigerwald wrote:
> > Its getting quite strange.
>
> I would agree :)
>
> Before I paste a bunch of thing, I wanted to thank you for not giving up on
> me
> and offering your time to help me
On 02.08.2012 12:36, Liu Bo wrote:
> On 08/02/2012 06:30 PM, Stefan Behrens wrote:
>> On Wed, 01 Aug 2012 16:31:54 +0200, Stefan Behrens wrote:
>>> On Wed, 01 Aug 2012 21:31:58 +0800, Liu Bo wrote:
On 08/01/2012 09:07 PM, Jan Schmidt wrote:
> On Wed, August 01, 2012 at 14:02 (+0200), Liu B
On 08/02/2012 04:25 AM, Josef Bacik wrote:
> We need an smb_mb() before waitqueue_active to avoid missing wakeups.
> Before Mitch was hitting a deadlock between the ordered flushers and the
> transaction commit because the ordered flushers were waiting for more refs
> and were never woken up, so th
On 08/02/2012 06:30 PM, Stefan Behrens wrote:
> On Wed, 01 Aug 2012 16:31:54 +0200, Stefan Behrens wrote:
>> On Wed, 01 Aug 2012 21:31:58 +0800, Liu Bo wrote:
>>> On 08/01/2012 09:07 PM, Jan Schmidt wrote:
On Wed, August 01, 2012 at 14:02 (+0200), Liu Bo wrote:
> On 08/01/2012 07:45 PM, St
On Wed, 01 Aug 2012 16:31:54 +0200, Stefan Behrens wrote:
> On Wed, 01 Aug 2012 21:31:58 +0800, Liu Bo wrote:
>> On 08/01/2012 09:07 PM, Jan Schmidt wrote:
>>> On Wed, August 01, 2012 at 14:02 (+0200), Liu Bo wrote:
On 08/01/2012 07:45 PM, Stefan Behrens wrote:
> With commit acce952b0, btr
From: Chen Yang
This patch adds the function to check correspondence between block group,
chunk and device extent.
Signed-off-by: Cheng Yang
Signed-off-by: Miao Xie
---
Makefile |2 +-
btrfsck.c | 569 +++-
dev-extent-cac
From: Zhou Bo
This patch enhances btrfs subvol list to show read-only snapshots.
You can use the -r option showing read-only snapshots, for example:
btrfs subvolume list -r
Signed-off-by: Zhou Bo
---
btrfs-list.c | 68 +++--
cmds-subvolume
On Thu, Aug 2, 2012 at 11:55 AM, Alexander Block
wrote:
> Hello Chris,
>
> You can find and pull a lot of fixes for btrfs send/receive in my git repo:
>
> git://github.com/ablock84/linux-btrfs.git for-chris
>
> These fixes are mostly the results of the reviews from Arne and Alex
> that I g
Hello Chris,
You can find and pull a lot of fixes for btrfs send/receive in my git repo:
git://github.com/ablock84/linux-btrfs.git for-chris
These fixes are mostly the results of the reviews from Arne and Alex
that I got here on the list. I'm not posting the patches to the list
at the mo
Liu Bo,
I am trying to resolve a conflict with your patch vs Hugo'
integration branch
http://git.darksatanic.net/repo/btrfs-progs-unstable.git
(integration-20120605)
---
@@ -185,11 +199,15 @@ static int add_root(struct root_lookup *root_lookup,
ri->dir_id = dir_id;
ri-
44 matches
Mail list logo
