On 10/26/2011 03:34 PM, David Sterba wrote:
Hi,
sorry for late reply. This patch tries to unify node-/leaf-/... sizes
nad put it just into fs_info, but this assumes all trees share the same
sizes. Unfortunatelly this is not true (once we allow big blocks; soon?).
The root tree has a hardcoded s
On 10/26/2011 06:27 PM, Chris Mason wrote:
On Wed, Oct 26, 2011 at 06:23:38PM +0200, David Sterba wrote:
On Wed, Oct 26, 2011 at 04:47:15PM +0200, Arne Jansen wrote:
The sizes get initialized to 4096, but after the super block is read,
these are replaced by those from the SB.
[reads sources
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Right now on-disk BTRFS_BLOCK_GROUP_* profile bits are used for
> avail_{data,metadata,system}_alloc_bits fields, which are there to tell
> us about available allocation profiles in the fs. When chunk is
> created, it's profile is OR'ed with respective av
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Add basic restriper infrastructure: ioctl to start restripe, all
> restripe ioctl data structures, add data structure for tracking
> restriper's state to fs_info. Duplicate balancing code for restriper,
> btrfs_balance() will be removed when restriper is
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Select chunks that are less than X percent full.
>
> Signed-off-by: Ilya Dryomov
> ---
> fs/btrfs/volumes.c | 33 +
> fs/btrfs/volumes.h |1 +
> 2 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/fs
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Introduce a new btree objectid for storing restripe item. The reason is
> to be able to resume restriper after a crash with the same parameters.
> Restripe item has a very high objectid and goes into tree of tree roots.
>
> The key for the new item is as
On 23.08.2011 22:01, Ilya Dryomov wrote:
> On mount, if restripe item is found, resume restripe in a separate
> kernel thread.
>
> Try to be smart to continue roughly where previous balance (or convert)
> was interrupted. For chunk types that were being converted to some
> profile we turn on soft
On 01.11.2011 12:07, David Sterba wrote:
> On Tue, Nov 01, 2011 at 11:08:38AM +0100, Arne Jansen wrote:
>>> +/*
>>> + * Should be called with restripe_mutex held
>>> + */
>>> +int btrfs_restripe(struct restripe_control *rctl)
>>> +{
> ...
&g
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Implement an ioctl for pausing restriper. This pauses the relocation,
> but restripe is still considered to be "in progress": restriper item is
> not deleted, other volume operations cannot be started, etc. If paused
> in the middle of profile changing o
On 11/02/2011 06:41 PM, Helmut Hullen wrote:
> Hallo,
>
> I'd like to get some explanations ...
>
>
> # btrfs filesystem show
>
> Label: 'MMedia' uuid: 120b036a-883f-46aa-bd9a-cb6a1897c8d2
> Total devices 3 FS bytes used 3.80TB
> devid1 size 1.82TB used 1.29TB path /dev/sdg1
>
On 06.11.2011 23:33, Jesper Juhl wrote:
> It seems to me that we may leak the memory allocated to 'multi' in
> scrub_fixup() if, for example, 'length' turns out to be less than
> PAGE_SIZE after we call btrfs_map_block(). This patch should take care
> of the leak by always kfree'ing 'multi' before
On 06.11.2011 20:29, Andrea Gelmini wrote:
> 2011/11/6 Chris Mason :
>
> Hi Chris,
>and thanks a lot for your work.
>
>> Arne Jansen and Jan Schmidt have improved the scrubber and provided
>> utilities to walk btrfs' many backrefs. The scrubber is much fas
On 07.11.2011 10:49, Roman Mamedov wrote:
> On Mon, 07 Nov 2011 10:37:16 +0100
> Arne Jansen wrote:
>
>>>I've got this:
>>>
>>> root@Q45:/home/gelma/dev/prg/btrfs# ./btrfs scrub start -Br /dev/md126
>>> ERROR: scrubbing /dev/md126 failed
Hi Andrea,
On 07.11.2011 13:42, Andrea Gelmini wrote:
> 2011/11/7 Arne Jansen :
>> On what platform are you running this? Can you please try this after
>> a fresh boot? Maybe there's an allocation that can't be served with
>> a badly fragmented memory.
>
> Hi
On 03.11.2011 11:32, Jan Schmidt wrote:
> On 03.11.2011 02:41, Li Zefan wrote:
>> (as this is going to be merged into mainline..)
>>
>>> +/*
>>> + * calls iterate() for every inode that references the extent identified by
>>> + * the given parameters. will use the path given as a parameter and retu
On 07.11.2011 13:50, Andrea Gelmini wrote:
> 2011/11/7 Arne Jansen :
>> is it 32 or 64 bit?
>
> 64bit.
> Please take a look at my other reply.
Can you please have a look with strace to make sure it's
really the ioctl the ENOMEM originates froM?
Thanks,
Arne
>
&g
On 09.11.2011 08:48, Christoph Hellwig wrote:
> On Tue, Nov 08, 2011 at 08:07:01PM -0500, Chris Mason wrote:
>> Looks like bio_add_page() is failing and we're getting the enomem from
>> there. LVM is only letting us put one page in each bio.
>
> Yes, at the moment all bio based DM targets only al
Currently scrub fails with ENOMEM when bio_add_page fails. Unfortunately
dm based targets accept only one page per bio, thus making scrub always
fails. This patch just submits the current bio when an error is encountered
and starts a new one.
Signed-off-by: Arne Jansen
---
fs/btrfs/scrub.c
setup, it should stripe to all 8 devices until the 5 smaller ones
are full, and from then on stripe to the 3 remaining devices.
See commit
commit 73c5de0051533cbdf2bb656586c3eb21a475aa7d
Author: Arne Jansen
Date: Tue Apr 12 12:07:57 2011 +0200
btrfs: quasi-round-robin for chunk allocation
Al
On 17.11.2011 12:53, Thomas Schmidt wrote:
>
>> On 17.11.2011 01:27, Thomas Schmidt wrote:
>> In your setup, it should stripe to all 8 devices until the 5 smaller ones
>> are full, and from then on stripe to the 3 remaining devices.
>
> Afaik the behavior you describe is exactly the problem.
> It
On 11/21/2011 05:15 AM, dima wrote:
> On 11/21/2011 06:50 AM, Karol Šebesta wrote:
>> Hello,
>>
>> Is there any possibility to set quota limit for subvolume created in
>> BTRFS pool as in Solaris ZFS?
>
> Hi
> Quotas are not implemented yet in btrfs as far as I know.
This type of quota is impleme
On 11/21/2011 05:06 PM, Phillip Susi wrote:
> On 7/10/2011 4:21 AM, Arne Jansen wrote:
>> btrfs qgroup limit [--exclusive] |none
>>
>>
>> btrfs qgroup limit 10g /usr
>>
>> That should be simple enough for the common use case.
>
> Wouldn't
[I accidentally failed to include the list in the previous reply]
On 11/21/2011 07:51 PM, Arne Jansen wrote:
> On 11/21/2011 07:29 PM, Phillip Susi wrote:
>> On 11/21/2011 12:20 PM, Arne Jansen wrote:
>>> On 11/21/2011 05:06 PM, Phillip Susi wrote:
>>>> On 7/10/2
On 22.11.2011 04:19, Erik Jensen wrote:
> I have a corrupted multi-device file system that got corrupted ages
> ago (as I recall, one of the drives stopped responding, causing btrfs
> to panic). I am hoping to recover some of the data. For what it's
> worth, here is the dmesg output from trying to
n and feel free to improve it :)
Signed-off-by: Arne Jansen
---
Makefile|3 +
ctree.h |6 +
fragments.c | 480 +++
3 files changed, 489 insertions(+), 0 deletions(-)
create mode 100644 fragments.c
diff --git a/Makefile
devices
(correctly) return ENOTTY. This patch adds this to the error check.
Signed-off-by: Arne Jansen
---
scrub.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scrub.c b/scrub.c
index 9dca5f6..ca7cce7 100644
--- a/scrub.c
+++ b/scrub.c
@@ -987,7 +987,7 @@ static int
block layer provides a non-blocking
submit_bio. Then the whole submit_worker mechanism can be killed.
Signed-off-by: Arne Jansen
---
fs/btrfs/volumes.c | 30 +-
1 files changed, 1 insertions(+), 29 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index
On 29.11.2011 22:47, Chris Mason wrote:
> On Tue, Nov 29, 2011 at 09:40:56PM +0100, Arne Jansen wrote:
>> Write bios are submitted from the submit_worker. The worker pumps down
>> bios into the block layer until it signals a congestion. At least this
>> is the theory. In pr
On 17.11.2011 15:06, Thomas Schmidt wrote:
> Original-Nachricht
>> Datum: Thu, 17 Nov 2011 13:59:26 +0100
>> Von: Arne Jansen
>> An: Thomas Schmidt
>> CC: linux-btrfs@vger.kernel.org
>> Betreff: Re: [RFC] improve space utilization on off-sized
On 26.11.2011 05:14, Phillip Susi wrote:
> On 07/10/2011 04:21 AM, Arne Jansen wrote:
>> Now that I've got a working prototype of subvolume quota, I'd like
>> to get some feedback on the on-disk structure and the commands I
>> intend to use.
>
> I think I&
permanently lost, though it
would be possible to write a tool to recover those lost subvol deletions.
This patch checks if the orphan belongs to a subvol (dead root) and skips
the deletion.
Signed-off-by: Arne Jansen
---
fs/btrfs/inode.c | 32
1 files changed, 32
On 08.12.2011 16:19, Jeremy Sanders wrote:
> Hi - I'm trying out btrfs again, and I see the same old bug in kernel 3.1.4
> (Fedora 16, x86_64, dual-core), where after a few hours of writing, it
> switches from writing with several threads to writing with one:
How many disks does the fs have?
-A
On 17.01.2012 11:02, Miao Xie wrote:
> If there is no free space, the free space allocator will try to get space from
> the block group with the degenerated profile. For example, if there is no free
> space in the RAID1 block groups, the allocator will try to allocate space from
> the DUP block gro
On 21.01.2012 11:49, Martin Steigerwald wrote:
> Am Dienstag, 20. Dezember 2011 schrieb Martin Steigerwald:
>
> When I do btrfs scrub start / the machine locks immediately up hard.
Can you please give me the output of sysrq-w when the machine is locked up?
Thanks,
Arne
>
> Then usually on next
On 24.01.2012 11:16, Martin Steigerwald wrote:
> Am Dienstag, 24. Januar 2012 schrieb Arne Jansen:
>> On 21.01.2012 11:49, Martin Steigerwald wrote:
>>> Am Dienstag, 20. Dezember 2011 schrieb Martin Steigerwald:
>>>
>>> When I do btrfs scrub start / the machine
On 25.01.2012 03:37, Anand Jain wrote:
>
>> The wiki on kernel.org is in read-only mode
>> [1] http://btrfs.ipv5.de/
>
> Is wiki still in read only mode? I am able to login,
> but there isn't any link to create new page ?
>
You mean the wiki mentioned above? You have to confirm
your email ad
.
Reported-and-tested-by: Stefan Behrens
Signed-off-by: Arne Jansen
---
fs/btrfs/scrub.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 9770cc5..abc0fbf 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -1367,7 +1367,8
When inserting into the radix tree returns EEXIST, get the existing
entry without giving up the spinlock in between.
There was a race for both the zones trees and the extent tree.
Signed-off-by: Arne Jansen
---
fs/btrfs/reada.c | 36
1 files changed, 16
Normally when there are 2 copies of a block, we add both to the
reada extent tree and prefetch only the one that is easier to reach.
This way we can better utilize multiple devices.
In case of DUP this makes no sense as both copies reside on the
same device.
Signed-off-by: Arne Jansen
---
fs
Hi Martin,
I just sent 2 patches to the list. Could you please test if these
fix your problem with scrub?
Thanks,
Arne
On 02/24/12 16:51, Martin Steigerwald wrote:
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
I still have th
On 02/25/12 09:33, Duncan wrote:
Arne Jansen posted on Sat, 25 Feb 2012 09:09:47 +0100 as excerpted:
Normally when there are 2 copies of a block, we add both to the reada
extent tree and prefetch only the one that is easier to reach.
This way we can better utilize multiple devices.
In case of
On 05.03.2012 08:07, Fajar A. Nugraha wrote:
> On Mon, Mar 5, 2012 at 1:51 PM, Anand Jain wrote:
>>
>>> (notably the direct modification of
>>> crontab files, which is considered to be an internal detail if I
>>> understand correctly, and I'm fairly certain is broken as written),
>>
>>
>> I did c
On 16.03.2012 16:05, Martin Steigerwald wrote:
>> has an important fix for scrub on 32 bit that should solve this.
>
> So finally - the machine did make-kpkg over night and complained about
> missing Documentation lguest, then I switched off lots from distro default
> config and just did the usua
Hi Anand,
On 21.03.2012 05:03, Anand Jain wrote:
>
> Hi Team,
>
> Could you let me know if you are working on..
>
>Synchronous snapshot delete (or similar)
>
> few requested for this feature, just wanted
> to know if anyone has picked up this and is
> working on it.
I'm not working d
Add the fs-global state and initialization for snapshot deletion
Signed-off-by: Arne Jansen
---
fs/btrfs/ctree.h | 35 +++
fs/btrfs/disk-io.c | 18 ++
2 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs
le at
git://git.kernel.org/pub/scm/linux/kernel/git/arne/linux-btrfs.git droptree
Arne Jansen (5):
btrfs: extend readahead interface
btrfs: add droptree inode
btrfs: droptree structures and initialization
btrfs: droptree implementation
btrfs: use droptree for snapshot deletion
fs/btrf
Update btrfs_clean_old_snapshots to make use of droptree. Snapshots
with old backrefs and snapshots which deletion is always in progress
are deleted with the old code, all other snapshots deletions use
droptree.
Some droptree-related debug code is also added to reada.c.
Signed-off-by: Arne Jansen
truncated to zero.
This patch also exports free_space_cache's io_ctl functions to
droptree and adds functions to store and read u8, u16, u32 and u64
values, as well as byte arrays of arbitrary length.
Signed-off-by: Arne Jansen
---
fs/btrfs/btrfs_inode.h |4 +
fs/btrfs/ct
readaheads to other trees.
Also added is a function to cancel all outstanding requests for a
given readahead and all its sub-readas.
As the interface changes slightly, scrub has been edited to reflect
the changes.
Signed-off-by: Arne Jansen
---
fs/btrfs/ctree.h | 37 -
fs/btrfs/reada.c
description see inline comments.
Signed-off-by: Arne Jansen
---
fs/btrfs/Makefile |2 +-
fs/btrfs/droptree.c | 1916 +++
2 files changed, 1917 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/Makefile b/fs/btrfs/Makefile
index 0c4fa2b..620d7c8
On 13.04.2012 04:53, Tsutomu Itoh wrote:
> Hi, Arne,
>
> (2012/04/13 0:54), Arne Jansen wrote:
>> This is an implementation of snapshot deletion using the readahead
>> framework. Multiple snapshots can be deleted at once and the trees
>> are not enumerated sequentia
On 13.04.2012 05:40, Liu Bo wrote:
> On 04/12/2012 11:54 PM, Arne Jansen wrote:
>> This patchset reimplements snapshot deletion with the help of the readahead
>> framework. For this callbacks are added to the framework. The main idea is
>> to traverse many snapshots at once
On 13.04.2012 09:10, Liu Bo wrote:
> On 04/13/2012 02:53 PM, Arne Jansen wrote:
>
>> On 13.04.2012 05:40, Liu Bo wrote:
>>>> On 04/12/2012 11:54 PM, Arne Jansen wrote:
>>>>>> This patchset reimplements snapshot deletion with the help of the
>>>
On 13.04.2012 09:20, Liu Bo wrote:
> On 04/13/2012 03:10 PM, Liu Bo wrote:
>
>> On 04/13/2012 02:53 PM, Arne Jansen wrote:
>>
>>> On 13.04.2012 05:40, Liu Bo wrote:
>>
>>
>> I see.
>>
>> I've just tested it on 3.4-rc2, I cannot
On 13.04.2012 16:05, Ilya Dryomov wrote:
> Fix a bug, where in case we need to adjust stripe_size so that the
> length of the resulting chunk is less than or equal to max_chunk_size,
> DUP chunks turn out to be only half as big as they could be.
>
> Cc: Arne Jansen
> Signed-of
under space pressure.
Signed-off-by: Arne Jansen
---
fs/btrfs/extent-tree.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index a844204..db13e51 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -37
On 13.04.2012 09:43, Liu Bo wrote:
> On 04/13/2012 03:19 PM, Arne Jansen wrote:
>
>>
>> might be out of memory. How much does this vm (?) have?
>> Can you try to reduce the constants in disk-io.c:2003-2005?
>>
>> Thanks,
>> Arne
>>
On 14.04.2012 14:56, Arne Jansen wrote:
> It is basically a good thing if we are interruptible when waiting for
> free space, but the generality in which it is implemented currently
> leads to system calls being interruptible that are not documented this
> way. For example git
On 04/17/12 20:22, Josef Bacik wrote:
On Tue, Apr 17, 2012 at 11:24:01AM -0400, Chris Mason wrote:
On Tue, Apr 17, 2012 at 04:15:32PM +0200, Arne Jansen wrote:
On 14.04.2012 14:56, Arne Jansen wrote:
It is basically a good thing if we are interruptible when waiting for
free space, but the
On 04/17/12 21:38, Chris Mason wrote:
On Tue, Apr 17, 2012 at 03:36:20PM -0400, Josef Bacik wrote:
Well then passing a flag down that says we can't interrupt I guess is what we're
going to have to do and just wait uninterruptible. I think our best bet is to
just fix them as they come up, I thou
under space pressure.
Instead we raise the bar to only be interruptible by SIGKILL.
Thanks to David Sterba for suggesting this.
Signed-off-by: Arne Jansen
---
fs/btrfs/extent-tree.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/e
On 18.04.2012 10:27, Arne Jansen wrote:
> It is basically a good thing if we are interruptible when waiting for
> free space, but the generality in which it is implemented currently
> leads to system calls being interruptible that are not documented this
> way. For example git
Hi Liu Bo,
thanks for testing :)
so one block reserve ran out of space. Did you use the same test as
before? On SSD?
Thanks,
Arne
On 27.04.2012 05:16, Liu Bo wrote:
>
> Sorry for the long delay.
>
> I've tested the droptree patch (1/5->5/5) on the latest upstream 3.4-rc4
> along with the miss
On 30.04.2012 13:11, Dan Carpenter wrote:
> Hello Arne Jansen,
>
> The patch 8c9c2bf7a3c4: "btrfs: fix race in reada" from Feb 25, 2012,
> leads to the following warning:
> fs/btrfs/reada.c:308 reada_find_zone()
>warn: 'zone' was already free
On 04.05.2012 05:19, Mark Murawski wrote:
> I think I have some failing hard drives, they are disconnected for now.
>
> stan {~} root# btrfs filesystem show
> Label: none uuid: d71404d4-468e-47d5-8f06-3b65fa7776aa
> Total devices 2 FS bytes used 6.27GB
> devid1 size 9.31GB use
On 05/04/12 20:54, Alexander Block wrote:
The comment above ulist_next stated that it's allowed to call ulist_add
while enumerating. This is actually not allowed as an add may realocate
the nodes buffer und thus make the prev pointer invalid.
Signed-off-by: Alexander Block
I'd much prefer to f
On 22.03.2013 13:03, Wang Shilong wrote:
> Hello Arne,
>
> Since "quota rescan" has not been implemented yet,
>
> overflow can happen, so until now, we can have a check when
> doing accounting in the kernel, if the referenced/exclusive is not
> enough to delete, we just make it to be 0 and give a
On 03/29/13 14:42, Wang Shilong wrote:
> From: Wang Shilong
>
> Just remove the unnecessary check and assignment.
>
> Signed-off-by: Wang Shilong
> ---
> fs/btrfs/backref.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
> ind
On 03/30/13 12:55, Wang Shilong wrote:
>
>
>> On 03/29/13 14:42, Wang Shilong wrote:
>>> From: Wang Shilong
>>>
>>> Just remove the unnecessary check and assignment.
>>>
>>> Signed-off-by: Wang Shilong
>>> ---
>>> fs/btrfs/backref.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
On 03/28/13 11:53, Wang Shilong wrote:
> From: Wang Shilong
>
> This patch introduces mutex lock 'quota_lock', and makes
> all the user change for quota protected by quota_lock.
>
> Signed-off-by: Wang Shilong
> Reviewed-by: Miao Xie
> ---
> fs/btrfs/ctree.h |3 +++
> fs/btrfs/disk-io.c
On 03/28/13 11:54, Wang Shilong wrote:
> From: Wang Shilong
>
> We use mutex_lock to protect all the user change operaions.
> So when we are calling find_qgroup_rb() to check whether
> qgroup exists, we don't have to hold spin_lock.
>
> Besides, when enabling/disabling quota,it must be single
>
Hello Wang,
On 03/31/13 03:44, Wang Shilong wrote:
> Hello Arne, Jan,
>
> When i run stresstest with quota enabled, i hit a panic where
> btrfs_find_all_roots() is called. Would you please double check it.
>
On what kernel version do you hit this (git commit id preferred)?
Can you send us the
On 04/05/13 23:03, Koen De Wit wrote:
> When data in a file is overwritten, starting somewhere in the middle of
> the file, the overwritten space is counted twice against the space usage
> numbers. Is this a bug, or did I something wrong?
Neither. This is a result of how btrfs allocates and overwr
On 15.04.2013 12:37, Wang Shilong wrote:
> Step to reproduce:
> mkfs.btrfs
> mount
> dd if=/dev/zero of=//data bs=1M count=10
> sync
> btrfs quota enable
> btrfs qgroup create 0/5
> btrfs qgroup limit 5M 0/5
> rm -f //data
> sync
> b
On 15.04.2013 09:19, Wang Shilong wrote:
> Hello Jan,
>
>> On Mon, April 15, 2013 at 08:08 (+0200), Wang Shilong wrote:
>
>>> Hello Jan,
>>>
On Mon, April 15, 2013 at 07:44 (+0200), Jan Schmidt wrote:
> Thanks, v2 to come.
Uh, but not immediately. I didn't get tracking of "exclusive
de->aux;
>>>
>>> if ((qg->lim_flags & BTRFS_QGROUP_LIMIT_MAX_RFER) &&
>>> - qg->reserved + qg->rfer + num_bytes >
>>> + qg->reserved + (signed long long)qg->rfer + num_bytes >
>>
On 04/19/13 21:21, Eric Sandeen wrote:
> Big patch, but all it does is add statics to functions which
> are in fact static, then remove the associated dead-code fallout.
>
> removed functions:
>
> btrfs_iref_to_path()
> __btrfs_lookup_delayed_deletion_item()
> __btrfs_search_delayed_insertion_ite
On 04/20/13 19:43, Eric Sandeen wrote:
> On 4/20/13 7:43 AM, Wang Shilong wrote:
>> From: Wang Shilong
>>
>> ulist is a generic structure to iterate tree. we export them
>> just in the hope it may be used by other modules. However, until
>> now, it is just used by btrfs. The main point is that uli
On 09.05.2013 17:14, Remco Hosman - Yerf IT wrote:
> kernel: 3.9.0
> btrfs-progs: pulled from git this morning
>
> Trying to receive a 5gig send file. the first bit is fast, doing 10 -
> 50MB/sec.
> then it slows down. cpu usage is 50% (dual core machine).
> when i do a strace, it looks like this
On 06/04/13 16:53, Chris Mason wrote:
> Quoting Christoph Hellwig (2013-06-04 10:48:56)
>> On Mon, Jun 03, 2013 at 03:55:55PM -0400, J??rn Engel wrote:
>>> Actually, when I compare the two invocations, I prefer the
>>> list_for_each_entry_del() variant over list_pop_entry().
>>>
>>> while (
On 05.06.2013 04:09, Jörn Engel wrote:
> On Tue, 4 June 2013 14:44:35 -0400, Jörn Engel wrote:
>>
>> Or while_list_drain?
I'm fine with while_list_drain, although a name starting with list_
like all other list macros would be nice. How about just list_drain?
The next question is where to put it in
On 07.06.2013 16:50, Eric Sandeen wrote:
> On 6/7/13 5:29 AM, Dave Chinner wrote:
>> On Fri, Jun 07, 2013 at 09:18:58AM +0200, Jan Schmidt wrote:
>>> (cc Arne for far-progs discussion)
>>>
>>> On Thu, June 06, 2013 at 19:54 (+0200), Eric Sandeen wrote:
On 6/6/13 10:20 AM, Jan Schmidt wrote:
>>
On 10.06.2013 08:21, Tomasz Chmielewski wrote:
> I'm trying to use btrfs quotas, but I'm unable to find reliable
> documentation on its usage.
>
> Let's start with an empty subvolume:
>
> - assign 200 MB space to it:
>
> # btrfs qgroup limit 200m /mnt/btrfs-backup/tester/
>
>
> - see the usage
On 07/29/13 10:05, Tomasz Chmielewski wrote:
> On Mon, 10 Jun 2013 09:41:39 +0200
> Arne Jansen wrote:
>
>>> Now, my questions:
>>>
>>> - what do both 104882176 104882176 numbers represent?
>>
>> The first number represents the amount of data in th
On 07/31/13 07:39, Tomasz Chmielewski wrote:
> On Wed, 31 Jul 2013 13:13:37 +0800
> Wang Shilong wrote:
>
>>> # git pull origin master
>>
>> Oops, i am sorry, here should:
>>
>> git pull origin qgroup
>>
>> would you please try it again
>
> Excellent, it works:
>
> # btrfs qgroup show -p /mnt/l
On 05.08.2013 18:35, Tomasz Chmielewski wrote:
>> I am trying to use qgroups
>> functionality & with a basic random-write workload, it constantly
>> keeps leaking memory & within few minutes of IO, there is either
>> out-of-memory killer trying to kill some tasks or there are
>> page-allocation fai
On 07.08.2013 23:43, Sergei Trofimovich wrote:
> From: Sergei Trofimovich
>
> Found by uselex.rb:
>> btrfs_reada_detach: [R]: exported from: fs/btrfs/btrfs.o fs/btrfs/built-in.o
>> fs/btrfs/reada.o
even though the function is currently unused, I'm hesitating to remove it
as it's part of the rea
On 08/08/13 19:46, Zach Brown wrote:
>>> even though the function is currently unused, I'm hesitating to remove it
>>> as it's part of the reada-API and might be handy for anyone going to use
>>> the API in the future.
>>
>> I agree. As replied here,
>> http://www.mail-archive.com/linux-btrfs@vger.
_del_qgroup_rb(struct btrfs_qgroup *qgroup)
> {
> - struct btrfs_qgroup *qgroup = find_qgroup_rb(fs_info, qgroupid);
> - struct btrfs_qgroup_list *list;
> + struct btrfs_qgroup_list *list = NULL;
Why do you initialize list to NULL here? It's always assigned
before used.
s_free_qgroup_config(fs_info);
>
> - if (!quota_root) {
> - ret = -EINVAL;
> - goto out;
> - }
> -
> ret = btrfs_clean_quota_tree(trans, quota_root);
> if (ret)
> goto out;
Reviewed-by: Arne Jansen
--
To unsubscribe from
On 07.08.2013 07:12, Wang Shilong wrote:
> btrfs_free_qgroup_config() is not only called by open/close_ctree(),but
> also btrfs_disable_quota().And for btrfs_disable_quota(),we have set
> 'quota_root' to be null before calling btrfs_free_qgroup_config(),so it
> is safe to cleanup in-memory structur
On 05/17/12 09:14, Dan Carpenter wrote:
Hi, I'm working on some new Smatch code and it complains about this
patch from last year. -Dan
This is a semi-automatic email about new static checker warnings.
The patch 7414a03fbf9e: "btrfs: initial readahead code and
prototypes" from May 23, 2011,
On 05/09/12 16:48, David Sterba wrote:
On Thu, Apr 12, 2012 at 05:54:38PM +0200, Arne Jansen wrote:
@@ -97,30 +119,87 @@ struct reada_machine_work {
+/*
+ * this is the default callback for readahead. It just descends into the
+ * tree within the range given at creation. if an error occurs
On 05/17/12 15:46, Dan Carpenter wrote:
On Thu, May 17, 2012 at 03:31:50PM +0200, Arne Jansen wrote:
The assumption here is that if err == 0, eb is always != NULL. There's
even a tiny comment above the function stating this:
107 /* in case of err, eb might be NULL */
On 21.05.2012 07:34, Miao Xie wrote:
> On Fri, 18 May 2012 14:52:07 +0200, David Sterba wrote:
>> On Thu, May 17, 2012 at 07:58:21PM +0800, Miao Xie wrote:
>>> --- a/fs/btrfs/super.c
>>> +++ b/fs/btrfs/super.c
>>> @@ -1151,6 +1151,8 @@ static int btrfs_remount(struct super_block *sb, int
>>> *flag
On 05/25/12 19:49, Stefan Behrens wrote:
It would be helpful if already the generic block layer would offer
device error counters. Then btrfs could read them, add own counters for
its checksum detected errors, and store everything persistently in the
filesystem.
I take it that you not only cou
On 05/28/12 10:41, Liu Bo wrote:
On 05/28/2012 02:06 PM, WeiFeng Liu wrote:
On Sunday, May 27, 2012 at 5:44 PM, Liu Bo wrote:
Hi,
Thanks for working on this.
Do you have any performance number?
The idea is an interesting one, but I have no idea if it really
works, because blocks are
still
On 04.06.2012 04:59, Liu Bo wrote:
> On 06/04/2012 10:18 AM, Maxim Mikheev wrote:
>
>> Hi Liu,
>>
>> 1) all of them not working (see dmesg at the end)
>> 2)
>> max@s0:~$ sudo btrfs scrub start /dev/sdb
>> ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
>> max@s0:~$ sudo bt
On 04.06.2012 13:30, Maxim Mikheev wrote:
> How can I mount it at the first?
Let me state it differently: If you can't mount it, you can't scrub it.
>
> On 06/04/2012 04:18 AM, Arne Jansen wrote:
>> On 04.06.2012 04:59, Liu Bo wrote:
>>> On 06/04/2012 10:18 AM
On 04.06.2012 14:39, Alex Lyakas wrote:
>
> # How does one track changes in generic INODE_ITEM properties, like
> "mode" or "uid/gid"? Whenever such property gets changed, INODE_ITEM
> gets stamped with a new transid, but do we need to compare it with the
> previous version on the receive side to
1 - 100 of 407 matches
Mail list logo
