On 02/11/2013 05:08 AM, David Sterba wrote:
On Sat, Feb 09, 2013 at 11:21:16AM -0800, Blair Zajac wrote:
Running an Ubuntu Raring VM which was built a week ago that is now running
3.8-rc6, I was booting it last night when it hung. After a few forced
reboots, it came back up and I found the atta
On 02/20/2013 08:19 PM, Alex Elsayed wrote:
Matias Bjorling wrote:
Here is a short proposal for the hybrid storage cache idea with
introduction/motivation and a bird's eye view of an approach to implement
a hybrid storage cache for btrfs. Please note that there is currently no
available patches
When running the 083th case of xfstests on the filesystem with
"compress-force=lzo", the following WARNINGs were triggered.
WARNING: at fs/btrfs/inode.c:7908
WARNING: at fs/btrfs/inode.c:7909
WARNING: at fs/btrfs/inode.c:7911
WARNING: at fs/btrfs/extent-tree.c:4510
WARNING: at fs/btrfs/ex
hi,
On wed, 20 Feb 2013 23:35:36 -0600, Mitch Harder wrote:
> I'm getting a series of kernel WARNING messages when testing Josef's
> btrfs-next and Chris' next branch running xfstests 083 when mounted
> with compress-force=lzo.
>
> I'm not seeing any other indications of problems other than the
>
From: Wang Shilong
Steps to reproduce:
btrfs qgroup limit m /subv
Here, unit(k/K/g/G/m/M/t/T) all will trigger the problem.
For the above command, the original code will parse the limit value as 0
and return successfully.It is wrong,fix it.
Signed-off-by: Wang Shilong
---
cmds-qgroup.
On Thu, Feb 21, 2013 at 02:48:22AM -0700, Miao Xie wrote:
> When running the 083th case of xfstests on the filesystem with
> "compress-force=lzo", the following WARNINGs were triggered.
> WARNING: at fs/btrfs/inode.c:7908
> WARNING: at fs/btrfs/inode.c:7909
> WARNING: at fs/btrfs/inode.c:7911
On Mon, Feb 18, 2013 at 04:56:04PM +0900, Kyungsik Lee wrote:
> @@ -55,8 +55,9 @@ static struct list_head *lzo_alloc_workspace(void)
> return ERR_PTR(-ENOMEM);
>
> workspace->mem = vmalloc(LZO1X_MEM_COMPRESS);
> - workspace->buf = vmalloc(PAGE_CACHE_SIZE);
> - workspac
On Thu, Feb 21, 2013 at 7:26 AM, Chris Mason wrote:
> On Thu, Feb 21, 2013 at 02:48:22AM -0700, Miao Xie wrote:
>> When running the 083th case of xfstests on the filesystem with
>> "compress-force=lzo", the following WARNINGs were triggered.
>> WARNING: at fs/btrfs/inode.c:7908
>> WARNING: at
Hi folks,
I'm using Ubuntu 12.10 Quantal with
# uname -r
3.5.0-24-generic
And it seems I cannot defrag :
# filefrag /boot/initrd.img-3.5.0-24-generic
/boot/initrd.img-3.5.0-24-generic: 3 extents found
# btrfs filesystem defrag /boot/initrd.img-3.5.0-24-generic
# echo $?
20
# filefrag /boot/ini
On Thu, Feb 21, 2013 at 03:46:59PM +0100, Swâmi Petaramesh wrote:
> Hi folks,
>
> I'm using Ubuntu 12.10 Quantal with
> # uname -r
> 3.5.0-24-generic
>
> And it seems I cannot defrag :
>
> # filefrag /boot/initrd.img-3.5.0-24-generic
> /boot/initrd.img-3.5.0-24-generic: 3 extents found
>
> # bt
Le 21/02/2013 16:01, Hugo Mills a écrit :
> That's a success. The return code for defrag is broken, and for some
> reason returns 20 on success.
Thanks for the quick reply Hugo. So should I script that "for now and
the future", $? 20 = OK ?
> This is pretty good. You can't guarantee that any giv
Hi Josef,
Please remove the following patch:
Btrfs: move fs/btrfs/ioctl.h to include/uapi/linux/btrfs.h
(55e301fd57a6239ec14b91a1cf2e70b3dd135194 in your btrfs-next.git)
It's not fully cooked and I'm working on a second version of the patch
that will do a little more rearranging of the header fi
When a subvolume is removed, we remove the root item from the root tree,
while the tree blocks and backrefs remain for a while. When backref walking
comes across one of those orphan tree blocks, it can find a backref for a
no longer existing root. This is all good, we only must tolerate
__resolve_i
On Thu, Feb 21, 2013 at 08:20:37AM -0700, Filipe Brandenburger wrote:
> Hi Josef,
>
> Please remove the following patch:
>
> Btrfs: move fs/btrfs/ioctl.h to include/uapi/linux/btrfs.h
> (55e301fd57a6239ec14b91a1cf2e70b3dd135194 in your btrfs-next.git)
>
> It's not fully cooked and I'm working on
Hi again,
Having numerous snapshots, I prefer to ask rather than take the risk of
exploding my storage space, better safe than sorry ;-)
"man btrfs" states :
« NOTE: defragmenting with kernels up to 2.6.37 will unlink COW-ed
copies of data, don't use it if you use snapshots, have
deduplicat
On Thu, Feb 21, 2013 at 04:46:14PM +0100, Swâmi Petaramesh wrote:
> Hi again,
>
> Having numerous snapshots, I prefer to ask rather than take the risk of
> exploding my storage space, better safe than sorry ;-)
>
> "man btrfs" states :
>
> « NOTE: defragmenting with kernels up to 2.6.37 will unl
On Thu, 2013-02-21 at 16:46 +0100, Swâmi Petaramesh wrote:
> Hi again,
>
> Having numerous snapshots, I prefer to ask rather than take the risk of
> exploding my storage space, better safe than sorry ;-)
>
> "man btrfs" states :
>
> « NOTE: defragmenting with kernels up to 2.6.37 will unlink COW
Le 21/02/2013 16:50, Liu Bo a écrit :
> Well, there is already a patch which addresses your concern and it's
> 'snapshot-aware defrag' feature and now in v6, it's not merged yet.
> thanks, liubo
Hi Liu,
So should I understand that, even though the manpage states that the
issue is for kernels <=
Le 21/02/2013 16:54, Calvin Walton a écrit :
> You really should upgrade your kernel, however. 3.5.0 is rather old in
> btrfs-years! Lots of fixes have gone into newer kernels.
Hi Calvin,
I expect Ubuntu 13.04 to come with kernel 3.7 in April. Having Ubuntu
kernel upgrades every 6 months (and sev
On 02/21/2013 08:01 AM, Swâmi Petaramesh wrote:
Le 21/02/2013 16:54, Calvin Walton a écrit :
You really should upgrade your kernel, however. 3.5.0 is rather old in
btrfs-years! Lots of fixes have gone into newer kernels.
Hi Calvin,
I expect Ubuntu 13.04 to come with kernel 3.7 in April.
13.
On 2/21/13 9:10 AM, Swâmi Petaramesh wrote:
> Le 21/02/2013 16:01, Hugo Mills a écrit :
>> That's a success. The return code for defrag is broken, and for some
>> reason returns 20 on success.
>
> Thanks for the quick reply Hugo. So should I script that "for now and
> the future", $? 20 = OK ?
H
On Thu, Feb 21, 2013 at 05:01:30PM +0100, Swâmi Petaramesh wrote:
> Le 21/02/2013 16:54, Calvin Walton a écrit :
> > You really should upgrade your kernel, however. 3.5.0 is rather old in
> > btrfs-years! Lots of fixes have gone into newer kernels.
>
> Hi Calvin,
>
> I expect Ubuntu 13.04 to come
On Thu, Feb 21, 2013 at 10:10:57AM -0600, Eric Sandeen wrote:
> On 2/21/13 9:10 AM, Swâmi Petaramesh wrote:
> > Le 21/02/2013 16:01, Hugo Mills a écrit :
> >> That's a success. The return code for defrag is broken, and for some
> >> reason returns 20 on success.
> >
> > Thanks for the quick reply
On Thu, Feb 21, 2013 at 06:03:17PM +0100, Swâmi Petaramesh wrote:
> Le 21/02/2013 17:38, Hugo Mills a écrit :
> > Plus, if something does go wrong with your FS, and you're running an
> > older kernel, you'll get limited amounts of sympathy, because quite a
> > lot of the problems people encounter w
Le 21/02/2013 17:38, Hugo Mills a écrit :
> Plus, if something does go wrong with your FS, and you're running an
> older kernel, you'll get limited amounts of sympathy, because quite a
> lot of the problems people encounter with older kernels have already
> been fixed in newer ones.
The matter, as
Thanks a lot for the prompt response. I had seen that, but I am still
not sure of where it really
happens within fill_delalloc. Could you help me a little further in that path?
Secondly, now I am confused between the btree_writepages and
btrfs_writepages/btrfs_writepage
methods. I thought btrfs_wr
Le 21/02/2013 18:25, Hugo Mills a écrit :
> Correct. But btrfs isn't at that stage yet. It's getting visibly
> closer, but it's not quite there. Hence the very strong recommendation
> to keep up with the latest code. Hugo.
The matter is that BTRFS had many early adopters just because it is -
and
Ok,
Nothing terribly broken with it, I can do with incremental commits on
top of it, thanks!
Filipe
On Thu, Feb 21, 2013 at 7:46 AM, Chris Mason wrote:
> On Thu, Feb 21, 2013 at 08:20:37AM -0700, Filipe Brandenburger wrote:
>> Hi Josef,
>>
>> Please remove the following patch:
>>
>> Btrfs: mov
Hi Chris,
my comments below
On 02/20/2013 10:32 PM, Chris Mason wrote:
> Hi everyone,
>
> This spot in the chunk allocation code has seen a lot of little tweaks,
> so I wanted to send this patch out for more eyes.
>
> --
>
> We try to limit the size of a chunk to 10GB, which keeps the unit of
>
Am Donnerstag, 21. Februar 2013 schrieb Swâmi Petaramesh:
> Hi folks,
>
> I'm using Ubuntu 12.10 Quantal with
> # uname -r
> 3.5.0-24-generic
>
> And it seems I cannot defrag :
>
> # filefrag /boot/initrd.img-3.5.0-24-generic
> /boot/initrd.img-3.5.0-24-generic: 3 extents found
>
> # btrfs file
A user reported hitting the BUG_ON() in btrfs_finished_ordered_io() where we had
csums on a NOCOW extent. This can happen if we have NODATACOW set but not
NODATASUM set, which can happen in two cases, either we mount with -o nodatacow
and then write into preallocated space, or chattr +C a director
On Thu, Feb 21, 2013 at 06:47:28PM +0100, Swâmi Petaramesh wrote:
> Le 21/02/2013 18:25, Hugo Mills a écrit :
> > Correct. But btrfs isn't at that stage yet. It's getting visibly
> > closer, but it's not quite there. Hence the very strong recommendation
> > to keep up with the latest code. Hugo.
>
On 02/21/2013 06:47 PM, Swâmi Petaramesh wrote:
> Le 21/02/2013 18:25, Hugo Mills a écrit :
>> Correct. But btrfs isn't at that stage yet. It's getting visibly
>> closer, but it's not quite there. Hence the very strong recommendation
>> to keep up with the latest code. Hugo.
>
> The matter is tha
I've experienced filesystem freezes with permanent spikes in the active
process count for quite a while, particularly on filesystems whose
available raw space has already been fully allocated to chunks.
While looking into this, I found a pretty obvious error in
do_chunk_alloc: it sets space_info->
On Thu, 21 Feb 2013 18:47:28 +0100
Swâmi Petaramesh wrote:
> Le 21/02/2013 18:25, Hugo Mills a écrit :
> > Correct. But btrfs isn't at that stage yet. It's getting visibly
> > closer, but it's not quite there. Hence the very strong
> > recommendation to keep up with the latest code. Hugo.
>
> T
On Thu, Feb 21, 2013 at 09:58:16PM +0100, Bardur Arantsson wrote:
> On 02/21/2013 06:47 PM, Swâmi Petaramesh wrote:
> > Le 21/02/2013 18:25, Hugo Mills a écrit :
> >> Correct. But btrfs isn't at that stage yet. It's getting visibly
> >> closer, but it's not quite there. Hence the very strong recomm
On Feb 21, 2013, Alexandre Oliva wrote:
> What I saw in that function also happens to explain why in some cases I
> see filesystems allocate a huge number of chunks that remain unused
> (leading to the scenario above, of not having more chunks to allocate).
> It happens for data and metadata, but
On Thu, Feb 21, 2013 at 03:34:15PM -0500, Josef Bacik wrote:
> A user reported hitting the BUG_ON() in btrfs_finished_ordered_io() where we
> had
> csums on a NOCOW extent. This can happen if we have NODATACOW set but not
> NODATASUM set, which can happen in two cases, either we mount with -o
>
While inserting dir index and updating inode for a snapshot, we'd
add delayed items which consume trans->block_rsv, if we don't have
any space reserved in this trans handle, we either just return or
reserve space again.
But before creating pending snapshots during committing transaction,
we've don
setup:
mkfs.btrfs /dev/sdb
mkfs.ext4 /dev/sdb && mount /dev/sdb /ext4
mkfs.btrfs /dev/sdc /dev/sdd
test case:
mkfs.btrfs /dev/sdc /dev/sdd
problem:
mkfs is fine, however reports the following error ..
---
ERROR: unable to scan the device '/dev/sdb' - Device or resource busy
ERROR: u
Signed-off-by: Hemanth Kumar
---
298 | 37 +
298.out | 12
2 files changed, 49 insertions(+)
create mode 100644 298
create mode 100644 298.out
diff --git a/298 b/298
new file mode 100644
index 000..d699fb7
--- /dev/null
+++ b/298
@@ -0,
On 02/21/2013 10:56 PM, David Sterba wrote:
> On Thu, Feb 21, 2013 at 09:58:16PM +0100, Bardur Arantsson wrote:
>> On 02/21/2013 06:47 PM, Swâmi Petaramesh wrote:
>>> Le 21/02/2013 18:25, Hugo Mills a écrit :
Correct. But btrfs isn't at that stage yet. It's getting visibly
closer, but it'
Signed-off-by: Hemanth Kumar
---
299 | 38 ++
299.out | 20
2 files changed, 58 insertions(+)
create mode 100644 299
create mode 100644 299.out
diff --git a/299 b/299
new file mode 100644
index 000..6b03438
--- /dev/null
+++ b/2
A few weeks ago I reported a similar bug [1]. It has to do with file
renaming. Do you think that it is related? This patch doesn't seem to
help.
[1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg21640.html
On Thu, Feb 21, 2013 at 3:34 PM, Josef Bacik wrote:
> A user reported hitting
On 02/22/13 07:12, Hemanth Kumar wrote:
>
> Signed-off-by: Hemanth Kumar
> ---
> 299 | 38 ++
> 299.out | 20
> 2 files changed, 58 insertions(+)
> create mode 100644 299
> create mode 100644 299.out
>
> diff --git a/299 b/299
> new
A trivial fix, corrects the indentation.
Signed-off-by: Anand Jain
---
utils.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/utils.c b/utils.c
index d660507..9c2e510 100644
--- a/utils.c
+++ b/utils.c
@@ -1192,12 +1192,13 @@ scan_again:
return
On Mon, Jan 28, 2013 at 10:49:20AM -0500, Marios Titas wrote:
> Try this:
>
> touch test
> chattr +C test
> lsattr test
> mv test test2
> lsattr test2
>
> The original file (test) will have the C flag but when renamed the
> flag disappears. If the volume is unmounted and then
On Fri, Feb 22, 2013 at 01:34:26AM -0500, Marios Titas wrote:
> A few weeks ago I reported a similar bug [1]. It has to do with file
> renaming. Do you think that it is related? This patch doesn't seem to
> help.
Yes, they're related, and I sent you a patch in [1] thread, could you check it?
than
48 matches
Mail list logo
