Re: [RFC INFO PATCH 02/03] export use_mm and unuse_mm for filesystem modules.
Liuwenyi wrote: Maybe, you should send this patch to Andrew Morton a...@linux-foundation.org Andrea Arcangeli aarca...@redhat.com Michael S. Tsirkin m...@redhat.com linux-ker...@vger.kernel.org linux...@kvack.org I said in [00] that I sent this patch to Andrew. What I did not say was it was sent on December 9, 2009 to every addess on your list, except for Andrea. jim -- 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
Re: btrfs fallocate woes
On Wed, Jan 20, 2010 at 7:28 AM, Aneesh Kumar K. V aneesh.ku...@linux.vnet.ibm.com wrote: the below change fixes this for me on btrfs Thanks a million, now I guess we're waiting for Chris to pull it. Will it qualify for stable update? -- This message represents the official view of the voices in my head -- 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
Re: worse than expected compression ratios with -o compress
On Mon, Jan 18, 2010 at 05:11:53PM -0500, Jim Faulkner wrote:
On Mon, 18 Jan 2010, Chris Mason wrote:
Currently the only compression algorithm we support is gzip, so try
gzipp'ing
your database to get a better comparison. The plan is to eventually support
other compression algorithms, but currently we do not. Thanks,
The compression code backs off compression pretty quickly if parts of
the file do not compress well. This is another way of saying it favors
CPU time over the best possible compression. If gzip ends up better
than what you're getting from btrfs, I can give you a patch to force
compression all the time.
Yes, gzip compresses much better than btrfs. I'd greatly appreciate
a patch to force compression all the time.
It would be nice if such an ability were merged in the mainline.
Perhaps there could be a mount option or tunable parameter to force
compression?
Lets start by making sure that this patch works for you. Just apply it
(2.6.32 or 2.6.33-rc) and then mount -o compress-force. Normally, mount
-o compress will set a flag on a file after it fails to get good
compression for that file.
With this patch, mount -o compress-force will still honor that flag.
But it will skip setting it during new writes. This is a long way of
saying you'll have to copy your data file to a new files for the new
mount option to do anything.
Please let me know if this improves your ratios
-chris
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 9f806dd..2aa8ec6 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1161,6 +1161,7 @@ struct btrfs_root {
#define BTRFS_MOUNT_SSD_SPREAD (1 8)
#define BTRFS_MOUNT_NOSSD (1 9)
#define BTRFS_MOUNT_DISCARD(1 10)
+#define BTRFS_MOUNT_FORCE_COMPRESS (1 11)
#define btrfs_clear_opt(o, opt)((o) = ~BTRFS_MOUNT_##opt)
#define btrfs_set_opt(o, opt) ((o) |= BTRFS_MOUNT_##opt)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index b330e27..f46c572 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -483,7 +483,8 @@ again:
nr_pages_ret = 0;
/* flag the file so we don't compress in the future */
- BTRFS_I(inode)-flags |= BTRFS_INODE_NOCOMPRESS;
+ if (!btrfs_test_opt(root, FORCE_COMPRESS))
+ BTRFS_I(inode)-flags |= BTRFS_INODE_NOCOMPRESS;
}
if (will_compress) {
*num_added += 1;
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 3f9b457..8a1ea6e 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -66,7 +66,8 @@ enum {
Opt_degraded, Opt_subvol, Opt_device, Opt_nodatasum, Opt_nodatacow,
Opt_max_extent, Opt_max_inline, Opt_alloc_start, Opt_nobarrier,
Opt_ssd, Opt_nossd, Opt_ssd_spread, Opt_thread_pool, Opt_noacl,
- Opt_compress, Opt_notreelog, Opt_ratio, Opt_flushoncommit,
+ Opt_compress, Opt_compress_force, Opt_notreelog, Opt_ratio,
+ Opt_flushoncommit,
Opt_discard, Opt_err,
};
@@ -82,6 +83,7 @@ static match_table_t tokens = {
{Opt_alloc_start, alloc_start=%s},
{Opt_thread_pool, thread_pool=%d},
{Opt_compress, compress},
+ {Opt_compress_force, compress-force},
{Opt_ssd, ssd},
{Opt_ssd_spread, ssd_spread},
{Opt_nossd, nossd},
@@ -173,6 +175,11 @@ int btrfs_parse_options(struct btrfs_root *root, char
*options)
printk(KERN_INFO btrfs: use compression\n);
btrfs_set_opt(info-mount_opt, COMPRESS);
break;
+ case Opt_compress_force:
+ printk(KERN_INFO btrfs: forcing compression\n);
+ btrfs_set_opt(info-mount_opt, FORCE_COMPRESS);
+ btrfs_set_opt(info-mount_opt, COMPRESS);
+ break;
case Opt_ssd:
printk(KERN_INFO btrfs: use ssd allocation scheme\n);
btrfs_set_opt(info-mount_opt, SSD);
--
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
Re: [RFC INFO PATCH 02/03] export use_mm and unuse_mm for filesystem modules.
jim owens wrote: What I did not say was it was sent on December 9, 2009 to every addess on your list, except for Andrea. OK, as josef told me, the patch is corrupt and will not apply. I am sending a new one I just made against btrfs-unstable to linux-btrfs and will create a new patch for Andrew when the directIO code has been tested. jim -- 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
Howto mount intact left-over device of a degraded btrfs-raid?
Hi list I tried to mount the intact device of a two memer btrfs raid array with one device missing: # mount -o degraded /dev/sdb /mnt this wouldn't work with kernel 2.6.32-2 - caused some sort of memory segfault # btrfs-vol -r missing /mnt complained and refused to mount the array degraded with only one intact array member left - demanded two intact members How can I mount this array anyway? thanks! -- 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
Re: btrfs write behavior on idle system
On Mon, Jan 18, 2010 at 08:36:37PM +0100, Carlos R. Mafra wrote: On Mo 18.Jan'10 at 12:14:43 -0600, Ravi Pinjala wrote: On 01/18/10 11:17, Carlos R. Mafra wrote: Hi everyone, I am using btrfs for my /home partition since I upgraded my slow laptop hdd for an ssd 3 weeks ago. I am always in sync with Linus' tree of the day (plus a btrfs patch which is not in there yet) and so far I haven't lost any data, so all is good. I have a question about the write behavior of the various [btrfs- ] kernel threads, as I've been monitoring what is writing to the ssd just in case. So what I've been observing with 'iostat', 'iotop' and 'blktrace' is the following. If my laptop is almost absolutely idle (just a plain Window Maker and a few xterms and a couple dockapps open) there is nothing writing to the disk (which is OK). But as soon as I leave an open tab in chrome (or firefox) the various [btrfs- ] threads start writing in my /home, and I don't know what. For testing purposes, I mounted the config dir of chrome (~/.config/google-chrome) in my SD card (at /dev/mmcblk0p1) to exclude the possibility of maybe chrome trying to update its history or something, so that it does not write anything in my /home partition with btrfs. But I see this in the output of 'iotop' from a 60 sec interval, showing only the processes which wrote something: Total DISK READ: 0 B/s | Total DISK WRITE: 10.26 K/s PID USER DISK READ DISK WRITE SWAPINIOCOMMAND 485 root 0 B/s5.19 K/s 0.00 % 0.02 % [btrfs-transacti] 3792 root 0 B/s 0 B/s 0.00 % 0.01 % [flush-btrfs-1] 476 root 0 B/s0.13 K/s 0.00 % 0.00 % [btrfs-delalloc-] 481 root 0 B/s4.93 K/s 0.00 % 0.00 % [btrfs-endio-wri] and there are more instances like this. Is there a way to avoid (or reduce) the writings of these threads? And when I start opening some pages in chrome and use it some more I get many many writes on my /home partition from these threads (and swapper, see below) even though I mounted the .config/google-chrome dir under /dev/mmcblk0p1 which uses ext4. From another experiment where chrome was showing a blank tab a ~7 minutes run of 'blktrace -a write /dev/sda3' (sda3 is my /home) ends like this (from 'blkparse -s sda3.blktrace.0'): - snip - Don't forget cache - should be under ~/.cache/google-chrome. That would probably explain the disk activity you're seeing. Oh my... what a shame! That was it; I moved it to the SD card and now my ssd is not suffering anymore. Web browsers can write a lot (really a lot) to disk. There are caches of the images, caches of the web pages, your history, book mark updates, and then whatever tracking and bank account numbers google is holding on to for you. Does anyone know if chrome share's firefox's affinity to use fsync heavily? You could test with strace. Either way, lots of writing when surfing the web isn't a big surprise. -chris -- 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
Re: Inconsistent reports after disk-error.
On Mon, Jan 18, 2010 at 11:45:40PM +0100, Ronny H. Kavli wrote: I've been running btrfs on some disks with Ubuntu kernel 2.6.31 for a while now. Recently I had a bad USB-cable to one of those disks which left the btrfs filesystem in a somewhat sad state. Fair enough. What worries me is what btrfsck reports back to me during two successive runs: r...@bollox:/home/kavli# btrfsck /dev/mapper/vg3-vbox1 checksum verify failed on 142837022720 wanted 5D18D333 found 95085E8 checksum verify failed on 142837022720 wanted 5D18D333 found 95085E8 checksum verify failed on 142837022720 wanted 5D18D333 found 95085E8 btrfsck: disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed. Aborted r...@bollox:/home/kavli# btrfsck /dev/mapper/vg3-vbox1 checksum verify failed on 142837022720 wanted 5D18D333 found 81D15E8 checksum verify failed on 142837022720 wanted 5D18D333 found 81D15E8 checksum verify failed on 142837022720 wanted 5D18D333 found 81D15E8 btrfsck: disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed. Aborted I'd expected the checksums for the two separate runs to be equal. This is a vanilla filesystem that resides on one physical disk: r...@bollox:/home/kavli# btrfs-show /dev/mapper/vg3-vbox1 failed to read /dev/sr0 Label: none uuid: 08078f2f-22e0-4b79-8367-66528791afff Total devices 1 FS bytes used 106.79GB devid1 size 232.88GB used 218.04GB path /dev/mapper/vg3-vbox1 Btrfs Btrfs v0.19 I've googled a bit and found one case with a similar problem in a raid1 setup (I guess incorrectly stated as raid0): http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg03429.html There were no followups beyond that point which stated the cause of this behaviour. I haven't been able to reproduce it locally, but I definitely think it sounds like the same problem. Have you tried the btrfs-map-logical program in the unstable btrfs-progs repo? -chris -- 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
Re: Inconsistent reports after disk-error.
On Mon, Jan 18, 2010 at 11:45:40PM +0100, Ronny H. Kavli wrote: BTW: Is there any hope of recovery of this filesystem, or is it just a new mkfs that can help? I'd expect that we can help at least copy some data off. -chris -- 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
[PATCH] fix up userspace for newer glibc
Rawhide is getting cranky with posix compliance, and a few
things have stopped building.
getpagesize() is now only available -with- __USE_XOPEN_EXTENDED
or __USE_BSD, and NOT __USE_XOPEN2K.
_GNU_SOURCE must define __USE_XOPEN2K because getpagesize()
has gone away for mkfs. I gave up and used sysconf.
Also, something used to pull in stat that no longer does, so
things like S_ISREG weren't getting defined.
The following fixes things for me.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
Index: btrfs-progs-0.19/btrfsck.c
===
--- btrfs-progs-0.19.orig/btrfsck.c
+++ btrfs-progs-0.19/btrfsck.c
@@ -21,6 +21,9 @@
#include stdio.h
#include stdlib.h
#include fcntl.h
+#include sys/types.h
+#include sys/stat.h
+#include unistd.h
#include kerncompat.h
#include ctree.h
#include disk-io.h
Index: btrfs-progs-0.19/mkfs.c
===
--- btrfs-progs-0.19.orig/mkfs.c
+++ btrfs-progs-0.19/mkfs.c
@@ -341,7 +341,7 @@ int main(int ac, char **av)
u64 alloc_start = 0;
u64 metadata_profile = BTRFS_BLOCK_GROUP_RAID1 | BTRFS_BLOCK_GROUP_DUP;
u64 data_profile = BTRFS_BLOCK_GROUP_RAID0;
- u32 leafsize = getpagesize();
+ u32 leafsize = sysconf(_SC_PAGESIZE);
u32 sectorsize = 4096;
u32 nodesize = leafsize;
u32 stripesize = 4096;
@@ -398,7 +398,7 @@ int main(int ac, char **av)
print_usage();
}
}
- sectorsize = max(sectorsize, (u32)getpagesize());
+ sectorsize = max(sectorsize, (u32)sysconf(_SC_PAGESIZE));
if (leafsize sectorsize || (leafsize (sectorsize - 1))) {
fprintf(stderr, Illegal leafsize %u\n, leafsize);
exit(1);
--
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
removing a snapshot that is outside the subvolume directory fails, sorta
Well, it fails the way that I'm trying to do it. kernel:2.6.31.9-174.fc12.x86_64 btrfs-progs: btrfs-progs-0.19-9.fc12.x86_64 On a new filesystem: $ cd /mnt/btrfs1 $ btrfsctl -S subvol1 . operation complete Btrfs Btrfs v0.19 $ btrfsctl -s snapofsubvol1 subvol1 operation complete Btrfs Btrfs v0.19 $ btrfsctl -D snapofsubvol1 subvol1 ioctl:: No such file or directory $ btrfsctl -S subvol2 . operation complete Btrfs Btrfs v0.19 # cd subvol2 $ btrfsctl -s snapofsubvol2 subvol2 operation complete Btrfs Btrfs v0.19 $ btrfsctl -D snapofsubvol2 subvol2 operation complete Btrfs Btrfs v0.19 AHA, I figured it out! $ btrfsctl -D snapofsubvol1 subvol1/.. I don't know if that's the intended syntax or if it's accidental, but I'll go ahead and send this as an FYI if anyone has the same issue. Maybe it's obvious to some, but it wasn't to me. -- 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
Unable to handle kernel NULL pointer dereference at virtual address 00000008
Hello, I get the following error if I edit fstab with vi on a fresh btrfs filesystem. vi Segfaults at saving the file. # mkfs.btrfs /dev/sda2 # mount /mnt/ # cd / # find . -xdev | cpio -vdump /mnt # vi /mnt/etc/fstab Segmentation fault This also happens with a 'cp -a': # cd /mnt/ # cp etc/fstab tmp/ # cp etc/fstab tmp/ # cp -a etc/fstab tmp/ Segmentation fault And 'ls -l' # cd /mnt/ # ls tmp/ bla fstab network.configured # ls -l tmp/ Segmentation fault Kernel config: CONFIG_BTRFS_FS=y CONFIG_BTRFS_FS_POSIX_ACL=y (I'll try without ACL now, but takes about an hour to compile the kernel). This kernel is a patched 2.6.33-rc1 from git://repo.or.cz/linux-2.6/linux-2.6-openrd.git This error also happens if I remove linux-2.6-openrd/fs/btrfs/ and copy btrfs-unstable/fs/btrfs/ (latetst as of yesterday and this morning). I'm not sure if that is allowed though. # mkfs.btrfs -V mkfs.btrfs, part of Btrfs Btrfs v0.19 The system is Debian Sid on an Openrd-client (ARM). The ssd is an Intel X25-E. I didn't find a similar bugreport. With kind regards, Sander [26055.036656] device fsid 904e5c0206a9b9d1-f00b47d7270b119a devid 1 transid 7 /dev/sda2 [26055.045253] btrfs: use ssd allocation scheme [26678.340511] Unable to handle kernel NULL pointer dereference at virtual address 0008 [26678.348648] pgd = cebb8000 [26678.351367] [0008] *pgd=03127031, *pte=, *ppte= [26678.357691] Internal error: Oops: 17 [#1] [26678.361716] last sysfs file: /sys/kernel/uevent_helper [26678.366878] Modules linked in: [26678.369950] CPU: 0Not tainted (2.6.33-rc1 #1) [26678.374768] PC is at btrfs_get_acl+0x60/0x250 [26678.379142] LR is at btrfs_xattr_get_acl+0x10/0x70 [26678.383956] pc : [c026c294]lr : [c026c494]psr: 2093 [26678.383962] sp : c5199e08 ip : c04fc87c fp : bec451d4 [26678.395498] r10: 00186058 r9 : c5198000 r8 : c0496b5a [26678.400749] r7 : r6 : 8000 r5 : ce0ef600 r4 : 0008 [26678.407307] r3 : 2013 r2 : 2093 r1 : 8000 r0 : 0008 [26678.413864] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [26678.421119] Control: 0005397f Table: 0ebb8000 DAC: 0015 [26678.426891] Process vi (pid: 1033, stack limit = 0xc5198270) [26678.432576] Stack: (0xc5199e08 to 0xc519a000) [26678.436958] 9e00: c5199e70 db119840 0084 c0496b5a c5198000 [26678.445182] 9e20: 00186058 c026c494 c5199e70 0017 c04fc838 c019bb20 c5199e70 [26678.453405] 9e40: ce0ef600 c98734c8 db119840 0084 c5199e70 c019c01c 0084 db119840 [26678.461628] 9e60: bec450c0 ce0ef600 0017 c019c0c4 74737973 702e6d65 7869736f 6c63615f [26678.469851] 9e80: 6363615f 00737365 c5199f18 0001 c98734c8 c018e1e4 [26678.478073] 9ea0: 0001 0371 117ee576 0005 c3ba3009 dfc4a280 ce0ef600 [26678.486297] 9ec0: c5199f18 c5199ee8 c5198000 c3ba3000 c5199f18 c5198000 [26678.494520] 9ee0: c3ba3000 c018e4cc c5199f2c c3ba3000 0001 c5199f18 c3ba3000 [26678.502743] 9f00: c018e57c c04f26f0 c3ba3000 c3ba3000 c018eeb0 dfc4a280 ce0ef600 [26678.510966] 9f20: c5199f30 c5199f48 bec45170 df412400 0001 0001 [26678.519189] 9f40: 00179424 c01883a8 0001f9da 0010 c51981a4 c04f240c d5b20900 [26678.527411] 9f60: 0012 c98734c8 c5199f88 0002 c5199f88 0084 bec450c0 4012f994 [26678.535635] 9f80: c019c220 dfc4a280 ce0ef600 0084 bec450c0 4012c7e8 00e5 [26678.543858] 9fa0: c0122fa4 c0122e20 0084 bec450c0 00186058 4012f994 bec450c0 0084 [26678.552081] 9fc0: 0084 bec450c0 4012c7e8 00e5 0001 00179444 00186058 bec451d4 [26678.560304] 9fe0: bec450b0 bec450a0 40274ecc 401fb5d0 6010 00186058 d5abcade ace1046d [26678.568532] [c026c294] (btrfs_get_acl+0x60/0x250) from [c026c494] (btrfs_xattr_get_acl+0x10/0x70) [26678.577802] [c026c494] (btrfs_xattr_get_acl+0x10/0x70) from [c019bb20] (generic_getxattr+0x78/0x7c) [26678.587243] [c019bb20] (generic_getxattr+0x78/0x7c) from [c019c01c] (vfs_getxattr+0x58/0x5c) [26678.596074] [c019c01c] (vfs_getxattr+0x58/0x5c) from [c019c0c4] (getxattr+0xa4/0x11c) [26678.604298] [c019c0c4] (getxattr+0xa4/0x11c) from [c019c220] (sys_getxattr+0x44/0x58) [26678.612525] [c019c220] (sys_getxattr+0x44/0x58) from [c0122e20] (ret_fast_syscall+0x0/0x28) [26678.621265] Code: 0a77 e10f3000 e3832080 e121f002 (e5942000) [26678.627621] ---[ end trace a16c1078eb68be38 ]--- -- Humilis IT Services and Solutions http://www.humilis.net -- 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
Re: Unable to handle kernel NULL pointer dereference at virtual address 00000008
Sander wrote (ao): I get the following error if I edit fstab with vi on a fresh btrfs filesystem. vi Segfaults at saving the file. # mkfs.btrfs /dev/sda2 # mount /mnt/ # cd / # find . -xdev | cpio -vdump /mnt # vi /mnt/etc/fstab Segmentation fault This also happens with a 'cp -a': # cd /mnt/ # cp etc/fstab tmp/ # cp etc/fstab tmp/ # cp -a etc/fstab tmp/ Segmentation fault And 'ls -l' # cd /mnt/ # ls tmp/ bla fstab network.configured # ls -l tmp/ Segmentation fault Kernel config: CONFIG_BTRFS_FS=y CONFIG_BTRFS_FS_POSIX_ACL=y (I'll try without ACL now, but takes about an hour to compile the kernel). Without CONFIG_BTRFS_FS_POSIX_ACL I can't reproduce the segfaults. With kind regards, Sander This kernel is a patched 2.6.33-rc1 from git://repo.or.cz/linux-2.6/linux-2.6-openrd.git This error also happens if I remove linux-2.6-openrd/fs/btrfs/ and copy btrfs-unstable/fs/btrfs/ (latetst as of yesterday and this morning). I'm not sure if that is allowed though. # mkfs.btrfs -V mkfs.btrfs, part of Btrfs Btrfs v0.19 The system is Debian Sid on an Openrd-client (ARM). The ssd is an Intel X25-E. I didn't find a similar bugreport. With kind regards, Sander [26055.036656] device fsid 904e5c0206a9b9d1-f00b47d7270b119a devid 1 transid 7 /dev/sda2 [26055.045253] btrfs: use ssd allocation scheme [26678.340511] Unable to handle kernel NULL pointer dereference at virtual address 0008 [26678.348648] pgd = cebb8000 [26678.351367] [0008] *pgd=03127031, *pte=, *ppte= [26678.357691] Internal error: Oops: 17 [#1] [26678.361716] last sysfs file: /sys/kernel/uevent_helper [26678.366878] Modules linked in: [26678.369950] CPU: 0Not tainted (2.6.33-rc1 #1) [26678.374768] PC is at btrfs_get_acl+0x60/0x250 [26678.379142] LR is at btrfs_xattr_get_acl+0x10/0x70 [26678.383956] pc : [c026c294]lr : [c026c494]psr: 2093 [26678.383962] sp : c5199e08 ip : c04fc87c fp : bec451d4 [26678.395498] r10: 00186058 r9 : c5198000 r8 : c0496b5a [26678.400749] r7 : r6 : 8000 r5 : ce0ef600 r4 : 0008 [26678.407307] r3 : 2013 r2 : 2093 r1 : 8000 r0 : 0008 [26678.413864] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [26678.421119] Control: 0005397f Table: 0ebb8000 DAC: 0015 [26678.426891] Process vi (pid: 1033, stack limit = 0xc5198270) [26678.432576] Stack: (0xc5199e08 to 0xc519a000) [26678.436958] 9e00: c5199e70 db119840 0084 c0496b5a c5198000 [26678.445182] 9e20: 00186058 c026c494 c5199e70 0017 c04fc838 c019bb20 c5199e70 [26678.453405] 9e40: ce0ef600 c98734c8 db119840 0084 c5199e70 c019c01c 0084 db119840 [26678.461628] 9e60: bec450c0 ce0ef600 0017 c019c0c4 74737973 702e6d65 7869736f 6c63615f [26678.469851] 9e80: 6363615f 00737365 c5199f18 0001 c98734c8 c018e1e4 [26678.478073] 9ea0: 0001 0371 117ee576 0005 c3ba3009 dfc4a280 ce0ef600 [26678.486297] 9ec0: c5199f18 c5199ee8 c5198000 c3ba3000 c5199f18 c5198000 [26678.494520] 9ee0: c3ba3000 c018e4cc c5199f2c c3ba3000 0001 c5199f18 c3ba3000 [26678.502743] 9f00: c018e57c c04f26f0 c3ba3000 c3ba3000 c018eeb0 dfc4a280 ce0ef600 [26678.510966] 9f20: c5199f30 c5199f48 bec45170 df412400 0001 0001 [26678.519189] 9f40: 00179424 c01883a8 0001f9da 0010 c51981a4 c04f240c d5b20900 [26678.527411] 9f60: 0012 c98734c8 c5199f88 0002 c5199f88 0084 bec450c0 4012f994 [26678.535635] 9f80: c019c220 dfc4a280 ce0ef600 0084 bec450c0 4012c7e8 00e5 [26678.543858] 9fa0: c0122fa4 c0122e20 0084 bec450c0 00186058 4012f994 bec450c0 0084 [26678.552081] 9fc0: 0084 bec450c0 4012c7e8 00e5 0001 00179444 00186058 bec451d4 [26678.560304] 9fe0: bec450b0 bec450a0 40274ecc 401fb5d0 6010 00186058 d5abcade ace1046d [26678.568532] [c026c294] (btrfs_get_acl+0x60/0x250) from [c026c494] (btrfs_xattr_get_acl+0x10/0x70) [26678.577802] [c026c494] (btrfs_xattr_get_acl+0x10/0x70) from [c019bb20] (generic_getxattr+0x78/0x7c) [26678.587243] [c019bb20] (generic_getxattr+0x78/0x7c) from [c019c01c] (vfs_getxattr+0x58/0x5c) [26678.596074] [c019c01c] (vfs_getxattr+0x58/0x5c) from [c019c0c4] (getxattr+0xa4/0x11c) [26678.604298] [c019c0c4] (getxattr+0xa4/0x11c) from [c019c220] (sys_getxattr+0x44/0x58) [26678.612525] [c019c220] (sys_getxattr+0x44/0x58) from [c0122e20] (ret_fast_syscall+0x0/0x28) [26678.621265] Code: 0a77 e10f3000 e3832080 e121f002 (e5942000) [26678.627621] ---[ end trace a16c1078eb68be38 ]--- -- Humilis IT Services and Solutions http://www.humilis.net -- 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
