Re: [GIT PULL] Btrfs pull request
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 > > Thanks a lot for your time, > Andrea -- 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 v2 3/3] xfstests 275: add a write and reserve test
This test is for write-posix test. If writing a file when the disk is almost
full, the posix wants the call to write as much as possible but not none.
quote the POSIX:
If a write() requests that more bytes be written than there is room for
(for example, [XSI] [Option Start] the process' file size limit or
[Option End] the physical end of a medium), only as many bytes as there
is room for shall be written. For example, suppose there is space for 20
bytes more in a file before reaching a limit. A write of 512 bytes will
return 20. The next write of a non-zero number of bytes would give a
failure return (except as noted below).
Signed-off-by: Wu Bo
---
275 | 89 +++
275.out |5 +++
group |1 +
3 files changed, 95 insertions(+), 0 deletions(-)
create mode 100755 275
create mode 100644 275.out
diff --git a/275 b/275
new file mode 100755
index 000..214262e
--- /dev/null
+++ b/275
@@ -0,0 +1,89 @@
+#! /bin/bash
+# FS QA Test No. 275
+#
+# The posix write test. when write size is larger than disk free size,
+# should write as more as possible
+#
+#---
+# Copyright (c) 2011-2012 Fujitsu, Inc. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+#---
+#
+#creator
+owner=wu...@cn.fujitsu.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=0# success is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+ cd /
+ rm -f $SCRATCH_MNT/* $tmp.*
+ _scratch_unmount
+}
+
+. ./common.rc
+. ./common.filter
+
+# real QA test starts here
+_supported_fs generic
+_supported_os IRIX Linux
+_require_scratch
+
+echo "--"
+echo "write lack test"
+echo "--"
+
+rm -f $seq.full
+
+umount $SCRATCH_DEV 2>/dev/null
+_scratch_mkfs_sized $((1 * 1024 * 1024 * 1024)) >>$seq.full 2>&1
+_scratch_mount
+
+rm -rf $SCRATCH_MNT/*
+cd $SCRATCH_MNT
+
+dd if=/dev/zero of=tmp1 bs=4K count=1 >/dev/null 2>&1
+if [ $? -ne 0 ]
+then
+ echo "create file err"
+ status=1
+ exit
+fi
+
+dd if=/dev/zero of=tmp2 bs=1M >/dev/null 2>&1
+dd if=/dev/zero of=tmp3 bs=4K >/dev/null 2>&1
+sync
+
+rm -f tmp1
+sync
+
+dd if=/dev/zero of=tmp1 bs=8K count=1 >/dev/null 2>&1
+_filesize=`du tmp1 | awk '{print $1}'`
+if [ $_filesize -ne 4 ]
+then
+ echo "write file err"
+ status=1
+ exit
+fi
+
+echo "done"
+exit
diff --git a/275.out b/275.out
new file mode 100644
index 000..30af43c
--- /dev/null
+++ b/275.out
@@ -0,0 +1,5 @@
+QA output created by 275
+--
+write lack test
+--
+done
diff --git a/group b/group
index 44a..8c6 100644
--- a/group
+++ b/group
@@ -388,3 +388,4 @@ deprecated
272 auto enospc rw
273 auto rw
274 auto rw
+275 auto rw
--
1.7.3.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
[PATCH v2 2/3] xfstests 274: add a prealloc and reserve test
This test is for preallocation test. If the disk is full, just with a prealloc
file has some free space that prealloc early. We need to check whether the write
to the free space is success or not.
Signed-off-by: Wu Bo
---
274 | 91 +++
274.out |5 +++
group |1 +
3 files changed, 97 insertions(+), 0 deletions(-)
create mode 100755 274
create mode 100644 274.out
diff --git a/274 b/274
new file mode 100755
index 000..b658004
--- /dev/null
+++ b/274
@@ -0,0 +1,91 @@
+#! /bin/bash
+# FS QA Test No. 274
+#
+# preallocation test
+#
+#---
+# Copyright (c) 2011-2012 Fujitsu, Inc. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+#---
+#
+#creator
+owner=wu...@cn.fujitsu.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=0# success is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+ cd /
+ rm -f $SCRATCH_MNT/* $tmp.*
+ _scratch_unmount
+}
+
+. ./common.rc
+. ./common.filter
+
+# real QA test starts here
+_supported_fs generic
+_supported_os IRIX Linux
+_require_scratch
+
+echo "--"
+echo "preallocation test"
+echo "--"
+
+rm -f $seq.full
+
+umount $SCRATCH_DEV 2>/dev/null
+_scratch_mkfs_sized $((1 * 1024 * 1024 * 1024)) >>$seq.full 2>&1
+_scratch_mount
+
+rm -rf $SCRATCH_MNT/*
+cd $SCRATCH_MNT
+dd if=/dev/zero of=test bs=4K count=1 >/dev/null 2>&1
+if [ $? -ne 0 ]
+then
+ echo "create file err"
+ status=1
+ exit
+fi
+
+fallocate -n -o 4K -l 1M test >/dev/null 2>&1
+if [ $? -ne 0 ]
+then
+ echo "fallocate file err"
+ status=1
+ exit
+fi
+
+dd if=/dev/zero of=tmp1 bs=1M >/dev/null 2>&1
+dd if=/dev/zero of=tmp2 bs=4K >/dev/null 2>&1
+sync
+
+dd if=/dev/zero of=test seek=1 bs=4K count=2 conv=notrunc >/dev/null 2>&1
+if [ $? -ne 0 ]
+then
+ echo "fill prealloc range err"
+ status=1
+ exit
+fi
+
+echo "done"
+exit
diff --git a/274.out b/274.out
new file mode 100644
index 000..edbf3cc
--- /dev/null
+++ b/274.out
@@ -0,0 +1,5 @@
+QA output created by 274
+--
+preallocation test
+--
+done
diff --git a/group b/group
index b8245bf..44a 100644
--- a/group
+++ b/group
@@ -387,3 +387,4 @@ deprecated
271 auto rw quick
272 auto enospc rw
273 auto rw
+274 auto rw
--
1.7.3.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
[PATCH v2 1/3] xfstests 273: add a copy and reserve test
This test is a stress test. It creates a set of threads for coping small files
into disk. I use a 2G disk for test, the ENOSPC arises usually but the disk is
not full under kenerl 3.0 with intel64.
Signed-off-by: Wu Bo
---
273 | 145 +++
273.out |4 ++
group |1 +
3 files changed, 150 insertions(+), 0 deletions(-)
create mode 100755 273
create mode 100644 273.out
diff --git a/273 b/273
new file mode 100755
index 000..2965132
--- /dev/null
+++ b/273
@@ -0,0 +1,145 @@
+#! /bin/bash
+# FS QA Test No. 273
+#
+# reservation test with heavy cp workload
+#
+#---
+# Copyright (c) 2011-2012 Fujitsu, Inc. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+#---
+#
+#creator
+owner=wu...@cn.fujitsu.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=0 # success is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+ cd /
+ rm -rf $SCRATCH_MNT/* $tmp.*
+ _scratch_unmount
+}
+
+. ./common.rc
+. ./common.filter
+
+threads=50
+count=1
+
+_threads_set()
+{
+ _cpu_num=`cat /proc/cpuinfo | grep "processor" | wc -l`
+ threads=$(($_cpu_num * 50))
+ if [ $threads -gt 200 ]
+ then
+ threads=200
+ fi
+}
+
+_file_create()
+{
+ _i=0
+
+ if ! mkdir $SCRATCH_MNT/origin
+ then
+ echo "mkdir origin err"
+ status=1
+ exit
+ fi
+
+ cd $SCRATCH_MNT/origin
+
+ _disksize=`df --block-size=1 | grep $SCRATCH_DEV | awk '{print $2}'`
+ _disksize=$(($_disksize / 3))
+ _num=$(($_disksize / $count / $threads / 4096))
+ _count=$count
+ while [ $_i -lt $_num ]
+ do
+ dd if=/dev/zero of=file_$_i bs=4096 count=$_count >/dev/null
2>&1
+ _i=$(($_i + 1))
+ done
+
+ cd $here
+}
+
+_porter()
+{
+ _suffix=$1
+
+ if ! mkdir $SCRATCH_MNT/sub_$_suffix
+ then
+ echo "mkdir sub_xxx err"
+ status=1
+ exit
+ fi
+
+ cp -r $SCRATCH_MNT/origin $SCRATCH_MNT/sub_$_suffix >$seq.full 2>&1
+ if [ $? -ne 0 ]
+ then
+ echo "_porter $_suffix not complete"
+ fi
+
+ sync
+}
+
+_do_workload()
+{
+ _pids=""
+ _pid=1
+
+ rm -rf $SCRATCH_MNT/*
+
+ _threads_set
+ _file_create
+
+ _threads=$threads
+
+ while [ $_pid -lt $_threads ]
+ do
+ _porter $_pid &
+ _pids="$_pids $!"
+ _pid=$(($_pid + 1))
+ done
+
+ wait $_pids
+}
+
+# real QA test starts here
+_supported_fs generic
+_supported_os IRIX Linux
+_require_scratch
+
+echo "--"
+echo "start the workload"
+echo "--"
+
+rm -f $seq.full
+
+umount $SCRATCH_DEV 2>/dev/null
+_scratch_mkfs_sized $((2 * 1024 * 1024 * 1024)) >>$seq.full 2>&1
+_scratch_mount
+
+_do_workload
+
+_check_scratch_fs
+status=$?
+exit
diff --git a/273.out b/273.out
new file mode 100644
index 000..146af43
--- /dev/null
+++ b/273.out
@@ -0,0 +1,4 @@
+QA output created by 273
+--
+start the workload
+--
diff --git a/group b/group
index 616cbdd..b8245bf 100644
--- a/group
+++ b/group
@@ -386,3 +386,4 @@ deprecated
270 auto quota rw prealloc ioctl enospc
271 auto rw quick
272 auto enospc rw
+273 auto rw
--
1.7.3.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
[PATCH v2 0/3] xfstests: Add a group of reservation space test
Changes v1->v2: - Make test-set support generic This patch set add a group of reservation space test. Especailly for btrfs. It includes three parts: copy workload, prealloc and write posix. For test 273, I hope it's usefull for Josef's reserve improve work. For test 274 and 275, the current btrfs is not pass yet. Wu Bo (3): xfstests 273: add a copy and reserve test xfstests 274: add a prealloc and reserve test xfstests 275: add a write and reserve test 273 | 145 +++ 273.out |4 ++ 274 | 91 +++ 274.out |5 ++ 275 | 89 ++ 275.out |5 ++ group |3 + 7 files changed, 342 insertions(+), 0 deletions(-) create mode 100755 273 create mode 100644 273.out create mode 100755 274 create mode 100644 274.out create mode 100755 275 create mode 100644 275.out -- 1.7.3.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
Re: How to remount btrfs without compression?
On 11/08/2011 10:54 AM, Eric Griffith wrote: On 11/7/2011 8:52 PM, Fajar A. Nugraha wrote: On Tue, Nov 8, 2011 at 8:06 AM, Eric Griffith wrote: Edit your fstab, remove the compress flag, reboot. Tell btrfs to rebalance the system, reboot again. And I -THINK- that'll decompress all the files I think the original question was how to force uncompressed mode, whether specific to a file or to a whole filesystem, without having to reboot :) AFAIK there's no way to do that. Whoops! Misunderstood the question haha. Yeah, as far as decompressing just a single file; from what I've read, thats impossible. Eric, Fajar, Thanks. Understood. Yes, it is possible to remove the compress flag from fstab, reboot and even do not do any defragmentation/rebalancing - just re-save the file and it will be saved uncompressed. This works. But only with reboot... -- 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: How to remount btrfs without compression?
On 11/7/2011 8:52 PM, Fajar A. Nugraha wrote: On Tue, Nov 8, 2011 at 8:06 AM, Eric Griffith wrote: Edit your fstab, remove the compress flag, reboot. Tell btrfs to rebalance the system, reboot again. And I -THINK- that'll decompress all the files I think the original question was how to force uncompressed mode, whether specific to a file or to a whole filesystem, without having to reboot :) AFAIK there's no way to do that. Whoops! Misunderstood the question haha. Yeah, as far as decompressing just a single file; from what I've read, thats impossible. -- 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: How to remount btrfs without compression?
On Tue, Nov 8, 2011 at 8:06 AM, Eric Griffith wrote: > Edit your > fstab, remove the compress flag, reboot. Tell btrfs to rebalance the system, > reboot again. And I -THINK- that'll decompress all the files I think the original question was how to force uncompressed mode, whether specific to a file or to a whole filesystem, without having to reboot :) AFAIK there's no way to do that. -- Fajar -- 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: WARNING: at fs/btrfs/extent-tree.c:124
On Tue, Nov 08, 2011 at 09:09:18AM +0900, Tsutomu Itoh wrote: > (2011/11/08 1:12), Chris Mason wrote: > > On Mon, Nov 07, 2011 at 02:10:29PM +0900, Tsutomu Itoh wrote: > >> In for-linus branch, when xfstests was executed, the following warning > >> messages were output. > > > > Dave Sterba and I were consistently getting these last week, but after > > fixes from Josef and I in the current branch I thought they were fixed. > > > > Do this come up every time? > > No. > Although I am running xfstests from yesterday, it is only one time that > this message was output. > > > > > Which mount options were you using? > > # mount > ... > /dev/sdd4 on /test7 type btrfs (rw) Ok, I'm struggling to reproduce this one. Looks like three of us have hit it once and only once. -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: How to remount btrfs without compression?
On 11/7/2011 7:55 PM, dima wrote: On 11/07/2011 09:19 PM, Martin Steigerwald wrote: Am Montag, 7. November 2011 schrieb dima: Hello, Hi Dima, Is there any possibility to remount a compressed btrfs without any compression at all? Syslinux bootloader does not understand any btrfs compression and whenever I edit syslinux.cfg on my compressed / subvolume, the file becomes compressed and thus unreadable by syslinux on the next boot. I tried to remount / without the 'compress' option (and edit syslinux.cfg in uncompressed state) and while the "mount" command would not show compression any more, I can see in the /proc/mounts that compression is still there and the file still gets compressed after editing. But there seem to be no mount option like compress=none or something. The only workaround I found is to boot from a live CD mount / without any compression and re-save syslinux.cfg. Then it the file gets uncompressed. Are there any other options except for this workaround to temporarily remount btrfs without compression? What does lsattr show on the file? Have you tried chattr -c on the file? It might help to do a btrfs filesystem defrag on the file to remove compression, cause I don´t think chattr -c itself will uncompress it. Hi Martin, Thanks for your reply. Yes, I did check out lsattr. It shows that no flags are set. Setting chattr +c then chattr -c and re-saving file has no effect either. I also tried to defragment the file itself and the directory where it was in without setting -c but it would not have any effect because / is mounted with compression. As far as I understand it is possible to individually set compression on/off on single files. Could not find how to turn it off though. 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 Hey Dima, I know if you install a system without the compress flag already done, you can force BTRFS to compress everything post-install by teling it to "rebalance" the filesystem. I'm under Win7 right now so I dont know the exact command. Check btrfs --help for that. I dont know if it works in reverse, but you can definitely try it. Edit your fstab, remove the compress flag, reboot. Tell btrfs to rebalance the system, reboot again. And I -THINK- that'll decompress all the files -- 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: How to remount btrfs without compression?
On 11/07/2011 09:19 PM, Martin Steigerwald wrote: Am Montag, 7. November 2011 schrieb dima: Hello, Hi Dima, Is there any possibility to remount a compressed btrfs without any compression at all? Syslinux bootloader does not understand any btrfs compression and whenever I edit syslinux.cfg on my compressed / subvolume, the file becomes compressed and thus unreadable by syslinux on the next boot. I tried to remount / without the 'compress' option (and edit syslinux.cfg in uncompressed state) and while the "mount" command would not show compression any more, I can see in the /proc/mounts that compression is still there and the file still gets compressed after editing. But there seem to be no mount option like compress=none or something. The only workaround I found is to boot from a live CD mount / without any compression and re-save syslinux.cfg. Then it the file gets uncompressed. Are there any other options except for this workaround to temporarily remount btrfs without compression? What does lsattr show on the file? Have you tried chattr -c on the file? It might help to do a btrfs filesystem defrag on the file to remove compression, cause I don´t think chattr -c itself will uncompress it. Hi Martin, Thanks for your reply. Yes, I did check out lsattr. It shows that no flags are set. Setting chattr +c then chattr -c and re-saving file has no effect either. I also tried to defragment the file itself and the directory where it was in without setting -c but it would not have any effect because / is mounted with compression. As far as I understand it is possible to individually set compression on/off on single files. Could not find how to turn it off though. 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: BUG at fs/btrfs/inode.c:1795
(2011/11/07 21:50), David Sterba wrote: > Hi, > > I saw this BUG in current linus' (with last pull included) to quickly > trigger in xfstests/013, with freshly created fs and default raid flags. I encountered the same panic this morning, too. My mount option is, mount option: compress=lzo [50511.410486] device fsid cb6a6bb3-1f5d-465f-816b-be814e2d022f devid 1 transid 62154 /dev/sdd4 [50511.411385] btrfs: use lzo compression [50511.411388] btrfs: disk space caching is enabled [50519.386248] [ cut here ] [50519.386476] kernel BUG at fs/btrfs/inode.c:1795! [50519.386690] invalid opcode: [#1] SMP [50519.386906] CPU 0 [50519.386912] Modules linked in: btrfs nfsd lockd nfs_acl auth_rpcgss autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf cachefiles fscache ipv6 zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif megaraid_sas sr_mod cdrom floppy pata_acpi ata_generic ata_piix libata scsi_mod [last unloaded: btrfs] [50519.387140] [50519.387140] Pid: 32181, comm: btrfs-endio-wri Tainted: GW 3.1.0mod+ #1 FUJITSU-SV PRIMERGY/D2399 [50519.387140] RIP: 0010:[] [] btrfs_finish_ordered_io+0x269/0x2cf [btrfs] [50519.387140] RSP: 0018:88015d5a3ca0 EFLAGS: 00010286 [50519.387140] RAX: ffe4 RBX: 880085a6f400 RCX: 88015d5a3bb0 [50519.387140] RDX: RSI: 880190f317e0 RDI: 880190f31828 [50519.387140] RBP: 88015d5a3d10 R08: 88015d5a3bf0 R09: 813a7bad [50519.387140] R10: 88015d5a3b30 R11: 0800 R12: 88006c4ce2d0 [50519.387140] R13: 88017e83ef50 R14: 000b9f00 R15: 88017e83edc0 [50519.387140] FS: () GS:88019fc0() knlGS: [50519.387140] CS: 0010 DS: ES: CR0: 8005003b [50519.387140] CR2: 0033cfe844e0 CR3: 00019537b000 CR4: 06f0 [50519.387140] DR0: DR1: DR2: [50519.387140] DR3: DR6: 0ff0 DR7: 0400 [50519.387140] Process btrfs-endio-wri (pid: 32181, threadinfo 88015d5a2000, task 88018c9ead60) [50519.387140] Stack: [50519.387140] 88016add3298 88017e83f0b0 0282 [50519.387140] 88015d5a3ce0 88017e83edf0 88018c94c0c0 [50519.387140] 88015d5a3d30 880160afbff0 ea0004dfcc80 000b9000 [50519.387140] Call Trace: [50519.387140] [] btrfs_writepage_end_io_hook+0x5f/0x79 [btrfs] [50519.387140] [] end_bio_extent_writepage+0xae/0x159 [btrfs] [50519.387140] [] bio_endio+0x2d/0x2f [50519.387140] [] end_workqueue_fn+0x111/0x120 [btrfs] [50519.387140] [] worker_loop+0x18a/0x4bb [btrfs] [50519.387140] [] ? btrfs_queue_worker+0x224/0x224 [btrfs] [50519.387140] [] ? btrfs_queue_worker+0x224/0x224 [btrfs] [50519.387140] [] kthread+0x82/0x8a [50519.387140] [] kernel_thread_helper+0x4/0x10 [50519.387140] [] ? kthread_worker_fn+0x14a/0x14a [50519.387140] [] ? gs_change+0x13/0x13 [50519.387140] Code: f6 4c 89 ef e8 e0 b4 00 00 85 c0 74 0c 48 8b 45 c8 48 8b 40 28 a8 10 75 16 4c 89 ea 48 89 de 4c 89 e7 e8 4c c4 ff ff 85 c0 74 04 <0f> 0b eb fe 48 8b 83 20 01 00 00 48 3b 58 28 74 10 48 8b 45 c8 [50519.387140] RIP [] btrfs_finish_ordered_io+0x269/0x2cf [btrfs] [50519.387140] RSP -Tsutomu > > [ 528.458613] [ cut here ] > [ 528.461489] kernel BUG at fs/btrfs/inode.c:1795! > [ 528.461489] invalid opcode: [#1] SMP > [ 528.461489] CPU 1 > [ 528.461489] Modules linked in: loop btrfs aoe > [ 528.461489] > [ 528.461489] Pid: 8862, comm: btrfs-endio-wri Not tainted 3.1.0-default+ > #67 Intel Corporation Santa Rosa platform/Matanzas > [ 528.461489] RIP: 0010:[] [] > btrfs_finish_ordered_io+0x287/0x320 [btrfs] > [ 528.461489] RSP: 0018:880079809c80 EFLAGS: 00010286 > [ 528.461489] RAX: ffe4 RBX: 88007a15d000 RCX: > > [ 528.461489] RDX: 880079540440 RSI: 0001 RDI: > 0246 > [ 528.461489] RBP: 880079809cf0 R08: 0001 R09: > 0001 > [ 528.461489] R10: R11: R12: > 88006db1c3f0 > [ 528.461489] R13: 88007620ecd8 R14: R15: > 88006db1c000 > [ 528.461489] FS: () GS:88007de0() > knlGS: > [ 528.461489] CS: 0010 DS: ES: CR0: 8005003b > [ 528.461489] CR2: 7f5724ca4000 CR3: 7a127000 CR4: > 06e0 > [ 528.461489] DR0: DR1: DR2: > > [ 528.461489] DR3: DR6: 0ff0 DR7: > 0400 > [ 528.461489] Process btrfs-endio-
Re: WARNING: at fs/btrfs/extent-tree.c:124
(2011/11/08 1:12), Chris Mason wrote: > On Mon, Nov 07, 2011 at 02:10:29PM +0900, Tsutomu Itoh wrote: >> In for-linus branch, when xfstests was executed, the following warning >> messages were output. > > Dave Sterba and I were consistently getting these last week, but after > fixes from Josef and I in the current branch I thought they were fixed. > > Do this come up every time? No. Although I am running xfstests from yesterday, it is only one time that this message was output. > > Which mount options were you using? # mount ... /dev/sdd4 on /test7 type btrfs (rw) Thanks, Tsutomu > > -chris > >> >> Thanks, >> Tsutomu >> >> === >> >> Nov 7 13:51:00 luna kernel: [ 824.063444] device fsid >> 2f0ad8a9-93d5-4c99-837f-9db99543133b devid 1 transid 1822 /dev/sdd4 >> Nov 7 13:51:00 luna kernel: [ 824.063946] btrfs: disk space caching is >> enabled >> Nov 7 13:51:00 luna kernel: [ 824.097652] block group 1103101952 has an >> wrong amount of free space >> Nov 7 13:51:00 luna kernel: [ 824.097873] btrfs: failed to load free space >> cache for block group 1103101952 >> Nov 7 13:51:01 luna kernel: [ 824.413821] [ cut here >> ] >> Nov 7 13:51:01 luna kernel: [ 824.413855] WARNING: at >> fs/btrfs/extent-tree.c:124 btrfs_put_block_group+0x4f/0x67 [btrfs]() >> Nov 7 13:51:01 luna kernel: [ 824.413858] Hardware name: PRIMERGY >> Nov 7 13:51:01 luna kernel: [ 824.413860] Modules linked in: btrfs >> zlib_deflate crc32c libcrc32c nfsd lockd nfs_acl auth_rpcgss autofs4 sunrpc >> 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf cachefiles >> fscache ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput >> ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt >> iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache >> jbd2 crc16 sd_mod crc_t10dif megaraid_sas sr_mod cdrom floppy pata_acpi >> ata_generic ata_piix libata scsi_mod [last unloaded: microcode] >> Nov 7 13:51:01 luna kernel: [ 824.413915] Pid: 7472, comm: umount Not >> tainted 3.1.0mod+ #1 >> Nov 7 13:51:01 luna kernel: [ 824.413917] Call Trace: >> Nov 7 13:51:01 luna kernel: [ 824.413925] [] >> warn_slowpath_common+0x85/0x9d >> Nov 7 13:51:01 luna kernel: [ 824.413929] [] >> warn_slowpath_null+0x1a/0x1c >> Nov 7 13:51:01 luna kernel: [ 824.413943] [] >> btrfs_put_block_group+0x4f/0x67 [btrfs] >> Nov 7 13:51:01 luna kernel: [ 824.413956] [] >> btrfs_free_block_groups+0xde/0x258 [btrfs] >> Nov 7 13:51:01 luna kernel: [ 824.413973] [] >> close_ctree+0x22c/0x325 [btrfs] >> Nov 7 13:51:01 luna kernel: [ 824.413978] [] ? >> dispose_list+0x3e/0x4f >> Nov 7 13:51:01 luna kernel: [ 824.413989] [] >> btrfs_put_super+0x1d/0x2c [btrfs] >> Nov 7 13:51:01 luna kernel: [ 824.413994] [] >> generic_shutdown_super+0x5b/0xba >> Nov 7 13:51:01 luna kernel: [ 824.413998] [] >> kill_anon_super+0x16/0x22 >> Nov 7 13:51:01 luna kernel: [ 824.414002] [] >> deactivate_locked_super+0x26/0x57 >> Nov 7 13:51:01 luna kernel: [ 824.414006] [] >> deactivate_super+0x45/0x4c >> Nov 7 13:51:01 luna kernel: [ 824.414010] [] >> mntput_no_expire+0x143/0x14c >> Nov 7 13:51:01 luna kernel: [ 824.414822] [] >> sys_umount+0x2d9/0x304 >> Nov 7 13:51:01 luna kernel: [ 824.414838] [] ? >> path_put+0x22/0x26 >> Nov 7 13:51:01 luna kernel: [ 824.414846] [] >> system_call_fastpath+0x16/0x1b >> Nov 7 13:51:01 luna kernel: [ 824.414852] ---[ end trace 1167c1ef9b771b7f >> ]--- >> Nov 7 13:51:01 luna kernel: [ 824.418017] [ cut here >> ] >> Nov 7 13:51:01 luna kernel: [ 824.418039] WARNING: at >> fs/btrfs/extent-tree.c:7158 btrfs_free_block_groups+0x220/0x258 [btrfs]() >> Nov 7 13:51:01 luna kernel: [ 824.418042] Hardware name: PRIMERGY >> Nov 7 13:51:01 luna kernel: [ 824.418044] Modules linked in: btrfs >> zlib_deflate crc32c libcrc32c nfsd lockd nfs_acl auth_rpcgss autofs4 sunrpc >> 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf cachefiles >> fscache ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput >> ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt >> iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache >> jbd2 crc16 sd_mod crc_t10dif megaraid_sas sr_mod cdrom floppy pata_acpi >> ata_generic ata_piix libata scsi_mod [last unloaded: microcode] >> Nov 7 13:51:01 luna kernel: [ 824.418107] Pid: 7472, comm: umount Tainted: >> GW 3.1.0mod+ #1 >> Nov 7 13:51:01 luna kernel: [ 824.418110] Call Trace: >> Nov 7 13:51:01 luna kernel: [ 824.418117] [] >> warn_slowpath_common+0x85/0x9d >> Nov 7 13:51:01 luna kernel: [ 824.418121] [] >> warn_slowpath_null+0x1a/0x1c >> Nov 7 13:51:01 luna kernel: [ 824.418137] [] >> btrfs_free_block_groups+0x220/0x258 [btrfs] >> Nov 7 13:51:01 luna kernel: [ 824.418157] [] >> close_ctree+0x22c/0x325
Re: grub-1.99 and btrfs-only
On 07/11/11 22:07, Phillip Susi wrote: > (...) > > I'm still getting a "sparse file not allowed" error during boot, and > have to press enter to continue though. Still not tracked that one down. https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/736743 Missing feature in GRUB, see Colin Watson's comments in partucular. -- 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: grub-1.99 and btrfs-only
On 11/5/2011 10:02 PM, Chuck Burns wrote: These are my current subvolumes: # btrfs sub list / ID 256 top level 5 path mainroot ID 257 top level 5 path home I have sub 256 set as default, and then home is mounted onto mainroot. I advise against using set-default at all. The setup Ubuntu seems to be going for ( and is working well for me so far ) creates two subvolumes under the default root, named @ and @home, and intended to be mounted in / and /home respectively. The /@ subvolume is then mounted as the root via rootflags=subvol=@ argument, and grub is configured to use /@/boot/grub as its prefix directory. I'm still getting a "sparse file not allowed" error during boot, and have to press enter to continue though. Still not tracked that one down. -- 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: could not do orphan cleanup -116
On Mon, Nov 07, 2011 at 06:41:44PM +, Maciej Marcin Piechotka wrote: > On Mon, 2011-11-07 at 10:29 -0500, Josef Bacik wrote: > > On Mon, Nov 07, 2011 at 01:17:04PM +, Maciej Marcin Piechotka wrote: > > > Hello, > > > > > > When I booted my machine (after clean powerdown) the following message > > > appeared: > > > [ 32.757913] device fsid ---- devid 1 > > > transid 40864 /dev/mapper/X-X > > > [ 32.758466] btrfs: use lzo compression > > > [ 32.758475] btrfs: enabling disk space caching > > > [ 32.758483] btrfs: enabling inode map caching > > > [ 32.758490] btrfs: enabling auto defrag > > > [ 32.758497] btrfs: thread pool 2 > > > [ 34.024359] btrfs: could not do orphan cleanup -116 > > > [ 63.173382] btrfs: open_ctree failed > > > > > > btrfsck has shown no errors. > > > > > > Afterwards when I tried to mount filesystem it have shown: > > > > > > [ 116.012528] btrfs: enabling inode map caching > > > [ 116.012534] btrfs: enabling auto defrag > > > [ 116.012542] btrfs: thread pool 2 > > > > > > It looked like everything is working but to be sure I've run scrub: > > > > > > scrub status for fsid ---- > > > scrub started at Mon Nov 7 13:05:50 2011 and finished after 606 > > > seconds > > > total bytes scrubbed: 32.37GB with 0 errors > > > > > > PS. > > > # find include | xargs grep 116 > > > (...) > > > include/asm-generic/errno.h:#define ESTALE 116 /* Stale > > > NFS file handle */ > > > (...) > > > > > > I don't use NFS - I use LVM on LUKS. In any case - it have been done > > > concurrently with mounting of other fs which had no such problems. > > > > Yeah that's a bug with an earlier kernel, if you upgrade to 3.1 it should go > > away. Thanks, > > > > Josef > > > I'm using 'newer' kernel then 3.1 - I'm following Linus' tree (this > kernel is few days old). > Do you have the commit a8c9e5769718d47e87cce40c9b84cab421804797 Btrfs: fix orphan cleanup regression If not then the kernel isn't new enough. Thanks, Josef -- 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: could not do orphan cleanup -116
On Mon, 2011-11-07 at 10:29 -0500, Josef Bacik wrote: > On Mon, Nov 07, 2011 at 01:17:04PM +, Maciej Marcin Piechotka wrote: > > Hello, > > > > When I booted my machine (after clean powerdown) the following message > > appeared: > > [ 32.757913] device fsid ---- devid 1 > > transid 40864 /dev/mapper/X-X > > [ 32.758466] btrfs: use lzo compression > > [ 32.758475] btrfs: enabling disk space caching > > [ 32.758483] btrfs: enabling inode map caching > > [ 32.758490] btrfs: enabling auto defrag > > [ 32.758497] btrfs: thread pool 2 > > [ 34.024359] btrfs: could not do orphan cleanup -116 > > [ 63.173382] btrfs: open_ctree failed > > > > btrfsck has shown no errors. > > > > Afterwards when I tried to mount filesystem it have shown: > > > > [ 116.012528] btrfs: enabling inode map caching > > [ 116.012534] btrfs: enabling auto defrag > > [ 116.012542] btrfs: thread pool 2 > > > > It looked like everything is working but to be sure I've run scrub: > > > > scrub status for fsid ---- > > scrub started at Mon Nov 7 13:05:50 2011 and finished after 606 > > seconds > > total bytes scrubbed: 32.37GB with 0 errors > > > > PS. > > # find include | xargs grep 116 > > (...) > > include/asm-generic/errno.h:#define ESTALE 116 /* Stale > > NFS file handle */ > > (...) > > > > I don't use NFS - I use LVM on LUKS. In any case - it have been done > > concurrently with mounting of other fs which had no such problems. > > Yeah that's a bug with an earlier kernel, if you upgrade to 3.1 it should go > away. Thanks, > > Josef I'm using 'newer' kernel then 3.1 - I'm following Linus' tree (this kernel is few days old). Regards -- 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: [PATCH v8 1/8] btrfs: added helper functions to iterate backrefs
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 return >>> it >>> + * released. >>> + * when the iterator function returns a non-zero value, iteration stops. >>> + */ >>> +int iterate_extent_inodes(struct btrfs_fs_info *fs_info, >>> + struct btrfs_path *path, >>> + u64 extent_item_objectid, >>> + u64 extent_offset, >>> + iterate_extent_inodes_t *iterate, void *ctx) >> >> While trying to use this API, I found there's a big defect in this function. >> >>fs_tree 1 fs_tree 2 >>\ / >> \/ >> \ / >> \/ >> node >> | >> | >> leaf (EXTENT_DATA item) >> >> In the above case, the function will find only 1 reference. > > Hum. You are right. > > I'm convinced that I've been at this point months ago, only I cannot > find code dealing with counts > 1 on nodes. I'll look for a fix in my > branches or make a new one. > > Currently, this is more of a best-effort resolver. Support for delayed > extents is missing, it should be used on commit roots to get a > consistent state. > The qgroups patch contains an implementation to find all roots for a given extent. A quite extensive part of qgroups is needed for that, so it might be easiest to build a new version on top of qgroups. Otherwise I could split qgroups in 2 parts to factor out that half. -Arne -- 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: WARNING: at fs/btrfs/extent-tree.c:124
On Mon, Nov 07, 2011 at 02:10:29PM +0900, Tsutomu Itoh wrote: > In for-linus branch, when xfstests was executed, the following warning > messages were output. Dave Sterba and I were consistently getting these last week, but after fixes from Josef and I in the current branch I thought they were fixed. Do this come up every time? Which mount options were you using? -chris > > Thanks, > Tsutomu > > === > > Nov 7 13:51:00 luna kernel: [ 824.063444] device fsid > 2f0ad8a9-93d5-4c99-837f-9db99543133b devid 1 transid 1822 /dev/sdd4 > Nov 7 13:51:00 luna kernel: [ 824.063946] btrfs: disk space caching is > enabled > Nov 7 13:51:00 luna kernel: [ 824.097652] block group 1103101952 has an > wrong amount of free space > Nov 7 13:51:00 luna kernel: [ 824.097873] btrfs: failed to load free space > cache for block group 1103101952 > Nov 7 13:51:01 luna kernel: [ 824.413821] [ cut here > ] > Nov 7 13:51:01 luna kernel: [ 824.413855] WARNING: at > fs/btrfs/extent-tree.c:124 btrfs_put_block_group+0x4f/0x67 [btrfs]() > Nov 7 13:51:01 luna kernel: [ 824.413858] Hardware name: PRIMERGY > Nov 7 13:51:01 luna kernel: [ 824.413860] Modules linked in: btrfs > zlib_deflate crc32c libcrc32c nfsd lockd nfs_acl auth_rpcgss autofs4 sunrpc > 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf cachefiles > fscache ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev > parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support > tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod > crc_t10dif megaraid_sas sr_mod cdrom floppy pata_acpi ata_generic ata_piix > libata scsi_mod [last unloaded: microcode] > Nov 7 13:51:01 luna kernel: [ 824.413915] Pid: 7472, comm: umount Not > tainted 3.1.0mod+ #1 > Nov 7 13:51:01 luna kernel: [ 824.413917] Call Trace: > Nov 7 13:51:01 luna kernel: [ 824.413925] [] > warn_slowpath_common+0x85/0x9d > Nov 7 13:51:01 luna kernel: [ 824.413929] [] > warn_slowpath_null+0x1a/0x1c > Nov 7 13:51:01 luna kernel: [ 824.413943] [] > btrfs_put_block_group+0x4f/0x67 [btrfs] > Nov 7 13:51:01 luna kernel: [ 824.413956] [] > btrfs_free_block_groups+0xde/0x258 [btrfs] > Nov 7 13:51:01 luna kernel: [ 824.413973] [] > close_ctree+0x22c/0x325 [btrfs] > Nov 7 13:51:01 luna kernel: [ 824.413978] [] ? > dispose_list+0x3e/0x4f > Nov 7 13:51:01 luna kernel: [ 824.413989] [] > btrfs_put_super+0x1d/0x2c [btrfs] > Nov 7 13:51:01 luna kernel: [ 824.413994] [] > generic_shutdown_super+0x5b/0xba > Nov 7 13:51:01 luna kernel: [ 824.413998] [] > kill_anon_super+0x16/0x22 > Nov 7 13:51:01 luna kernel: [ 824.414002] [] > deactivate_locked_super+0x26/0x57 > Nov 7 13:51:01 luna kernel: [ 824.414006] [] > deactivate_super+0x45/0x4c > Nov 7 13:51:01 luna kernel: [ 824.414010] [] > mntput_no_expire+0x143/0x14c > Nov 7 13:51:01 luna kernel: [ 824.414822] [] > sys_umount+0x2d9/0x304 > Nov 7 13:51:01 luna kernel: [ 824.414838] [] ? > path_put+0x22/0x26 > Nov 7 13:51:01 luna kernel: [ 824.414846] [] > system_call_fastpath+0x16/0x1b > Nov 7 13:51:01 luna kernel: [ 824.414852] ---[ end trace 1167c1ef9b771b7f > ]--- > Nov 7 13:51:01 luna kernel: [ 824.418017] [ cut here > ] > Nov 7 13:51:01 luna kernel: [ 824.418039] WARNING: at > fs/btrfs/extent-tree.c:7158 btrfs_free_block_groups+0x220/0x258 [btrfs]() > Nov 7 13:51:01 luna kernel: [ 824.418042] Hardware name: PRIMERGY > Nov 7 13:51:01 luna kernel: [ 824.418044] Modules linked in: btrfs > zlib_deflate crc32c libcrc32c nfsd lockd nfs_acl auth_rpcgss autofs4 sunrpc > 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf cachefiles > fscache ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev > parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support > tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod > crc_t10dif megaraid_sas sr_mod cdrom floppy pata_acpi ata_generic ata_piix > libata scsi_mod [last unloaded: microcode] > Nov 7 13:51:01 luna kernel: [ 824.418107] Pid: 7472, comm: umount Tainted: > GW 3.1.0mod+ #1 > Nov 7 13:51:01 luna kernel: [ 824.418110] Call Trace: > Nov 7 13:51:01 luna kernel: [ 824.418117] [] > warn_slowpath_common+0x85/0x9d > Nov 7 13:51:01 luna kernel: [ 824.418121] [] > warn_slowpath_null+0x1a/0x1c > Nov 7 13:51:01 luna kernel: [ 824.418137] [] > btrfs_free_block_groups+0x220/0x258 [btrfs] > Nov 7 13:51:01 luna kernel: [ 824.418157] [] > close_ctree+0x22c/0x325 [btrfs] > Nov 7 13:51:01 luna kernel: [ 824.418161] [] ? > dispose_list+0x3e/0x4f > Nov 7 13:51:01 luna kernel: [ 824.418175] [] > btrfs_put_super+0x1d/0x2c [btrfs] > Nov 7 13:51:01 luna kernel: [ 824.418180] [] > generic_shutdown_super+0x5b/0xba > Nov 7 13:51:01 luna kernel: [ 824.418185] [] > kill
Re: WARNING: at fs/btrfs/free-space-cache.c:305
On Mon, Nov 07, 2011 at 05:06:32PM +0900, Tsutomu Itoh wrote: > Hi, Chris, > > (2011/11/04 8:43), Tsutomu Itoh wrote: > > (2011/11/03 20:19), Chris Mason wrote: > >> On Thu, Nov 03, 2011 at 10:25:23AM +0900, Tsutomu Itoh wrote: > >>> In integration-scrub branch, following warning messages were displayed by > >>> running xfstests. > >>> > >>> # btrfs fi sh /dev/sdd4 > >>> Label: none uuid: 8f28d85c-e37c-4c1b-adef-2627ca59be78 > >>> Total devices 2 FS bytes used 31.49MB > >>> devid1 size 9.31GB used 9.31GB path /dev/sdd4 > >>> devid2 size 15.01GB used 9.29GB path /dev/sdc1 > >>> > >>> Btrfs Btrfs v0.19 > >>> # mount > >>> ... > >>> /dev/sdd4 on /test7 type btrfs (rw,compress=lzo) > >>> # > >>> > >>> Thanks, > >>> Tsutomu > >>> > >>> > >>> > >>> Nov 3 09:55:18 luna kernel: [ 939.732044] device fsid > >>> 8f28d85c-e37c-4c1b-adef-2627ca59be78 devid 1 transid 20510 /dev/sdd4 > >>> Nov 3 09:55:18 luna kernel: [ 939.732533] btrfs: use lzo compression > >>> Nov 3 09:55:18 luna kernel: [ 939.732536] btrfs: disk space caching is > >>> enabled > >>> Nov 3 09:55:18 luna kernel: [ 939.898190] [ cut here > >>> ] > >>> Nov 3 09:55:18 luna kernel: [ 939.898223] WARNING: at > >>> fs/btrfs/free-space-cache.c:305 io_ctl_map_page+0x29/0x76 [btrfs]() > >>> Nov 3 09:55:18 luna kernel: [ 939.898227] Hardware name: PRIMERGY > >>> Nov 3 09:55:18 luna kernel: [ 939.898229] Modules linked in: btrfs > >>> zlib_deflate crc32c libcrc32c nfsd lockd nfs_acl auth_rpcgss autofs4 > >>> sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf > >>> cachefiles fscache ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod > >>> kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt > >>> iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 > >>> mbcache jbd2 crc16 sd_mod crc_t10dif megaraid_sas sr_mod cdrom floppy > >>> pata_acpi ata_generic ata_piix libata scsi_mod [last unloaded: microcode] > >>> Nov 3 09:55:18 luna kernel: [ 939.898291] Pid: 13337, comm: dd Not > >>> tainted 3.1.0integ-sc+ #1 > >>> Nov 3 09:55:18 luna kernel: [ 939.898294] Call Trace: > >>> Nov 3 09:55:18 luna kernel: [ 939.898303] [] > >>> warn_slowpath_common+0x85/0x9d > >>> Nov 3 09:55:18 luna kernel: [ 939.898308] [] > >>> warn_slowpath_null+0x1a/0x1c > >>> Nov 3 09:55:18 luna kernel: [ 939.898328] [] > >>> io_ctl_map_page+0x29/0x76 [btrfs] > >>> Nov 3 09:55:18 luna kernel: [ 939.898349] [] > >>> io_ctl_check_crc+0x62/0xdd [btrfs] > >> > >> Looks like io_ctl_read_bitmap will call io_ctl_check_crc with a mapped > >> page mapped. Any chance you're able to reproduce this? > > > > Yes. > > However, because the panic that David reported occurs, I cannot reproduce > > this problem though I executed xfstests again. > > In for-linus branch, I was able to reproduce this problem. > The message log is attached to this mail. Great, the traces clearly show io_ctl_read_bitmap is leaving a page mapped and that io_ctl_check_crc is trying to map it again. Josef, looks like io_ctl_read_bitmap needs to always unmap? [ trace below ] -chris > > Thanks, > Tsutomu > Nov 7 15:16:28 luna kernel: [ 3010.347454] device fsid > 9880be7d-1b7f-4233-b14d-c6bc37d3d26c devid 1 transid 7775 /dev/sdd4 > Nov 7 15:16:28 luna kernel: [ 3010.347954] btrfs: disk space caching is > enabled > Nov 7 15:16:28 luna kernel: [ 3010.398732] [ cut here > ] > Nov 7 15:16:28 luna kernel: [ 3010.398768] WARNING: at > fs/btrfs/free-space-cache.c:305 io_ctl_map_page+0x29/0x76 [btrfs]() > Nov 7 15:16:28 luna kernel: [ 3010.398772] Hardware name: PRIMERGY > > Nov 7 15:16:28 luna kernel: [ 3010.398774] Modules linked in: nfsd lockd > nfs_acl auth_rpcgss autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand > acpi_cpufreq freq_table mperf cachefiles fscache ipv6 btrfs zlib_deflate > crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput > ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt > iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache > jbd2 crc16 sd_mod crc_t10dif megaraid_sas sr_mod cdrom floppy pata_acpi > ata_generic ata_piix libata scsi_mod [last unloaded: microcode] > Nov 7 15:16:28 luna kernel: [ 3010.398834] Pid: 11742, comm: mkdir Not > tainted 3.1.0mod+ #1 > Nov 7 15:16:28 luna kernel: [ 3010.398837] Call Trace: > Nov 7 15:16:28 luna kernel: [ 3010.398846] [] > warn_slowpath_common+0x85/0x9d > Nov 7 15:16:28 luna kernel: [ 3010.398851] [] > warn_slowpath_null+0x1a/0x1c > Nov 7 15:16:28 luna kernel: [ 3010.398872] [] > io_ctl_map_page+0x29/0x76 [btrfs] > Nov 7 15:16:28 luna kernel: [ 3010.398893] [] > io_ctl_check_crc+0x62/0xd0 [btrfs] > Nov 7 15:16:28 luna kernel: [ 3010.398899] [] ? > rb_insert_color+0x68/0xe5 > Nov 7 15:16:28 luna kernel: [
Re: [PATCH] btrfs: fix double-free 'tree_root' in 'btrfs_mount()'
On Mon, Nov 07, 2011 at 12:12:07PM +0300, sly...@gmail.com wrote: > From: Sergei Trofimovich > > On error path 'tree_root' is treed in 'free_fs_info()'. > No need to free it explicitely. Noticed by SLUB in debug mode: Nice, thanks for the patch. -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: btrfs: could not do orphan cleanup -116
On Mon, Nov 07, 2011 at 01:17:04PM +, Maciej Marcin Piechotka wrote: > Hello, > > When I booted my machine (after clean powerdown) the following message > appeared: > [ 32.757913] device fsid ---- devid 1 > transid 40864 /dev/mapper/X-X > [ 32.758466] btrfs: use lzo compression > [ 32.758475] btrfs: enabling disk space caching > [ 32.758483] btrfs: enabling inode map caching > [ 32.758490] btrfs: enabling auto defrag > [ 32.758497] btrfs: thread pool 2 > [ 34.024359] btrfs: could not do orphan cleanup -116 > [ 63.173382] btrfs: open_ctree failed > > btrfsck has shown no errors. > > Afterwards when I tried to mount filesystem it have shown: > > [ 116.012528] btrfs: enabling inode map caching > [ 116.012534] btrfs: enabling auto defrag > [ 116.012542] btrfs: thread pool 2 > > It looked like everything is working but to be sure I've run scrub: > > scrub status for fsid ---- > scrub started at Mon Nov 7 13:05:50 2011 and finished after 606 > seconds > total bytes scrubbed: 32.37GB with 0 errors > > PS. > # find include | xargs grep 116 > (...) > include/asm-generic/errno.h:#define ESTALE 116 /* Stale > NFS file handle */ > (...) > > I don't use NFS - I use LVM on LUKS. In any case - it have been done > concurrently with mounting of other fs which had no such problems. Yeah that's a bug with an earlier kernel, if you upgrade to 3.1 it should go away. Thanks, Josef -- 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-progs: PATCH] scrub: fix build failure by restoring proper library ordering
Hi David, On 07.11.2011 13:45, David Sterba wrote: > On Mon, Nov 07, 2011 at 10:19:33AM +0300, sly...@gmail.com wrote: >> btrfs: $(objects) btrfs.o btrfs_cmds.o scrub.o >> -$(CC) -lpthread $(CFLAGS) -o btrfs btrfs.o btrfs_cmds.o scrub.o \ >> -$(objects) $(LDFLAGS) $(LIBS) >> +$(CC) $(CFLAGS) -o btrfs btrfs.o btrfs_cmds.o scrub.o \ >> +$(objects) $(LDFLAGS) $(LIBS) -lpthread > > No, it's "-pthread", adds both preprocessor and linker flags. It seems to do the right thing on x86_64, although... If I'm reading my gcc manpage right, it is telling me to use -pthread only for ia64 on HPUX, powerpc and sparc. (gcc 4.4.5 that is) -Jan -- 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
btrfs: could not do orphan cleanup -116
Hello, When I booted my machine (after clean powerdown) the following message appeared: [ 32.757913] device fsid ---- devid 1 transid 40864 /dev/mapper/X-X [ 32.758466] btrfs: use lzo compression [ 32.758475] btrfs: enabling disk space caching [ 32.758483] btrfs: enabling inode map caching [ 32.758490] btrfs: enabling auto defrag [ 32.758497] btrfs: thread pool 2 [ 34.024359] btrfs: could not do orphan cleanup -116 [ 63.173382] btrfs: open_ctree failed btrfsck has shown no errors. Afterwards when I tried to mount filesystem it have shown: [ 116.012528] btrfs: enabling inode map caching [ 116.012534] btrfs: enabling auto defrag [ 116.012542] btrfs: thread pool 2 It looked like everything is working but to be sure I've run scrub: scrub status for fsid ---- scrub started at Mon Nov 7 13:05:50 2011 and finished after 606 seconds total bytes scrubbed: 32.37GB with 0 errors PS. # find include | xargs grep 116 (...) include/asm-generic/errno.h:#define ESTALE 116 /* Stale NFS file handle */ (...) I don't use NFS - I use LVM on LUKS. In any case - it have been done concurrently with mounting of other fs which had no such problems. signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] Btrfs pull request
2011/11/7 Arne Jansen : > is it 32 or 64 bit? 64bit. Please take a look at my other reply. Thanks a lot for your time, Andrea -- 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
BUG at fs/btrfs/inode.c:1795
Hi,
I saw this BUG in current linus' (with last pull included) to quickly
trigger in xfstests/013, with freshly created fs and default raid flags.
[ 528.458613] [ cut here ]
[ 528.461489] kernel BUG at fs/btrfs/inode.c:1795!
[ 528.461489] invalid opcode: [#1] SMP
[ 528.461489] CPU 1
[ 528.461489] Modules linked in: loop btrfs aoe
[ 528.461489]
[ 528.461489] Pid: 8862, comm: btrfs-endio-wri Not tainted 3.1.0-default+ #67
Intel Corporation Santa Rosa platform/Matanzas
[ 528.461489] RIP: 0010:[] []
btrfs_finish_ordered_io+0x287/0x320 [btrfs]
[ 528.461489] RSP: 0018:880079809c80 EFLAGS: 00010286
[ 528.461489] RAX: ffe4 RBX: 88007a15d000 RCX:
[ 528.461489] RDX: 880079540440 RSI: 0001 RDI: 0246
[ 528.461489] RBP: 880079809cf0 R08: 0001 R09: 0001
[ 528.461489] R10: R11: R12: 88006db1c3f0
[ 528.461489] R13: 88007620ecd8 R14: R15: 88006db1c000
[ 528.461489] FS: () GS:88007de0()
knlGS:
[ 528.461489] CS: 0010 DS: ES: CR0: 8005003b
[ 528.461489] CR2: 7f5724ca4000 CR3: 7a127000 CR4: 06e0
[ 528.461489] DR0: DR1: DR2:
[ 528.461489] DR3: DR6: 0ff0 DR7: 0400
[ 528.461489] Process btrfs-endio-wri (pid: 8862, threadinfo 880079808000,
task 880079540440)
[ 528.461489] Stack:
[ 528.461489] 0286 88006db1c610 880079809ca0
810a07dd
[ 528.461489] 880079809cc0 88006db1c0b8
880078b4f9c0
[ 528.461489] 880079809d10 88007941cff0 88007d491ef0
00101fff
[ 528.461489] Call Trace:
[ 528.461489] [] ? trace_hardirqs_on+0xd/0x10
[ 528.461489] [] btrfs_writepage_end_io_hook+0x4c/0xa0
[btrfs]
[ 528.461489] [] end_bio_extent_writepage+0x138/0x190
[btrfs]
[ 528.461489] [] bio_endio+0x1d/0x40
[ 528.461489] [] end_workqueue_fn+0xf4/0x130 [btrfs]
[ 528.461489] [] worker_loop+0xb4/0x520 [btrfs]
[ 528.461489] [] ? btrfs_queue_worker+0x330/0x330 [btrfs]
[ 528.461489] [] kthread+0xa6/0xb0
[ 528.461489] [] kernel_thread_helper+0x4/0x10
[ 528.461489] [] ? retint_restore_args+0x13/0x13
[ 528.461489] [] ? __init_kthread_worker+0x70/0x70
[ 528.461489] [] ? gs_change+0x13/0x13
[ 528.461489] Code: 00 85 c0 74 10 48 8b 45 c8 48 8b 40 28 a8 10 0f 85 8f fe
ff ff 4c 89 e2 48 89 de 4c 89 ef e8 71 f7 ff ff 85 c0 0f 84 79 fe ff ff <0f> 0b
0f 1f 80 00 00 00 00 48 89 df e8 18 a3 ff ff 49 89 c5 e9
[ 528.461489] RIP [] btrfs_finish_ordered_io+0x287/0x320
[btrfs]
[ 528.461489] RSP
[ 528.775180] ---[ end trace 0b60ffea4d2cd332 ]---
1789 add_pending_csums(trans, inode, ordered_extent->file_offset,
1790 &ordered_extent->list);
1791
1792 ret = btrfs_ordered_update_i_size(inode, 0, ordered_extent);
1793 if (!ret || !test_bit(BTRFS_ORDERED_PREALLOC,
&ordered_extent->flags)) {
1794 ret = btrfs_update_inode(trans, root, inode);
1795 BUG_ON(ret);
1796 }
ret is -28 ENOSPC .
mount flags: compress=lzo,discard,space_cache,autodefrag,inode_cache
david
--
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: [GIT PULL] Btrfs pull request
2011/11/7 Roman Mamedov : > If so, shouldn't there also be a corresponding dmesg warning about "Unable to > allocate", which would confirm or rule this out? > So before following the "did you try turning it off and on again" advice (and > throwing away useful debug info), I'd suggest checking/saving dmesg first. Hi Roman, and thanks a lot for your reply. I did check dmesg and /var/log also, but I didn't find complain about it. So, I tried with a loopback device and it works well. Maybe the problem is about my device stack? Bottom up my home is on a: md + luks + lvm + md + btrfs. Thanks a lot for your time, Andrea -- 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-progs: PATCH] scrub: fix build failure by restoring proper library ordering
On Mon, Nov 07, 2011 at 10:19:33AM +0300, sly...@gmail.com wrote: > btrfs: $(objects) btrfs.o btrfs_cmds.o scrub.o > - $(CC) -lpthread $(CFLAGS) -o btrfs btrfs.o btrfs_cmds.o scrub.o \ > - $(objects) $(LDFLAGS) $(LIBS) > + $(CC) $(CFLAGS) -o btrfs btrfs.o btrfs_cmds.o scrub.o \ > + $(objects) $(LDFLAGS) $(LIBS) -lpthread No, it's "-pthread", adds both preprocessor and linker flags. david -- 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: [GIT PULL] Btrfs pull request
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 Arne, >and thanks a lot for your reply. >So: >a) it's a fresh Ubuntu 11.04, with latest Linus git tree > (31555213f03bca37d2c02e10946296052f4ecfcd), and latest btrfs progs > (13eced9a0c2b6bd6bc38e6f0f46a1977b1167e67), plus Chris btrfs branch > for-linus; >b) same problem after a fresh boot. is it 32 or 64 bit? Thanks, Arne > > Thanks, > Andrea -- 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: [GIT PULL] Btrfs pull request
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 Arne, and thanks a lot for your reply. So: a) it's a fresh Ubuntu 11.04, with latest Linus git tree (31555213f03bca37d2c02e10946296052f4ecfcd), and latest btrfs progs (13eced9a0c2b6bd6bc38e6f0f46a1977b1167e67), plus Chris btrfs branch for-linus; b) same problem after a fresh boot. Thanks, Andrea -- 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: How to remount btrfs without compression?
Am Montag, 7. November 2011 schrieb dima: > Hello, Hi Dima, > Is there any possibility to remount a compressed btrfs without any > compression at all? > > Syslinux bootloader does not understand any btrfs compression and > whenever I edit syslinux.cfg on my compressed / subvolume, the file > becomes compressed and thus unreadable by syslinux on the next boot. > > I tried to remount / without the 'compress' option (and edit > syslinux.cfg in uncompressed state) and while the "mount" command would > not show compression any more, I can see in the /proc/mounts that > compression is still there and the file still gets compressed after > editing. But there seem to be no mount option like compress=none or > something. > > The only workaround I found is to boot from a live CD mount / without > any compression and re-save syslinux.cfg. Then it the file gets > uncompressed. > > Are there any other options except for this workaround to temporarily > remount btrfs without compression? What does lsattr show on the file? Have you tried chattr -c on the file? It might help to do a btrfs filesystem defrag on the file to remove compression, cause I don´t think chattr -c itself will uncompress it. As far as I understand it is possible to individually set compression on/off on single files. Although the global thing should work as well IMHO as least when the file is rewritten. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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: [GIT PULL] Btrfs pull request
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 for device id 1 (Cannot allocate memory) >>> scrub canceled for 11827b37-1ba0-4b3e-883d-2746987724ca >>> scrub started at Sun Nov 6 20:23:46 2011 and was aborted after 0 >>> seconds >>> total bytes scrubbed: 0.00 with 0 errors >>> root@Q45:/home/gelma/dev/prg/btrfs# ./btrfs scrub start -Br /home/ >>> ERROR: scrubbing /home/ failed for device id 1 (Cannot allocate memory) >>> scrub canceled for 11827b37-1ba0-4b3e-883d-2746987724ca >>> scrub started at Sun Nov 6 20:25:01 2011 and was aborted after 0 >>> seconds >>> total bytes scrubbed: 0.00 with 0 errors >> >> 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. > > If so, shouldn't there also be a corresponding dmesg warning about "Unable to > allocate", which would confirm or rule this out? > So before following the "did you try turning it off and on again" advice (and > throwing away useful debug info), I'd suggest checking/saving dmesg first. > You're right of course. The advice was not meant as a fix, but as a means to gather more information. -- 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: [GIT PULL] Btrfs pull request
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 for device id 1 (Cannot allocate memory) > > scrub canceled for 11827b37-1ba0-4b3e-883d-2746987724ca > > scrub started at Sun Nov 6 20:23:46 2011 and was aborted after 0 > > seconds > > total bytes scrubbed: 0.00 with 0 errors > > root@Q45:/home/gelma/dev/prg/btrfs# ./btrfs scrub start -Br /home/ > > ERROR: scrubbing /home/ failed for device id 1 (Cannot allocate memory) > > scrub canceled for 11827b37-1ba0-4b3e-883d-2746987724ca > > scrub started at Sun Nov 6 20:25:01 2011 and was aborted after 0 > > seconds > > total bytes scrubbed: 0.00 with 0 errors > > 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. If so, shouldn't there also be a corresponding dmesg warning about "Unable to allocate", which would confirm or rule this out? So before following the "did you try turning it off and on again" advice (and throwing away useful debug info), I'd suggest checking/saving dmesg first. -- With respect, Roman ~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free." signature.asc Description: PGP signature
Re: space cache generation (...) does not match inode (...)
Hi Josef, Am Montag, 8. August 2011 schrieb Josef Bacik: > On 08/06/2011 10:16 PM, Andrew Lutomirski wrote: > > I've always gotten space cache generation warnings, but some time > > after 3.0 they started going nuts. I get: > > > > space cache generation (14667727114112179905) does not match inode > > (154185) > > > > and other similar messages (with a huge number and a smaller number) > > at rates higher than one message per ms. They don't happen > > constantly, but they come in bursts big enough to fill my log buffer. > > Yeah sorry that's going to happen when you first switch to 3.0. We > switched the space cache stuff over to using the normal checksumming > code so all old space cache is going to look invalid. This is nothing > to worry about, it will just end up discarded and re-generated. I found these too and found this thread about it. Now I restarted 3.1 another time but I still get these. Less than before, but they still appear. Is that okay? I thought BTRFS would update the space cache once and then be done with it. When exactly should BTRFS be done with it? Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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: [GIT PULL] Btrfs pull request
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 faster >> thanks to extensive btree readahead and instead of just telling you a >> specific block is bad, it tells you which btree or which file was >> impacted by that bad block. > >Using your for-linus branch, on latest Linus' git tree, with latest > git tools, >I've got this: > > root@Q45:/home/gelma/dev/prg/btrfs# ./btrfs scrub start -Br /dev/md126 > ERROR: scrubbing /dev/md126 failed for device id 1 (Cannot allocate memory) > scrub canceled for 11827b37-1ba0-4b3e-883d-2746987724ca > scrub started at Sun Nov 6 20:23:46 2011 and was aborted after 0 > seconds > total bytes scrubbed: 0.00 with 0 errors > root@Q45:/home/gelma/dev/prg/btrfs# ./btrfs scrub start -Br /home/ > ERROR: scrubbing /home/ failed for device id 1 (Cannot allocate memory) > scrub canceled for 11827b37-1ba0-4b3e-883d-2746987724ca > scrub started at Sun Nov 6 20:25:01 2011 and was aborted after 0 > seconds > total bytes scrubbed: 0.00 with 0 errors 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. Thanks, Arne > > Thanks a lot for your time, > Andrea >> -- 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: [PATCH] btrfs: fix double-free 'tree_root' in 'btrfs_mount()'
> > bdev=/dev/ubda > > btr_root=/btr > > /mkfs.btrfs $bdev > > mount $bdev $btr_root > > mkdir $btr_root/subvols/ > > cd $btr_root/subvols/ > > /btrfs su cr foo > > /btrfs su cr bar > > mount $bdev -osubvol=subvols/foo $btr_root/subvols/bar > > umount $btr_root/subvols/bar > > Can you please send this as a new testcase for xfstests? I'll try to. Will take some time though (never seen it before). Thanks! -- Sergei signature.asc Description: PGP signature
Re: [PATCH] btrfs: Don't leak mem in scrub_fixup().
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 we return in that error
> case.
Thanks for looking into this. The current pull request already contains
a fix for this, from Ilya Dryomov.
-Arne
>
> Signed-off-by: Jesper Juhl
> ---
> fs/btrfs/scrub.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> Compile tested only since I don't have any btrfs filesystems to test on.
>
> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
> index a8d03d5..b53433e 100644
> --- a/fs/btrfs/scrub.c
> +++ b/fs/btrfs/scrub.c
> @@ -271,6 +271,7 @@ static void scrub_fixup(struct scrub_bio *sbio, int ix)
> ret = btrfs_map_block(map_tree, REQ_WRITE, logical, &length,
> &multi, 0);
> if (ret || !multi || length < PAGE_SIZE) {
> + kfree(multi);
> printk(KERN_ERR
> "scrub_fixup: btrfs_map_block failed us for %llu\n",
> (unsigned long long)logical);
--
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: [PATCH] btrfs: fix double-free 'tree_root' in 'btrfs_mount()'
On Mon, Nov 07, 2011 at 12:12:07PM +0300, sly...@gmail.com wrote: > bdev=/dev/ubda > btr_root=/btr > /mkfs.btrfs $bdev > mount $bdev $btr_root > mkdir $btr_root/subvols/ > cd $btr_root/subvols/ > /btrfs su cr foo > /btrfs su cr bar > mount $bdev -osubvol=subvols/foo $btr_root/subvols/bar > umount $btr_root/subvols/bar Can you please send this as a new testcase for xfstests? -- 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] btrfs: fix double-free 'tree_root' in 'btrfs_mount()'
From: Sergei Trofimovich
On error path 'tree_root' is treed in 'free_fs_info()'.
No need to free it explicitely. Noticed by SLUB in debug mode:
Complete reproducer under usermode linux (discovered on real
machine):
bdev=/dev/ubda
btr_root=/btr
/mkfs.btrfs $bdev
mount $bdev $btr_root
mkdir $btr_root/subvols/
cd $btr_root/subvols/
/btrfs su cr foo
/btrfs su cr bar
mount $bdev -osubvol=subvols/foo $btr_root/subvols/bar
umount $btr_root/subvols/bar
which gives
device fsid 4d55aa28-45b1-474b-b4ec-da912322195e devid 1 transid 7 /dev/ubda
=
BUG kmalloc-2048: Object already free
-
INFO: Allocated in btrfs_mount+0x389/0x7f0 age=0 cpu=0 pid=277
INFO: Freed in btrfs_mount+0x51c/0x7f0 age=0 cpu=0 pid=277
INFO: Slab 0x62886200 objects=15 used=9 fp=0x70b4d2d0
flags=0x4081
INFO: Object 0x70b4d2d0 @offset=21200 fp=0x70b4a968
...
Call Trace:
70b31948: [<6008c522>] print_trailer+0xe2/0x130
70b31978: [<6008c5aa>] object_err+0x3a/0x50
70b319a8: [<6008e242>] free_debug_processing+0x142/0x2a0
70b319e0: [<600ebf6f>] btrfs_mount+0x55f/0x7f0
70b319f8: [<6008e5c1>] __slab_free+0x221/0x2d0
Signed-off-by: Sergei Trofimovich
Cc: Arne Jansen
Cc: Chris Mason
Cc: David Sterba
---
fs/btrfs/super.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 57080df..dcd5aef 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -933,8 +933,12 @@ static struct dentry *btrfs_mount(struct file_system_type
*fs_type, int flags,
* then open_ctree will properly initialize everything later.
*/
fs_info = kzalloc(sizeof(struct btrfs_fs_info), GFP_NOFS);
+ if (!fs_info) {
+ error = -ENOMEM;
+ goto error_close_devices;
+ }
tree_root = kzalloc(sizeof(struct btrfs_root), GFP_NOFS);
- if (!fs_info || !tree_root) {
+ if (!tree_root) {
error = -ENOMEM;
goto error_close_devices;
}
@@ -964,7 +968,6 @@ static struct dentry *btrfs_mount(struct file_system_type
*fs_type, int flags,
btrfs_close_devices(fs_devices);
free_fs_info(fs_info);
- kfree(tree_root);
} else {
char b[BDEVNAME_SIZE];
@@ -992,7 +995,6 @@ static struct dentry *btrfs_mount(struct file_system_type
*fs_type, int flags,
error_close_devices:
btrfs_close_devices(fs_devices);
free_fs_info(fs_info);
- kfree(tree_root);
return ERR_PTR(error);
}
--
1.7.3.4
--
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: WARNING: at fs/btrfs/free-space-cache.c:305
Hi, Chris, (2011/11/04 8:43), Tsutomu Itoh wrote: > (2011/11/03 20:19), Chris Mason wrote: >> On Thu, Nov 03, 2011 at 10:25:23AM +0900, Tsutomu Itoh wrote: >>> In integration-scrub branch, following warning messages were displayed by >>> running xfstests. >>> >>> # btrfs fi sh /dev/sdd4 >>> Label: none uuid: 8f28d85c-e37c-4c1b-adef-2627ca59be78 >>> Total devices 2 FS bytes used 31.49MB >>> devid1 size 9.31GB used 9.31GB path /dev/sdd4 >>> devid2 size 15.01GB used 9.29GB path /dev/sdc1 >>> >>> Btrfs Btrfs v0.19 >>> # mount >>> ... >>> /dev/sdd4 on /test7 type btrfs (rw,compress=lzo) >>> # >>> >>> Thanks, >>> Tsutomu >>> >>> >>> >>> Nov 3 09:55:18 luna kernel: [ 939.732044] device fsid >>> 8f28d85c-e37c-4c1b-adef-2627ca59be78 devid 1 transid 20510 /dev/sdd4 >>> Nov 3 09:55:18 luna kernel: [ 939.732533] btrfs: use lzo compression >>> Nov 3 09:55:18 luna kernel: [ 939.732536] btrfs: disk space caching is >>> enabled >>> Nov 3 09:55:18 luna kernel: [ 939.898190] [ cut here >>> ] >>> Nov 3 09:55:18 luna kernel: [ 939.898223] WARNING: at >>> fs/btrfs/free-space-cache.c:305 io_ctl_map_page+0x29/0x76 [btrfs]() >>> Nov 3 09:55:18 luna kernel: [ 939.898227] Hardware name: PRIMERGY >>> Nov 3 09:55:18 luna kernel: [ 939.898229] Modules linked in: btrfs >>> zlib_deflate crc32c libcrc32c nfsd lockd nfs_acl auth_rpcgss autofs4 sunrpc >>> 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf >>> cachefiles fscache ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm >>> uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt >>> iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 >>> mbcache jbd2 crc16 sd_mod crc_t10dif megaraid_sas sr_mod cdrom floppy >>> pata_acpi ata_generic ata_piix libata scsi_mod [last unloaded: microcode] >>> Nov 3 09:55:18 luna kernel: [ 939.898291] Pid: 13337, comm: dd Not >>> tainted 3.1.0integ-sc+ #1 >>> Nov 3 09:55:18 luna kernel: [ 939.898294] Call Trace: >>> Nov 3 09:55:18 luna kernel: [ 939.898303] [] >>> warn_slowpath_common+0x85/0x9d >>> Nov 3 09:55:18 luna kernel: [ 939.898308] [] >>> warn_slowpath_null+0x1a/0x1c >>> Nov 3 09:55:18 luna kernel: [ 939.898328] [] >>> io_ctl_map_page+0x29/0x76 [btrfs] >>> Nov 3 09:55:18 luna kernel: [ 939.898349] [] >>> io_ctl_check_crc+0x62/0xdd [btrfs] >> >> Looks like io_ctl_read_bitmap will call io_ctl_check_crc with a mapped >> page mapped. Any chance you're able to reproduce this? > > Yes. > However, because the panic that David reported occurs, I cannot reproduce > this problem though I executed xfstests again. In for-linus branch, I was able to reproduce this problem. The message log is attached to this mail. Thanks, Tsutomu Nov 7 15:16:28 luna kernel: [ 3010.347454] device fsid 9880be7d-1b7f-4233-b14d-c6bc37d3d26c devid 1 transid 7775 /dev/sdd4 Nov 7 15:16:28 luna kernel: [ 3010.347954] btrfs: disk space caching is enabled Nov 7 15:16:28 luna kernel: [ 3010.398732] [ cut here ] Nov 7 15:16:28 luna kernel: [ 3010.398768] WARNING: at fs/btrfs/free-space-cache.c:305 io_ctl_map_page+0x29/0x76 [btrfs]() Nov 7 15:16:28 luna kernel: [ 3010.398772] Hardware name: PRIMERGY Nov 7 15:16:28 luna kernel: [ 3010.398774] Modules linked in: nfsd lockd nfs_acl auth_rpcgss autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf cachefiles fscache ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif megaraid_sas sr_mod cdrom floppy pata_acpi ata_generic ata_piix libata scsi_mod [last unloaded: microcode] Nov 7 15:16:28 luna kernel: [ 3010.398834] Pid: 11742, comm: mkdir Not tainted 3.1.0mod+ #1 Nov 7 15:16:28 luna kernel: [ 3010.398837] Call Trace: Nov 7 15:16:28 luna kernel: [ 3010.398846] [] warn_slowpath_common+0x85/0x9d Nov 7 15:16:28 luna kernel: [ 3010.398851] [] warn_slowpath_null+0x1a/0x1c Nov 7 15:16:28 luna kernel: [ 3010.398872] [] io_ctl_map_page+0x29/0x76 [btrfs] Nov 7 15:16:28 luna kernel: [ 3010.398893] [] io_ctl_check_crc+0x62/0xd0 [btrfs] Nov 7 15:16:28 luna kernel: [ 3010.398899] [] ? rb_insert_color+0x68/0xe5 Nov 7 15:16:28 luna kernel: [ 3010.398919] [] io_ctl_read_bitmap+0x34/0x61 [btrfs] Nov 7 15:16:28 luna kernel: [ 3010.398941] [] ? link_free_space+0x3f/0x54 [btrfs] Nov 7 15:16:28 luna kernel: [ 3010.398961] [] __load_free_space_cache+0x2f1/0x35a [btrfs] Nov 7 15:16:28 luna kernel: [ 3010.398967] [] ? igrab+0x1d/0x44 Nov 7 15:16:28 luna kernel: [ 3010.398988] [] load_free_space_cache+0xca/0x168 [btrfs] Nov 7 15:16:28 luna kernel: [ 3010.399004] [] cache_block_group+0xa3/0x1f2 [btrfs] Nov
