There is still a problem when btrfs is built-in:
err = btrfs_hash_init();
Will not succeed if run on an slow cpu (intel u7300) or in qemu if
btrfs is built-in:
# qemu-kvm -enable-kvm -usbdevice tablet -m 2048 -smp 2 -sdl -kernel
/usr/src/linux/arch/x86/boot/bzImage
But it works, when btrfs is
okay, putting late_initcall instead of module_init fixes it for me,
but this is something you guys should decide how to handle:
//module_init(init_btrfs_fs)
late_initcall(init_btrfs_fs);
Ahmet
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
err = btrfs_hash_init();
Did you find out what err's value was?
Its -2
Ahmet
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks a lot Filipe!
Have been testing this patch now for 5 days and it fixed this annoying
Problem since 3.11.0 on 3x NFS Servers here.
This is also a candidate that should be back ported, as it fixes crashes.
Just for Information for others here: Your previous patch,
Btrfs: return immediately
On Sat, Sep 21, 2013 at 1:20 PM, Ahmet Inan
ai...@mathematik.uni-freiburg.de wrote:
You will want the patch I just sent,
Btrfs: create the uuid tree on remount rw
and that should fix the snapshot problems. Thanks,
thanks Josef - you can close this bug:
https://bugzilla.kernel.org
You will want the patch I just sent,
Btrfs: create the uuid tree on remount rw
and that should fix the snapshot problems. Thanks,
thanks Josef - you can close this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=61301
then. will try your patch later, too.
Ahmet
--
To unsubscribe from
ive had the same problem and this commit helped, which i had to cherry-pick:
commit c83b3452db6e1b048312c50b23f06c9634535f80
Author: Josef Bacik jba...@fusionio.com
Date: Mon Jul 22 12:50:37 2013 -0400
Btrfs: reset ret in record_one_backref
I was getting warnings when running find ./
I got this problem since 3.8.5 + for-linus (from that time).
Have just tried 3.8.6 + for-linus with git merge -X theirs
btrfs/for-linus but still same problem.
Going back to 3.7.4 + for-linus (from that time) doesn't give me the problem.
This is an production nfs server with 2x2TB raid1, so cant
The real problem, however, is not caused by that commit but by a tree mod log
bug. I expect that fs/btrfs/ctree.c:1144 is this BUG_ON in your kernel from
__tree_mod_log_rewind (my line numbers don't match):
1138 switch (tm-op) {
1139 case
Yeah we have a lot of
ptr = kmalloc();
BUG_ON(ptr);
everywhere. I'll fix this one up but I really need to sit down and go through
all of them and make sure we do the right thing in all these places. Thanks,
But what would be the right thing to do when you got no memory?
Spinlock until
On Wed, Feb 27, 2013 at 7:26 PM, Josef Bacik jba...@fusionio.com wrote:
On Wed, Feb 27, 2013 at 07:31:11AM -0700, Ahmet Inan wrote:
Yeah we have a lot of
ptr = kmalloc();
BUG_ON(ptr);
everywhere. I'll fix this one up but I really need to sit down and go
through
all of them
If we're corrupting on abort that is a bug too that needs to be fixed
too. I've banged on the abort stuff a lot recently when trying to
make it not panic the box and it appears to work fine. Obviously that
kind of stuff needs to be tested as well, but so far I haven't seen
abort corrupt the
i also dont see any benefit from inlining small files:
this example is me doing a fully fledged prebuilt
gentoo system installation on a fresh HDD from
squashfs image on usb key in under 5 minutes:
with defaults (inlining small files):
# mount -o noatime,compress=lzo /dev/sda2 /mnt/point
# time
i also dont see any benefit from inlining small files:
with defaults (inlining small files):
real4m39.253s
Data: total=10.01GB, used=9.08GB
Metadata, DUP: total=2.00GB, used=992.48MB
without inline:
real4m42.085s
Data: total=11.01GB, used=10.85GB
Metadata, DUP: total=1.00GB,
with defaults (inlining small files):
real4m39.253s
Data: total=10.01GB, used=9.08GB
Metadata, DUP: total=2.00GB, used=992.48MB
This uses 10290.40 MB total, if we pad with zeroes (9.08GB plus
992.48MB).
without inline:
real4m42.085s
Data: total=11.01GB, used=10.85GB
Metadata,
9.08GB + 992.48MB*2 == 11.02GB
10.85GB + 518MB*2 == 11.86GB
That's nearly a GB smaller.
That, too; I missed the DUP. Not quite as pronounced as in my
calculations, then, but still a significant enough difference.
great. now were down to 7-8%
just FYI:
ive retested with max_inline=0 but
--
Ahmet Inan
Systemadministrator
Mathematisches Institut
Albert-Ludwigs-Universität Freiburg
Eckerstr. 1
79104 Freiburg im Breisgau
Tel.: +49(0)761 / 203-5552
Raum: 332
mailto:sys...@email.mathematik.uni-freiburg.de
Abteilung für Angewandte Mathematik
Albert-Ludwigs-Universität Freiburg
Hermann
On Sat, Apr 21, 2012 at 10:54 PM, Ahmet Inan
ai...@mathematik.uni-freiburg.de wrote:
On Fri, Apr 13, 2012 at 3:47 PM, Josef Bacik jo...@redhat.com wrote:
On Fri, Apr 13, 2012 at 02:26:19PM +0200, Ahmet Inan wrote:
On Fri, Apr 13, 2012 at 1:22 PM, Ahmet Inan
ai...@mathematik.uni-freiburg.de
On Sun, Apr 22, 2012 at 9:59 AM, Sergei Trofimovich sly...@gmail.com wrote:
On Sat, 21 Apr 2012 22:54:41 +0200
Ahmet Inan ai...@mathematik.uni-freiburg.de wrote:
On Fri, Apr 13, 2012 at 3:47 PM, Josef Bacik jo...@redhat.com wrote:
On Fri, Apr 13, 2012 at 02:26:19PM +0200, Ahmet Inan wrote
On Sun, Apr 22, 2012 at 11:16 AM, Ahmet Inan
ai...@mathematik.uni-freiburg.de wrote:
On Sun, Apr 22, 2012 at 9:59 AM, Sergei Trofimovich sly...@gmail.com wrote:
On Sat, 21 Apr 2012 22:54:41 +0200
Ahmet Inan ai...@mathematik.uni-freiburg.de wrote:
On Fri, Apr 13, 2012 at 3:47 PM, Josef Bacik
On Fri, Apr 13, 2012 at 3:47 PM, Josef Bacik jo...@redhat.com wrote:
On Fri, Apr 13, 2012 at 02:26:19PM +0200, Ahmet Inan wrote:
On Fri, Apr 13, 2012 at 1:22 PM, Ahmet Inan
ai...@mathematik.uni-freiburg.de wrote:
On Fri, Apr 13, 2012 at 8:49 AM, cwillu cwi...@cwillu.com wrote:
dmesg
On Thu, Apr 12, 2012 at 4:23 PM, Josef Bacik jo...@redhat.com wrote:
On Thu, Apr 12, 2012 at 09:37:48AM -0400, Josef Bacik wrote:
On Thu, Apr 12, 2012 at 11:22:51AM +0200, Ahmet Inan wrote:
On Wed, Apr 11, 2012 at 7:04 PM, Josef Bacik jo...@redhat.com wrote:
On Wed, Apr 11, 2012 at 05:26
On Fri, Apr 13, 2012 at 8:49 AM, cwillu cwi...@cwillu.com wrote:
dmesg and fstab attached as requested.
Need dmesg after you've hit alt-sysrq-w a couple times during the slow period.
here.
i guess i should also increase dmesg history size next time.
other than the slow boot, everything seems
On Fri, Apr 13, 2012 at 2:57 PM, cwillu cwi...@cwillu.com wrote:
These are usb disks? Does that failure at 12.241517 (or related)
happen every time?
no, 0CCD:0052 is the webcam. i dont have the modules for the webcam
in initramfs, thats why.
the real slowness is around 33.305370
The 2 SATA
On Wed, Apr 11, 2012 at 7:04 PM, Josef Bacik jo...@redhat.com wrote:
On Wed, Apr 11, 2012 at 05:26:29PM +0200, Ahmet Inan wrote:
On Tue, Apr 10, 2012 at 5:16 PM, Josef Bacik jo...@redhat.com wrote:
On Mon, Apr 09, 2012 at 05:20:46PM -0400, Calvin Walton wrote:
On Mon, 2012-04-09 at 16:54
On Tue, Apr 10, 2012 at 5:16 PM, Josef Bacik jo...@redhat.com wrote:
On Mon, Apr 09, 2012 at 05:20:46PM -0400, Calvin Walton wrote:
On Mon, 2012-04-09 at 16:54 -0400, Josef Bacik wrote:
On Mon, Apr 09, 2012 at 01:10:04PM -0400, Calvin Walton wrote:
On Mon, 2012-04-09 at 11:53 -0400, Calvin
On Thu, Feb 16, 2012 at 6:55 PM, Chris Mason chris.ma...@oracle.com wrote:
On Thu, Feb 16, 2012 at 04:05:40PM +0100, Ahmet Inan wrote:
On Thu, Feb 16, 2012 at 11:31 AM, Chris Samuel ch...@csamuel.org wrote:
On Thursday 16 February 2012 19:06:52 Ahmet Inan wrote:
and got ENOSPC again
On Wed, Jan 18, 2012 at 5:13 PM, Mitch Harder
mitch.har...@sabayonlinux.org wrote:
I have a Btrfs partition that is reliably reproducing premature ENOSPC
when restoring the disk from a tar file, but it is only happening with
zlib compression (lzo or no compression proceeds normally).
Ive just
On Thu, Feb 16, 2012 at 11:31 AM, Chris Samuel ch...@csamuel.org wrote:
On Thursday 16 February 2012 19:06:52 Ahmet Inan wrote:
and got ENOSPC again :(
so it doesnt matter if lzo or zlib: ENOSPC with compression
enabled!
my kernel: vanilla 3.2.5
I know that there has been an ENOSPC fix
On Wed, Jan 18, 2012 at 5:13 PM, Mitch Harder
mitch.har...@sabayonlinux.org wrote:
I have a Btrfs partition that is reliably reproducing premature ENOSPC
when restoring the disk from a tar file, but it is only happening with
zlib compression (lzo or no compression proceeds normally).
thank you
30 matches
Mail list logo
