[PATCH] Btrfs: fix memory leak in load_free_space_cache()
load_free_space_cache() has forgotten to free path.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/free-space-cache.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 5802b147..b30242f 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -777,6 +777,7 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info,
spin_lock(block_group-lock);
if (block_group-disk_cache_state != BTRFS_DC_WRITTEN) {
spin_unlock(block_group-lock);
+ btrfs_free_path(path);
goto out;
}
spin_unlock(block_group-lock);
--
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 3/3 v3] xfstests: add btrfs online defragments QA test
As the title shows, we port btrfs online defragments QA test into xfstests.
v3:
- use xfstests wrappers.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
278 | 171 +++
278.out | 11
group |1 +
3 files changed, 183 insertions(+), 0 deletions(-)
create mode 100755 278
create mode 100644 278.out
diff --git a/278 b/278
new file mode 100755
index 000..4ecbc30
--- /dev/null
+++ b/278
@@ -0,0 +1,171 @@
+#! /bin/bash
+# FS QA Test No. 278
+#
+# Btrfs Online defragmentation tests
+#
+#---
+# Copyright (c) 2012 Fujitsu Liu Bo. 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=liubo2...@cn.fujitsu.com
+
+seq=`basename $0`
+echo QA output created by $seq
+here=`pwd`
+tmp=/tmp/$$
+cnt=11999
+filesize=48000
+
+status=1 # failure is the default!
+trap _cleanup; exit \$status 0 1 2 3 15
+
+_cleanup()
+{
+cd /
+rm -f $tmp.*
+}
+
+_create_file()
+{
+ if [ $1 -ne 2 ]; then
+ tmpfile=$SCRATCH_MNT/tmp_file
+ else
+ tmpfile=$SCRATCH_MNT/tmp_dir/tmp_file
+ fi
+
+ for i in `seq $cnt -1 0`; do
+ dd if=/dev/zero of=$tmpfile bs=4k count=1 \
+conv=notrunc seek=$i oflag=sync /dev/null
+ done
+ # get md5sum
+ md5sum $tmpfile /tmp/checksum
+}
+
+_btrfs_online_defrag()
+{
+ str=
+ if [ $2 = 2 ];then
+ str=$str -s -1 -l $((filesize / 2))
+ elif [ $2 = 3 ];then
+ str=$str -s $((filesize + 1)) -l $((filesize / 2))
+ HAVE_DEFRAG=1
+ elif [ $2 = 4 ];then
+ str=$str -l -1
+ elif [ $2 = 5 ];then
+ str=$str -l $((filesize + 1))
+ elif [ $2 = 6 ];then
+ str=$str -l $((filesize / 2))
+ fi
+
+ if [ $3 = 2 ];then
+ str=$str -c
+ fi
+
+ if [ $str != ]; then
+ btrfs filesystem defragment $str $SCRATCH_MNT/tmp_file
+ else
+ if [ $1 = 1 ];then
+ btrfs filesystem defragment $SCRATCH_MNT/tmp_file
+ elif [ $1 = 2 ];then
+ btrfs filesystem defragment $SCRATCH_MNT/tmp_dir
+ elif [ $1 = 3 ];then
+ btrfs filesystem defragment $SCRATCH_MNT
+ fi
+ fi
+ ret_val=$?
+ _scratch_remount
+ if [ $ret_val -ne 20 ];then
+ echo btrfs filesystem defragment failed! err is $ret_val
+ fi
+}
+
+_checksum()
+{
+ md5sum -c /tmp/checksum /dev/null 21
+ if [ $? -ne 0 ]; then
+ echo md5 checksum failed!
+ fi
+}
+
+_cleanup_defrag()
+{
+ umount $SCRATCH_MNT /dev/null 21
+}
+
+_setup_defrag()
+{
+ umount $SCRATCH_MNT /dev/null 21
+ _scratch_mkfs /dev/null 21
+ _scratch_mount
+ _create_file $1
+}
+
+_rundefrag()
+{
+ _setup_defrag $1
+ _btrfs_online_defrag $1 $2 $3
+ _checksum
+ _cleanup_defrag
+ _check_scratch_fs
+}
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+. ./common.defrag
+
+# real QA test starts here
+_supported_fs btrfs
+_supported_os Linux
+
+_setup_testdir
+## We require scratch so that we'll have free contiguous space
+_require_scratch
+_scratch_mkfs /dev/null 21
+_scratch_mount
+_require_defrag
+
+echo defrag object | defragment range | defragment compress
+echo a single file | default | off
+_rundefrag 1 1 1
+
+echo a single file | default | on
+_rundefrag 1 1 2
+
+echo a single file | start 0 0 len file size | off
+_rundefrag 1 2 1
+
+echo a single file | start file size 0 len file size | off
+_rundefrag 1 3 1
+
+echo a single file | start = 0 len 0 | off
+_rundefrag 1 4 1
+
+echo a single file | start = 0 len file size | off
+_rundefrag 1 5 1
+
+echo a single file | start = 0 0 len file size | off
+_rundefrag 1 6 1
+
+echo a directory | default | off
+_rundefrag 2 1 1
+
+echo a filesystem | default | off
+_rundefrag 3 1 1
+
+status=0
+exit
diff --git a/278.out b/278.out
new file mode 100644
index 000..100869e
--- /dev/null
+++ b/278.out
@@ -0,0 +1,11 @@
+QA output created by 278
+defrag
Re: [PATCH 00/21] Btrfs: restriper
On Mon, Feb 13, 2012 at 09:31:09PM -0500, Jérôme Poulin wrote: On Fri, Jan 6, 2012 at 9:30 AM, Ilya Dryomov idryo...@gmail.com wrote: This is a respin of restriper patch series which adds an initial implementation of restriper (it's a clever name for relocation framework that allows to do selective profile changing and selective balancing with some goodies like pausing/resuming and reporting progress to the user). See userspace cover patch for usage examples. I just tried merging this on my kernel 3.2.1 and it seems to work nicely. I compiled your btrfs-progs, made an LVM snapshot and launched a balance on my 300 GB filesystem converted from ext4. It worked for converting my metadata from single to dup, however, it didn't succeed converting my system from single to dup. Here is the command I used: root /usr/src/kernel/btrfs-progs # ./btrfs balance start -f -v -sconvert=dup -mconvert=dup /mnt/btrfs/ Dumping filters: flags 0xe, state 0x0, force is on METADATA (flags 0x100): converting, target=32, soft is off SYSTEM (flags 0x100): converting, target=32, soft is off Done, had to relocate 28 out of 220 chunks Then tried: root /usr/src/kernel/btrfs-progs # ./btrfs balance start -f -v -sconvert=dup /mnt/btrfs/ Dumping filters: flags 0xa, state 0x0, force is on SYSTEM (flags 0x100): converting, target=32, soft is off Done, had to relocate 0 out of 239 chunks Yeah, that's known. The old balancing code wasn't allowed to relocate chunk 0 and always skipped it. I decided to keep that limitation, it will be lifted (or otherwise fixed) shortly. Just to be sure, could you please paste the output of `btrfs-debug-tree -d your device' somewhere ? Thanks, Ilya -- 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 00/21] Btrfs: restriper
On Tue, Feb 14, 2012 at 9:18 AM, Ilya Dryomov idryo...@gmail.com wrote: Just to be sure, could you please paste the output of `btrfs-debug-tree -d your device' somewhere ? Here it is: http://paste.pocoo.org/show/550900/ I also had btrsck errors before and still have them with 3 new after balance (I guess it duplicated them :) root 424 inode 291690 errors 400 root 424 inode 18446744073709551604 errors 2000 root 424 inode 18446744073709551605 errors 1 Full btrfsck: http://paste.pocoo.org/show/550902/ -- 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 00/21] Btrfs: restriper
On Tue, Feb 14, 2012 at 11:15:39AM -0500, Jérôme Poulin wrote: On Tue, Feb 14, 2012 at 9:18 AM, Ilya Dryomov idryo...@gmail.com wrote: Just to be sure, could you please paste the output of `btrfs-debug-tree -d your device' somewhere ? Here it is: http://paste.pocoo.org/show/550900/ So I was correct, you have one system chunk, and it happens to start at logical 0. Balancing code simply skips it, I'll fix that. Thanks, Ilya -- 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: Bulk discard doesn't work after add/delete of devices
Hi, Liu Bo wrote: Actually I have no idea how to deal with this properly :( Because btrfs supports multi-devices so that we have to set the filesystem logical range to [0, (u64)-1] to get things to work well, while other filesystems's logical range is [0, device's total_bytes]. What's more, in btrfs, devices can be mirrored to RAID, and the free space is also ordered by logical addr [0, (u64)-1], so IMO it is impossible to interpreted the range. I do not concur with this reasoning, but please see below that I concur with your conclusion. I still think that the range could be interpreted like I hinted at in my mail: So, to make bulk discard of ranges useful, it seems the incoming range should be interpreted relative to the size of the filesystem and not to the allocated chunks. As AFAIK the size of the filesystem is just the sum of the sizes of its devices it might be possible to map the range onto a virtual concatenation of the devices, these perhaps ordered by devid, and then to find the free space by searching for the resulting devid(s) and device-relative offsets in the device tree? This would only be somewhat difficult to use if the filesystem consisted of a mixture of non trim-capable and trim-capable devices and if the idea behind ranges is that the user can expect an equal amount of trim-capable storage behind different equally sized ranges - but I don't know if this is indeed an idea behind ranges. If, on the other hand, there is a way outside of the ioctl to find out which devices the filesystem consists of and which of these support discard, the above mentioned way to interpret ranges would extend to this setting. But maybe this would already be too ugly, essentially working around the shortcomings of an interface that is too restricted. Moreover, I don't know why ranges smaller than the filesystem are supported by fstrim. I couldn't find any use cases or rationale for it in fstrim's or the ioctl's documentation or elsewhere. This makes it difficult to find out what might be useful in the case of a multi-device filesystem ;-) So, with ranges being this unclear, I concur with your suggestion: I'd better pick up treat the trim the complete filesystem case specially, and drop the following commit: commit f4c697e6406da5dd445eda8d923c53e1138793dd Author: Lukas Czerner lczer...@redhat.com Date: Mon Sep 5 16:34:54 2011 +0200 btrfs: return EINVAL if start total_bytes in fitrim ioctl More specifically, what I do wish for is: - Fix the problem I started the thread for: Make fstrim of the complete filesystem work. And then, if possible: - Simplify btrfs_trim_fs as much as possible to remove all traces of support for ranges smaller than the filesystem, document that this anyway wouldn't do what the user might expect, and, if possible, return an error in these cases. - Also trim unallocated space (for use after balancing and at mkfs time). Thanks for your time and your work, Lutz -- 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: can't read superblock (but could mount)
On Mon, 13 Feb 2012, Chris Mason wrote: btrfs-debug-tree -b 9872289792 /dev/xxx # btrfs-debug-tree -b 9872289792 /dev/loop1 leaf 9872289792 items 51 free space 0 generation 120351 owner 5 fs uuid 9e9886fc-3e60-4c59-a246-727662769ee2 chunk uuid f7e4ac1e-f4d6-436b-9bda-8409311dcdb6 item 0 key (923514 DIR_ITEM 2120090750) itemoff 3950 itemsize 45 location key (2722082 INODE_ITEM 0) type 1 namelen 15 datalen 0 name: UTBI__24.pcf.gz item 1 key (923514 DIR_ITEM 2120348073) itemoff 3895 itemsize 55 location key (2722204 INODE_ITEM 0) type 1 namelen 25 datalen 0 name: helvB12-ISO8859-14.pcf.gz item 2 key (923514 DIR_ITEM 2123806861) itemoff 3840 itemsize 55 location key (2723467 INODE_ITEM 0) type 1 namelen 25 datalen 0 name: lutRS08-ISO8859-15.pcf.gz item 3 key (923514 DIR_ITEM 2124181825) itemoff 3787 itemsize 53 location key (2722901 INODE_ITEM 0) type 1 namelen 23 datalen 0 name: timB10-ISO8859-9.pcf.gz item 4 key (923514 DIR_ITEM 2124481083) itemoff 3734 itemsize 53 location key (2723388 INODE_ITEM 0) type 1 namelen 23 datalen 0 name: luIS19-ISO8859-9.pcf.gz item 5 key (923514 DIR_ITEM 2127941711) itemoff 3679 itemsize 55 location key (2722919 INODE_ITEM 0) type 1 namelen 25 datalen 0 name: courBO18-ISO8859-2.pcf.gz item 6 key (923514 DIR_ITEM 2128786561) itemoff 3624 itemsize 55 location key (2721907 INODE_ITEM 0) type 1 namelen 25 datalen 0 name: helvBO24-ISO8859-1.pcf.gz item 7 key (923514 DIR_ITEM 2131308727) itemoff 3569 itemsize 55 location key (2723365 INODE_ITEM 0) type 1 namelen 25 datalen 0 name: ncenBI10-ISO8859-2.pcf.gz item 8 key (923514 DIR_ITEM 2131961491) itemoff 3515 itemsize 54 location key (2723113 INODE_ITEM 0) type 1 namelen 24 datalen 0 name: ncenI10-ISO8859-4.pcf.gz item 9 key (923514 DIR_ITEM 2132458601) itemoff 3461 itemsize 54 location key (2722426 INODE_ITEM 0) type 1 namelen 24 datalen 0 name: timI24-ISO8859-13.pcf.gz item 10 key (923514 DIR_ITEM 2132654723) itemoff 3406 itemsize 55 location key (2722242 INODE_ITEM 0) type 1 namelen 25 datalen 0 name: ncenB08-ISO8859-14.pcf.gz item 11 key (923514 DIR_ITEM 2136131400) itemoff 3353 itemsize 53 location key (2722472 INODE_ITEM 0) type 1 namelen 23 datalen 0 name: lubR10-ISO8859-2.pcf.gz item 12 key (923514 DIR_ITEM 2136302367) itemoff 3298 itemsize 55 location key (2721978 INODE_ITEM 0) type 1 namelen 25 datalen 0 name: helvR14-ISO8859-15.pcf.gz item 13 key (923514 DIR_ITEM 2141157400) itemoff 3244 itemsize 54 location key (2721809 INODE_ITEM 0) type 1 namelen 24 datalen 0 name: luRS24-ISO8859-10.pcf.gz item 14 key (923514 DIR_ITEM 2143920500) itemoff 3190 itemsize 54 location key (2722139 INODE_ITEM 0) type 1 namelen 24 datalen 0 name: lutRS10-ISO8859-4.pcf.gz item 15 key (923514 DIR_ITEM 2145353946) itemoff 3137 itemsize 53 location key (2722006 INODE_ITEM 0) type 1 namelen 23 datalen 0 name: timR18-ISO8859-9.pcf.gz item 16 key (923514 DIR_ITEM 2146914640) itemoff 3082 itemsize 55 location key (2723588 INODE_ITEM 0) type 1 namelen 25 datalen 0 name: lutBS12-ISO8859-14.pcf.gz item 17 key (923514 DIR_ITEM 2153679091) itemoff 3026 itemsize 56 location key (2722231 INODE_ITEM 0) type 1 namelen 26 datalen 0 name: UTB___12-ISO8859-10.pcf.gz item 18 key (923514 DIR_ITEM 2155361241) itemoff 2971 itemsize 55 location key (2721854 INODE_ITEM 0) type 1 namelen 25 datalen 0 name: UTRG__24-ISO8859-3.pcf.gz item 19 key (923514 DIR_ITEM 2164008501) itemoff 2917 itemsize 54 location key (2723441 INODE_ITEM 0) type 1 namelen 24 datalen 0 name: lubR14-ISO8859-13.pcf.gz item 20 key (923514 DIR_ITEM 2164058590) itemoff 2872 itemsize 45 location key (2722030 INODE_ITEM 0) type 1 namelen 15 datalen 0 name: courBO18.pcf.gz item 21 key (923514 DIR_ITEM 2164312387) itemoff 2827 itemsize 45 location key (2722107 INODE_ITEM 0) type 1 namelen 15 datalen 0 name: ncenBI12.pcf.gz item 22 key (923514 DIR_ITEM 2166794582) itemoff 2773 itemsize 54 location key (2722054 INODE_ITEM 0) type 1 namelen 24 datalen 0 name: timB08-ISO8859-10.pcf.gz item 23 key (923514 DIR_ITEM 2168622352) itemoff 2718 itemsize 55 location key (2722318
Re: can't read superblock (but could mount)
On Tue, Feb 14, 2012 at 06:37:16PM +0100, Timo Nentwig wrote: On Mon, 13 Feb 2012, Chris Mason wrote: btrfs-debug-tree -b 9872289792 /dev/xxx # btrfs-debug-tree -b 9872289792 /dev/loop1 leaf 9872289792 items 51 free space 0 generation 120351 owner 5 Ok, so this block is full of directory items, definitely not crucial to mounting. # btrfsck /dev/loop1 Extent back ref already exists for 9872289792 parent 0 root 5 leaf parent key incorrect 9872289792 bad block 9872289792 The block is also corrupted, as in the keys in the block aren't what we expect. ref mismatch on [9872289792 4096] extent item 1, found 2 Incorrect global backref count on 9872289792 found 1 wanted 2 backpointer mismatch on [9872289792 4096] owner ref check failed [9872289792 4096] ref mismatch on [9889067008 4096] extent item 1, found 0 Backref 9889067008 root 5 not referenced Incorrect global backref count on 9889067008 found 1 wanted 0 backpointer mismatch on [9889067008 4096] owner ref check failed [9889067008 4096] ref mismatch on [37163102208 65536] extent item 1, found 0 Incorrect local backref count on 37163102208 root 5 owner 3360937 offset 0 found 0 wanted 1 backpointer mismatch on [37163102208 65536] owner ref check failed [37163102208 65536] ref mismatch on [37163814912 36864] extent item 0, found 1 Backref 37163814912 root 5 owner 3360939 offset 0 num_refs 0 not found in extent tree Incorrect local backref count on 37163814912 root 5 owner 3360939 offset 0 found 1 wanted 0 backpointer mismatch on [37163814912 36864] And then we have a few other blocks with incorrect reference counts. found 15491117056 bytes used err is 1 total csum bytes: 14764500 total tree bytes: 366956544 total fs tree bytes: 317714432 btree space waste bytes: 90628933 file data blocks allocated: 16182484992 referenced 17813028864 Btrfs Btrfs v0.19 # mount /dev/loop1 /tmp/b mount: block device /dev/loop1 is write-protected, mounting read-only # ls /tmp/b bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var vm # echo hooray! Please explain :) I didn't do it ;) All the commands I asked you to run were readonly. The block is still corrupted. You've switched from /dev/sda to /dev/loop0, and loop0 is readonly. So the readonly mount may be stopping us from going into that bad branch of your tree (orphan cleanup perhaps). Regardless, the corrupt block isn't crucial, you should easily be able to copy things off. As for how we got here, I think you said you were originally running something older than 3.2 when these problems started, correct? -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: can't read superblock (but could mount)
On Tue, 14 Feb 2012, Chris Mason wrote: As for how we got here, I think you said you were originally running something older than 3.2 when these problems started, correct? Nope, I was already on 3.2.1 or 3.2.4. I restored a backup in the meantime and already had to soft-reset the box: # ls -ltr ~/.kde4/share/config/ ls: reading directory /home/foo/.kde4/share/config/: Input/output error Sigh... -- 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 1/3] Add the snappy-c compressor to lib v2
(BTW: If you're ever reworking this patch set, I'd like to make an ad hoc request for slightly different names for fs/btrfs/snappy.c and lib/snappy.c) Why? When building a x86 kernel, I get the following errors: CC [M] lib/snappy.o lib/snappy.c: In function 'snappy_init_env': lib/snappy.c:1268:2: error: implicit declaration of function 'vmalloc' CC [M] fs/btrfs/free-space-cache.o lib/snappy.c:1268:18: warning: assignment makes pointer from integer without a cast lib/snappy.c: In function 'snappy_free_env': lib/snappy.c:1293:2: error: implicit declaration of function 'vfree' make[1]: *** [lib/snappy.o] Error 1 make: *** [lib] Error 2 The error clears with this patch: Added thanks. -Andi -- 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: [RFB] add LZ4 compression method to btrfs
Silesia corpus (avg of 10 runs), AMD bulldozer box, 12G ram, 1Ghz cpu: lz4 = 739860 us ( 286 MB/s) 195930 us (1081 MB/s) 211957760 - 101630873 47.9% snappy 1.0.4 = 1050 ms ( 201 MB/s) 248 ms ( 853 MB/s) 211957760 - 104739310 49.4% snappy-c = 940111 us ( 225 MB/s) 299690 us ( 707 MB/s) 211957760 - 131060567 61.8% lzo 2.06 1x_1= 739421 us ( 286 MB/s) 436542 us ( 485 MB/s) 211957760 - 100576151 47.5% Silesia corpus (avg of 10 runs), Nehalem X7560, 2.3Ghz cpu: lz4 = 624170 us ( 339 MB/s) 200622 us (1056 MB/s) 211957760 - 101630873 47.9% snappy 1.0.4 = 1047 ms ( 202 MB/s) 265 ms ( 797 MB/s) 211957760 - 104739310 49.4% snappy-c = 836415 us ( 253 MB/s) 300567 us ( 705 MB/s) 211957760 - 131060567 61.8% lzo 2.06 1x_1= 639305 us ( 331 MB/s) 470840 us ( 450 MB/s) 211957760 - 100576151 47.5% Are you sure about these figures ? the difference seems too large. It's almost unbelievable. -- 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: [RFB] add LZ4 compression method to btrfs
Markus Lindberg marcuslindb...@gmail.com writes: Are you sure about these figures ? the difference seems too large. It's almost unbelievable. Yes, my benchmarks totally disagree with them. In my tests lz4 is generally slower than snappy-c. -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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: can't read superblock (but could mount)
On Tue, Feb 14, 2012 at 07:54:43PM +0100, Timo Nentwig wrote: On Tue, 14 Feb 2012, Chris Mason wrote: As for how we got here, I think you said you were originally running something older than 3.2 when these problems started, correct? Nope, I was already on 3.2.1 or 3.2.4. I restored a backup in the meantime and already had to soft-reset the box: Ok, 3.2 shouldn't have done this. Was this an external drive? What else do you have on the system? # ls -ltr ~/.kde4/share/config/ ls: reading directory /home/foo/.kde4/share/config/: Input/output error Sigh... Is this the same FS that was corrupted or a different one? -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: [RFB] add LZ4 compression method to btrfs
Are you sure about these figures ? the difference seems too large. It's almost unbelievable. -- You should not, Mark Ruijter found the same for LessFS (http://www.lessfs.com/wordpress/? p=688) and there is also such finding into an Hadoop thread (https://scribe.twitter.com/#!/otisg/status/148848850914902016) -- 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 1/3] Add the snappy-c compressor to lib v2
On Tue, Feb 14, 2012 at 1:52 PM, Andi Kleen a...@linux.intel.com wrote: (BTW: If you're ever reworking this patch set, I'd like to make an ad hoc request for slightly different names for fs/btrfs/snappy.c and lib/snappy.c) Why? It's not a big deal, I just found it confusing at first to see snappy.c being a different file in two places. -- 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] Btrfs-progs: add \btrfs subvolume get-default\ subcommand
Hi Xin / Hugo,
I am referring to
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
has miss match parameter list for list_subvols
--
# cd btrfs-progs
# egrep list_subvols *
btrfs_cmds.c: ret = list_subvols(fd, print_parent, 0);
btrfs_cmds.c: ret = list_subvols(fd, 0, 1);
btrfs_cmds.h:int list_subvols(int fd, int print_parent, int get_default);
-
btrfs-list.c:int list_subvols(int fd, int print_parent) -
--
--
# egrep -A 3 list_subvols btrfs-list.c
int list_subvols(int fd, int print_parent)
{
struct root_lookup root_lookup;
struct rb_node *n;
--
Looks like the following patch was checked in partially.
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg11103.html
Could you pls take a look / comment.
thxs, -Anand
--
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: can't read superblock (but could mount)
On Tue, 14 Feb 2012, Chris Mason wrote: Ok, 3.2 shouldn't have done this. Was this an external drive? What else do you have on the system? Nothing special actually. Standard arch linux with virtualbox kernel modules. It's a SSD if this should matter. Mounted with ssd,compress=lzo,noatime. Is this the same FS that was corrupted or a different one? Different one. Created from an old 3.2.1 gentoo install (btrfs 0.19-dirty). -- 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
