Re: [PATCH] xfstests 276: fix error 'FIBMAP: Invalid argument'
HI, This issue still exists when xfstests is run on debian although xfstests has contained this patch. root@debian-i386:/home/zwu/xfstests# git describe linux-v3.8-122-gdc75401 root@debian-i386:/home/zwu/xfstests# uname -a Linux debian-i386 3.10.0-rc2+ #3 SMP Sun May 26 14:04:13 CST 2013 x86_64 GNU/Linux root@debian-i386:/home/zwu/xfstests# - output mismatch (see /home/zwu/xfstests/results/btrfs/276.out.bad) --- tests/btrfs/276.out2013-05-25 15:09:01.0 + +++ /home/zwu/xfstests/results/btrfs/276.out.bad2013-05-26 09:31:49.962876905 + @@ -1,3 +1,32393 @@ QA output created by 276 *** test backref walking +FIBMAP: Invalid argument +FIBMAP: Invalid argument +FIBMAP: Invalid argument +FIBMAP: Invalid argument +FIBMAP: Invalid argument ... (Run 'diff -u tests/btrfs/276.out /home/zwu/xfstests/results/btrfs/276.out.bad' to see the entire diff) [ 3877.215268] device fsid 8367602a-14fa-49eb-aff0-44da1faa3b45 devid 1 transid 239 /dev/vdb [ 3877.218417] btrfs: disk space caching is enabled Ran: btrfs/276 Failures: btrfs/276 Failed 1 of 1 tests On Wed, Mar 6, 2013 at 2:43 AM, Rich Johnston rjohns...@sgi.com wrote: This patch has been committed. --Rich commit eba3a5206cd7f8df73d6e6dbf2bb0afca677fca8 Author: Wang Sheng-Hui shh...@gmail.com Date: Thu Feb 28 02:05:56 2013 + xfstests 276: fix error 'FIBMAP: Invalid argument' Commit 05dadc0 (Btrfs: add fiemap's flag check) added validity checks to the fiemap flags and hence invalid flags are now being rejected. Test 276 passes an invalid fiemap flag to btrfs, and so that test fails since this commit was added. Btrfs doesn't support FIEMAP_FLAG_XATTR, which is enabled by -x option of filefrag, and will fail with 'FIBMAP: Invalid argument' for 'filefrag -vx'. 'filefrag -vx' fails on btrfs with 'FIEMAP failed with unsupported flags 2' Remove the '-x' option. ___ xfs mailing list x...@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs -- Regards, Zhi Yong Wu -- 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: Recommended settings for SSD
On Sat, May 25, 2013 at 11:33 PM, Harald Glatt m...@hachre.de wrote:
Data that already exists will only be compressed on re-write. You can
do it with btrfs fi defrag and a script that traverses the fs to call
defrag on every file. Another good way is the find command that has
been outlined here:
https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#Defragmenting_a_directory_doesn.27t_work
I tried to my home partition the 'find' command and worked without
errors, not sure if it did compress (how can I check?). I tried also
on the root partition and every file that was in use (obviously) it
didn't defrag it. I am guessing I have to mount the partition from a
LiveCD but since the LiceCD kernel is usually old (in terms of btrfs)
do you reckon there will be any problems?
Thanks
--
Caution: breathing may be hazardous to your health.
#include stdio.h
int main(){printf(%s,\x4c\x65\x6f\x6e\x69\x64\x61\x73);}
--
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: compression on external hard drive?
On 05/26/2013 04:23 AM, Duncan wrote: Xavier Gnata posted on Sun, 26 May 2013 00:11:55 +0200 as excerpted: Nowdays, external hard drives are mounted automagically by kde, gnome or whatever else. How is it suppose to work with external hard drives using btrfs with compression? If a btrfs filesystem lzo-compressed is mounted without the |compress=|xxx option then all the newly created files are uncompressed, aren't then? Would it be possible to detect if a file system is compressed and to mount it *automatically* and accordingly (except otherwise explicitly stated by the user) with/without the lzo/gzip option? There's a proposal to do something like ext3/4's default options as set by tune2fs, at some point, presumably before btrfs loses the unstable disk format and under heavy development warnings. However, there's nothing like that yet, AFAIK, so most options must be set per-mount. There's a lot you can do with udev events, however, and strongly suspect either compression-detection, or match-against-a-list-and-compress (or don't compress if the default is compression otherwise) if the UUID/LABEL is listed. Alternatively, at least kde can be set not to automount specific UUIDs/ LABELs, and then there's always the traditional fstab option, and I think either fstab entered drives are ignored by the automount system or they're automounted with options from fstab (I have that kde subsystem entirely disabled here so it doesn't automount anything, so I'm not sure which it actually does). Ok I'm going to play with udev event and have a lot at what kde4.10.3 can do. However, I hope this will be solved at fs level once the dust has settled. Xavier -- 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 1/5] Btrfs: fix use-after-free bug during umount
Commit be283b2e674a09457d4563729015adb637ce7cc1 (Btrfs: use helper to cleanup tree roots) introduced the following bug, BUG: unable to handle kernel NULL pointer dereference at 0034 IP: [a039368c] extent_buffer_get+0x4/0xa [btrfs] [...] Pid: 2463, comm: btrfs-cache-1 Tainted: G O 3.9.0+ #4 innotek GmbH VirtualBox/VirtualBox RIP: 0010:[a039368c] [a039368c] extent_buffer_get+0x4/0xa [btrfs] Process btrfs-cache-1 (pid: 2463, threadinfo 880112d6, task 880117679730) [...] Call Trace: [a0398a99] btrfs_search_slot+0x104/0x64d [btrfs] [a039aea4] btrfs_next_old_leaf+0xa7/0x334 [btrfs] [a039b141] btrfs_next_leaf+0x10/0x12 [btrfs] [a039ea13] caching_thread+0x1a3/0x2e0 [btrfs] [a03d8811] worker_loop+0x14b/0x48e [btrfs] [a03d86c6] ? btrfs_queue_worker+0x25c/0x25c [btrfs] [81068d3d] kthread+0x8d/0x95 [81068cb0] ? kthread_freezable_should_stop+0x43/0x43 [8151e5ac] ret_from_fork+0x7c/0xb0 [81068cb0] ? kthread_freezable_should_stop+0x43/0x43 RIP [a039368c] extent_buffer_get+0x4/0xa [btrfs] We've free'ed commit_root before actually getting to free block groups where caching thread needs valid extent_root-commit_root. Signed-off-by: Liu Bo bo.li@oracle.com --- fs/btrfs/disk-io.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index e7b3cb5..a5c8f28 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3512,10 +3512,10 @@ int close_ctree(struct btrfs_root *root) percpu_counter_sum(fs_info-delalloc_bytes)); } - free_root_pointers(fs_info, 1); - btrfs_free_block_groups(fs_info); + free_root_pointers(fs_info, 1); + del_fs_roots(fs_info); iput(fs_info-btree_inode); -- 1.7.7 -- 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 2/5] Btrfs: update new flags for tracepoint
Adding new flags to keep tracepoints consistent with btrfs.
Signed-off-by: Liu Bo bo.li@oracle.com
---
include/trace/events/btrfs.h | 35 +++
1 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h
index ea546a4..2902657 100644
--- a/include/trace/events/btrfs.h
+++ b/include/trace/events/btrfs.h
@@ -40,22 +40,25 @@ struct extent_buffer;
{ BTRFS_ROOT_TREE_DIR_OBJECTID, ROOT_TREE_DIR }, \
{ BTRFS_CSUM_TREE_OBJECTID, CSUM_TREE }, \
{ BTRFS_TREE_LOG_OBJECTID, TREE_LOG }, \
+ { BTRFS_QUOTA_TREE_OBJECTID,QUOTA_TREE}, \
{ BTRFS_TREE_RELOC_OBJECTID,TREE_RELOC}, \
{ BTRFS_DATA_RELOC_TREE_OBJECTID, DATA_RELOC_TREE })
#define show_root_type(obj)\
obj, ((obj = BTRFS_DATA_RELOC_TREE_OBJECTID) ||\
(obj = BTRFS_ROOT_TREE_OBJECTID\
- obj = BTRFS_CSUM_TREE_OBJECTID)) ? __show_root_type(obj) : -
+ obj = BTRFS_QUOTA_TREE_OBJECTID)) ? __show_root_type(obj) : -
#define BTRFS_GROUP_FLAGS \
- { BTRFS_BLOCK_GROUP_DATA, DATA}, \
- { BTRFS_BLOCK_GROUP_SYSTEM, SYSTEM}, \
- { BTRFS_BLOCK_GROUP_METADATA, METADATA}, \
- { BTRFS_BLOCK_GROUP_RAID0, RAID0}, \
- { BTRFS_BLOCK_GROUP_RAID1, RAID1}, \
- { BTRFS_BLOCK_GROUP_DUP,DUP}, \
- { BTRFS_BLOCK_GROUP_RAID10, RAID10}
+ { BTRFS_BLOCK_GROUP_DATA, DATA},\
+ { BTRFS_BLOCK_GROUP_SYSTEM, SYSTEM}, \
+ { BTRFS_BLOCK_GROUP_METADATA, METADATA},\
+ { BTRFS_BLOCK_GROUP_RAID0, RAID0}, \
+ { BTRFS_BLOCK_GROUP_RAID1, RAID1}, \
+ { BTRFS_BLOCK_GROUP_DUP,DUP}, \
+ { BTRFS_BLOCK_GROUP_RAID10, RAID10}, \
+ { BTRFS_BLOCK_GROUP_RAID5, RAID5}, \
+ { BTRFS_BLOCK_GROUP_RAID6, RAID6}
#define BTRFS_UUID_SIZE 16
@@ -154,7 +157,9 @@ DEFINE_EVENT(btrfs__inode, btrfs_inode_evict,
{ EXTENT_FLAG_PINNED, PINNED}, \
{ EXTENT_FLAG_COMPRESSED, COMPRESSED}, \
{ EXTENT_FLAG_VACANCY, VACANCY }, \
- { EXTENT_FLAG_PREALLOC, PREALLOC })
+ { EXTENT_FLAG_PREALLOC, PREALLOC }, \
+ { EXTENT_FLAG_LOGGING, LOGGING }, \
+ { EXTENT_FLAG_FILLING, FILLING })
TRACE_EVENT(btrfs_get_extent,
@@ -201,13 +206,17 @@ TRACE_EVENT(btrfs_get_extent,
);
#define show_ordered_flags(flags) \
- __print_symbolic(flags, \
+ __print_symbolic(flags, \
{ BTRFS_ORDERED_IO_DONE,IO_DONE }, \
{ BTRFS_ORDERED_COMPLETE, COMPLETE }, \
{ BTRFS_ORDERED_NOCOW, NOCOW }, \
{ BTRFS_ORDERED_COMPRESSED, COMPRESSED}, \
{ BTRFS_ORDERED_PREALLOC, PREALLOC }, \
- { BTRFS_ORDERED_DIRECT, DIRECT})
+ { BTRFS_ORDERED_DIRECT, DIRECT}, \
+ { BTRFS_ORDERED_IOERR, IOERR }, \
+ { BTRFS_ORDERED_UPDATED_ISIZE, UPDATED_ISIZE }, \
+ { BTRFS_ORDERED_LOGGED_CSUM,LOGGED_CSUM })
+
DECLARE_EVENT_CLASS(btrfs__ordered_extent,
@@ -555,7 +564,9 @@ TRACE_EVENT(btrfs_delayed_ref_head,
{ BTRFS_BLOCK_GROUP_RAID0, RAID0 }, \
{ BTRFS_BLOCK_GROUP_RAID1, RAID1 }, \
{ BTRFS_BLOCK_GROUP_DUP,DUP }, \
- { BTRFS_BLOCK_GROUP_RAID10, RAID10})
+ { BTRFS_BLOCK_GROUP_RAID10, RAID10}, \
+ { BTRFS_BLOCK_GROUP_RAID5, RAID5 }, \
+ { BTRFS_BLOCK_GROUP_RAID6, RAID6 })
DECLARE_EVENT_CLASS(btrfs__chunk,
--
1.7.7
--
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/5] Btrfs: kill replicate code in replay_one_buffer
EXTREF is treated same as REF, so we can make the code tidy.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/tree-log.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index c276ac9..3f30053 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2016,13 +2016,8 @@ static int replay_one_buffer(struct btrfs_root *log,
struct extent_buffer *eb,
eb, i, key);
if (ret)
break;
- } else if (key.type == BTRFS_INODE_REF_KEY) {
- ret = add_inode_ref(wc-trans, root, log, path,
- eb, i, key);
- if (ret ret != -ENOENT)
- break;
- ret = 0;
- } else if (key.type == BTRFS_INODE_EXTREF_KEY) {
+ } else if (key.type == BTRFS_INODE_REF_KEY ||
+ key.type == BTRFS_INODE_EXTREF_KEY) {
ret = add_inode_ref(wc-trans, root, log, path,
eb, i, key);
if (ret ret != -ENOENT)
--
1.7.7
--
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 4/5 RESEND] Btrfs: remove unused code in btrfs_del_root
'leaf' and 'ri' is not used somehow.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/root-tree.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
index 5bf1ed5..4a5abda 100644
--- a/fs/btrfs/root-tree.c
+++ b/fs/btrfs/root-tree.c
@@ -368,8 +368,6 @@ int btrfs_del_root(struct btrfs_trans_handle *trans, struct
btrfs_root *root,
{
struct btrfs_path *path;
int ret;
- struct btrfs_root_item *ri;
- struct extent_buffer *leaf;
path = btrfs_alloc_path();
if (!path)
@@ -379,8 +377,6 @@ int btrfs_del_root(struct btrfs_trans_handle *trans, struct
btrfs_root *root,
goto out;
BUG_ON(ret != 0);
- leaf = path-nodes[0];
- ri = btrfs_item_ptr(leaf, path-slots[0], struct btrfs_root_item);
ret = btrfs_del_item(trans, root, path);
out:
--
1.7.7
--
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 5/5 RESEND] Btrfs: allow file data clone within a file
We did not allow file data clone within the same file because of
deadlock issues.
However, we now use nested lock to avoid deadlock between the
parent directory and the child file.
So it's safe to do file clone within the same file when the two
ranges are not overlapped.
Reviewed-by: David Sterba dste...@suse.cz
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/ioctl.c | 26 +++---
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 0f81d67..112153a 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2480,6 +2480,7 @@ static noinline long btrfs_ioctl_clone(struct file *file,
unsigned long srcfd,
int ret;
u64 len = olen;
u64 bs = root-fs_info-sb-s_blocksize;
+ int same_inode = 0;
/*
* TODO:
@@ -2516,7 +2517,7 @@ static noinline long btrfs_ioctl_clone(struct file *file,
unsigned long srcfd,
ret = -EINVAL;
if (src == inode)
- goto out_fput;
+ same_inode = 1;
/* the src must be open for reading */
if (!(src_file.file-f_mode FMODE_READ))
@@ -2547,12 +2548,16 @@ static noinline long btrfs_ioctl_clone(struct file
*file, unsigned long srcfd,
}
path-reada = 2;
- if (inode src) {
- mutex_lock_nested(inode-i_mutex, I_MUTEX_PARENT);
- mutex_lock_nested(src-i_mutex, I_MUTEX_CHILD);
+ if (!same_inode) {
+ if (inode src) {
+ mutex_lock_nested(inode-i_mutex, I_MUTEX_PARENT);
+ mutex_lock_nested(src-i_mutex, I_MUTEX_CHILD);
+ } else {
+ mutex_lock_nested(src-i_mutex, I_MUTEX_PARENT);
+ mutex_lock_nested(inode-i_mutex, I_MUTEX_CHILD);
+ }
} else {
- mutex_lock_nested(src-i_mutex, I_MUTEX_PARENT);
- mutex_lock_nested(inode-i_mutex, I_MUTEX_CHILD);
+ mutex_lock(src-i_mutex);
}
/* determine range to clone */
@@ -2570,6 +2575,12 @@ static noinline long btrfs_ioctl_clone(struct file
*file, unsigned long srcfd,
!IS_ALIGNED(destoff, bs))
goto out_unlock;
+ /* verify if ranges are overlapped within the same file */
+ if (same_inode) {
+ if (destoff + len off destoff off + len)
+ goto out_unlock;
+ }
+
if (destoff inode-i_size) {
ret = btrfs_cont_expand(inode, inode-i_size, destoff);
if (ret)
@@ -2846,7 +2857,8 @@ out:
unlock_extent(BTRFS_I(src)-io_tree, off, off + len - 1);
out_unlock:
mutex_unlock(src-i_mutex);
- mutex_unlock(inode-i_mutex);
+ if (!same_inode)
+ mutex_unlock(inode-i_mutex);
vfree(buf);
btrfs_free_path(path);
out_fput:
--
1.7.7
--
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: Recommended settings for SSD
I don't know a better way to check than doing df -h before and
after... If you use space_cache you have to clear_cache though to make
the numbers be current for sure each time before looking at df.
Old kernel can be a problem. You can use the Arch CDs to do it, they
usually come with the newest kernels.
https://www.archlinux.org/download/
If you need to install anything a quick guide to the package managing:
# Update Repos and Upgrade system:
pacman -Suy
# Install a specific package:
pacman -S packagename
# Search for a package
pacman -Ss search term
On Sun, May 26, 2013 at 12:00 PM, Leonidas Spyropoulos
artafi...@gmail.com wrote:
On Sat, May 25, 2013 at 11:33 PM, Harald Glatt m...@hachre.de wrote:
Data that already exists will only be compressed on re-write. You can
do it with btrfs fi defrag and a script that traverses the fs to call
defrag on every file. Another good way is the find command that has
been outlined here:
https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#Defragmenting_a_directory_doesn.27t_work
I tried to my home partition the 'find' command and worked without
errors, not sure if it did compress (how can I check?). I tried also
on the root partition and every file that was in use (obviously) it
didn't defrag it. I am guessing I have to mount the partition from a
LiveCD but since the LiceCD kernel is usually old (in terms of btrfs)
do you reckon there will be any problems?
Thanks
--
Caution: breathing may be hazardous to your health.
#include stdio.h
int main(){printf(%s,\x4c\x65\x6f\x6e\x69\x64\x61\x73);}
--
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: Recommended settings for SSD
On Sun, May 26, 2013 at 9:16 AM, Harald Glatt m...@hachre.de wrote: I don't know a better way to check than doing df -h before and after... If you use space_cache you have to clear_cache though to make the numbers be current for sure each time before looking at df. Not sure what you're thinking of; space_cache is just a mount-time optimization, storing and loading a memory structure to disk so that it doesn't have to be regenerated. As I understand it, if it's ever wrong, it's a serious bug. -- 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] xfstests 276: fix error 'FIBMAP: Invalid argument'
On 5/26/13 4:35 AM, Zhi Yong Wu wrote: HI, This issue still exists when xfstests is run on debian although xfstests has contained this patch. this issue must be different, then; same error (Invalid argument) but it can no longer be due to the -x option to filefrag. There must be some other root cause. Needs investigation on the btrfs side. IOWs, this looks like it could be a regression in btrfs? -Eric root@debian-i386:/home/zwu/xfstests# git describe linux-v3.8-122-gdc75401 root@debian-i386:/home/zwu/xfstests# uname -a Linux debian-i386 3.10.0-rc2+ #3 SMP Sun May 26 14:04:13 CST 2013 x86_64 GNU/Linux root@debian-i386:/home/zwu/xfstests# - output mismatch (see /home/zwu/xfstests/results/btrfs/276.out.bad) --- tests/btrfs/276.out2013-05-25 15:09:01.0 + +++ /home/zwu/xfstests/results/btrfs/276.out.bad2013-05-26 09:31:49.962876905 + @@ -1,3 +1,32393 @@ QA output created by 276 *** test backref walking +FIBMAP: Invalid argument +FIBMAP: Invalid argument +FIBMAP: Invalid argument +FIBMAP: Invalid argument +FIBMAP: Invalid argument ... (Run 'diff -u tests/btrfs/276.out /home/zwu/xfstests/results/btrfs/276.out.bad' to see the entire diff) [ 3877.215268] device fsid 8367602a-14fa-49eb-aff0-44da1faa3b45 devid 1 transid 239 /dev/vdb [ 3877.218417] btrfs: disk space caching is enabled Ran: btrfs/276 Failures: btrfs/276 Failed 1 of 1 tests On Wed, Mar 6, 2013 at 2:43 AM, Rich Johnston rjohns...@sgi.com wrote: This patch has been committed. --Rich commit eba3a5206cd7f8df73d6e6dbf2bb0afca677fca8 Author: Wang Sheng-Hui shh...@gmail.com Date: Thu Feb 28 02:05:56 2013 + xfstests 276: fix error 'FIBMAP: Invalid argument' Commit 05dadc0 (Btrfs: add fiemap's flag check) added validity checks to the fiemap flags and hence invalid flags are now being rejected. Test 276 passes an invalid fiemap flag to btrfs, and so that test fails since this commit was added. Btrfs doesn't support FIEMAP_FLAG_XATTR, which is enabled by -x option of filefrag, and will fail with 'FIBMAP: Invalid argument' for 'filefrag -vx'. 'filefrag -vx' fails on btrfs with 'FIEMAP failed with unsupported flags 2' Remove the '-x' option. ___ xfs mailing list x...@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs -- 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
Btrfsck errors (fs tree 565 refs 125 not found) - how serious
Hi, For about 3 weeks I've been using btrfs on my desktop machine, using the snapshot-functionality quite a lot. Today I ran btrfsck and got about ~10MB of output which looks like: fs tree 565 refs 125 not found unresolved ref root 807 dir 813347 index 277 namelen 39 name snapshot_1368273601_2013-05-11_14:00:01 error 600 unresolved ref root 808 dir 813347 index 277 namelen 39 name snapshot_1368273601_2013-05-11_14:00:01 error 600 ... fs tree 566 refs 125 not found unresolved ref root 807 dir 813347 index 278 namelen 39 name snapshot_1368274201_2013-05-11_14:10:01 error 600 unresolved ref root 808 dir 813347 index 278 namelen 39 name snapshot_1368274201_2013-05-11_14:10:01 error 600 .. while the log contained a lot of different values for fs tree, the refs which were not found stays fairly constant: refs: 125, 397, 398, 406, 407, 420 How serious are those issues, should I be worried? Would it help if I find ways to reproduce this behaviour on a fresh btrfs filesystem? Thank you in advance, Clemens -- 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
[Question] How to restore btrfs raid0 image file?
Hi, So the case is, now I've got a btrfs image file, which is created from a raid0 btrfs fs. And if I run 'btrfs-image -r image_file /dev/sdf', then I have to mount it with 'degraded' mode, and that still fails because raid0 requires two disks at least. So any ideas how to make it work? thanks, liubo -- 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
