[RFC PATCH] Trace: use unsigned long long in trace print frames
While adding tracepoint for btrfs, I got a problem:
btrfs uses some macros with ULL type, but tracepoint's macros,
__print_[flags,symbols](), only have unsigned long, so on 32bit box
there will be 64-32 truncate WARNINGs when compiling.
Here I'm inclined to make the replacement to clear those WARNINGs.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
include/linux/ftrace_event.h |7 ---
kernel/trace/trace_output.c | 10 +-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 22b32af..b52f2c5 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -12,15 +12,16 @@ struct tracer;
struct dentry;
struct trace_print_flags {
- unsigned long mask;
+ unsigned long long mask;
const char *name;
};
const char *ftrace_print_flags_seq(struct trace_seq *p, const char *delim,
- unsigned long flags,
+ unsigned long long flags,
const struct trace_print_flags *flag_array);
-const char *ftrace_print_symbols_seq(struct trace_seq *p, unsigned long val,
+const char *ftrace_print_symbols_seq(struct trace_seq *p,
+unsigned long long val,
const struct trace_print_flags
*symbol_array);
const char *ftrace_print_hex_seq(struct trace_seq *p,
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 456be90..97ba902 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -294,10 +294,10 @@ int trace_seq_path(struct trace_seq *s, struct path *path)
const char *
ftrace_print_flags_seq(struct trace_seq *p, const char *delim,
- unsigned long flags,
+ unsigned long long flags,
const struct trace_print_flags *flag_array)
{
- unsigned long mask;
+ unsigned long long mask;
const char *str;
const char *ret = p-buffer + p-len;
int i;
@@ -319,7 +319,7 @@ ftrace_print_flags_seq(struct trace_seq *p, const char
*delim,
if (flags) {
if (p-len delim)
trace_seq_puts(p, delim);
- trace_seq_printf(p, 0x%lx, flags);
+ trace_seq_printf(p, 0x%llx, flags);
}
trace_seq_putc(p, 0);
@@ -329,7 +329,7 @@ ftrace_print_flags_seq(struct trace_seq *p, const char
*delim,
EXPORT_SYMBOL(ftrace_print_flags_seq);
const char *
-ftrace_print_symbols_seq(struct trace_seq *p, unsigned long val,
+ftrace_print_symbols_seq(struct trace_seq *p, unsigned long long val,
const struct trace_print_flags *symbol_array)
{
int i;
@@ -345,7 +345,7 @@ ftrace_print_symbols_seq(struct trace_seq *p, unsigned long
val,
}
if (!p-len)
- trace_seq_printf(p, 0x%lx, val);
+ trace_seq_printf(p, 0x%llx, val);
trace_seq_putc(p, 0);
--
1.6.5.2
--
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 free space cache when there are pinned extents and clusters
+ spin_lock(block_group-tree_lock);
+ if (btrfs_block_group_free_space(block_group) !=
This function call can be replaced by block_group-free_space, so
we don't have to iterate the tree.
(This function gets removed in my patchset for inode number caching)
+ (block_group-key.offset - used - block_group-bytes_super)) {
+ spin_unlock(block_group-tree_lock);
+ printk(KERN_ERR block group %llu has an wrong amount of free
+space\n, block_group-key.objectid);
+ ret = 0;
+ goto free_cache;
+ }
+ spin_unlock(block_group-tree_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
Re: btrfs balancing start - and stop?
Hallo, Struan, Du meintest am 01.04.11: 1) Is the balancing operation expected to take many hours (or days?) on a filesystem such as this? Or are there known issues with the algorithm that are yet to be addressed? May be. Balancing about 15 GByte needed about 2 hours (or less), balancing about 2 TByte needed about 20 hours. dmesg counts down the number of remaining jobs. Viele Gruesse! Helmut -- 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 free space cache when there are pinned extents and clusters
On Fri, Apr 01, 2011 at 03:56:33PM +0800, Li Zefan wrote: + spin_lock(block_group-tree_lock); + if (btrfs_block_group_free_space(block_group) != This function call can be replaced by block_group-free_space, so we don't have to iterate the tree. (This function gets removed in my patchset for inode number caching) Ah yeah good point, 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 balancing start - and stop?
On 1/4/2011 3:12 μμ, Helmut Hullen wrote: Hallo, Struan, Du meintest am 01.04.11: 1) Is the balancing operation expected to take many hours (or days?) on a filesystem such as this? Or are there known issues with the algorithm that are yet to be addressed? May be. Balancing about 15 GByte needed about 2 hours (or less), balancing about 2 TByte needed about 20 hours. dmesg counts down the number of remaining jobs. are you sure? here is a snippet of dmesg from a balance i did yesterday (2.6.38.1) btrfs: relocating block group 15338569728 flags 9 btrfs: found 17296 extents btrfs: found 17296 extents btrfs: relocating block group 13191086080 flags 9 btrfs: found 21029 extents btrfs: found 21029 extents btrfs: relocating block group 11043602432 flags 9 btrfs: found 4728 extents btrfs: found 4728 extents Viele Gruesse! Helmut -- 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 -- 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: Do not use free space caching!
On 1/4/2011 1:59 πμ, Josef Bacik wrote: On Thu, Mar 31, 2011 at 05:06:42PM -0400, Calvin Walton wrote: On Wed, 2011-03-30 at 17:19 -0400, Josef Bacik wrote: Hello, Just found a big bug in the free space caching stuff that will result in early ENOSPC. I'm working on fixing this bug, but it won't be until tomorrow that I'll have it completely working, so for now make sure to mount -o clear_cache so that it just clears the cache and doesn't use it. NOTE: It doesn't cause problems other than early ENOSPC, you won't get corruption or anything like that, tho you could possibly panic. Sorry for the inconvenience. Thanks, Any chance you could provide a little more information about which kernels are affected? Is it any kernel with free space cache support (is 2.6.38.x included?) - and if so, do you plan on submitting the fix to the stable kernel series? Yeah it affects any kernel that has the free space cache feature, which I think started in .37. Course you have to have specifically enabled it, so it's not a huge problem. I've submitted a patch, but since it's currently an optional feature I don't think it needs to go to stable. Thanks, So it will have to wait for 2.6.39? If possible please push it for inclusion it in the next stable of 2.6.38, as 2.6.39 is a few months away and i wont risk an early RC for my system 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 -- 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 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Thu, Mar 31, 2011 at 08:02:22AM -0400, Chris Mason wrote: Excerpts from Christoph Hellwig's message of 2011-03-31 02:36:36 -0400: On Thu, Mar 31, 2011 at 12:00:11AM -0400, Larry D'Anna wrote: This is a simple patch to allow reflinks to be made crossing subvolume boundaries. NAK. subvolumes will have to become vfsmounts sooner or later, and we really must not support any operations spanning mountpoints. Sorry, I disagree here. reflinks were always intended to be able to span subvolumes. There's no conflict at all because they span different inodes. I don't think it's a good idea to introduce any user visible operations over subvolume boundaries. Currently we don't have any operations over mount boundaries, which is pretty fumdamental to the unix filesystem semantics. If you want to change this please come up with a clear description of the semantics and post it to linux-fsdevel for discussion. That of course requires a clear description of the btrfs subvolumes, which is still completely missing. -- 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 balancing start - and stop?
Hallo, Konstantinos, Du meintest am 01.04.11: dmesg counts down the number of remaining jobs. are you sure? here is a snippet of dmesg from a balance i did yesterday (2.6.38.1) btrfs: relocating block group 15338569728 flags 9 btrfs: found 17296 extents btrfs: found 17296 extents btrfs: relocating block group 13191086080 flags 9 btrfs: found 21029 extents btrfs: found 21029 extents btrfs: relocating block group 11043602432 flags 9 btrfs: found 4728 extents btrfs: found 4728 extents Yes - there I look how long the balancing job may still work. You see that the relocating line counts down: 15 13 11 ... Viele Gruesse! Helmut -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Trace: use unsigned long long in trace print frames
On Fri, 2011-04-01 at 14:42 +0800, liubo wrote: While adding tracepoint for btrfs, I got a problem: btrfs uses some macros with ULL type, but tracepoint's macros, __print_[flags,symbols](), only have unsigned long, so on 32bit box there will be 64-32 truncate WARNINGs when compiling. Here I'm inclined to make the replacement to clear those WARNINGs. Hmm, I don't like this. unsigned long is a natural word for architectures, I don't want to have 32 bit suffer because one user is doing something with ULL. A better solution is to add a trace_print_flags_u64 or something, that can be used for cases that u64 is needed. For archs were sizeof(long) == sizeof(u64) we can have the two macros/structs be the same. -- Steve -- 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 balancing start - and stop?
On Fri, Apr 01, 2011 at 03:36:00PM +0200, Helmut Hullen wrote: Hallo, Konstantinos, Du meintest am 01.04.11: dmesg counts down the number of remaining jobs. are you sure? here is a snippet of dmesg from a balance i did yesterday (2.6.38.1) btrfs: relocating block group 15338569728 flags 9 btrfs: found 17296 extents btrfs: found 17296 extents btrfs: relocating block group 13191086080 flags 9 btrfs: found 21029 extents btrfs: found 21029 extents btrfs: relocating block group 11043602432 flags 9 btrfs: found 4728 extents btrfs: found 4728 extents Yes - there I look how long the balancing job may still work. You see that the relocating line counts down: 15 13 11 ... It's not a good measure of time remaining, as the numbers there are pretty arbitrary: they're the start of the block group in btrfs's own internal address space. The balance algorithm will indeed go through the block groups in reverse order, but they're not guaranteed to terminate at zero. In fact, if you've balanced before, they're pretty much guaranteed to terminate a long way before zero. New block groups (for example, ones created during a balance) are always created with virtual addresses larger than any previous block group. So, if you started with block groups at addresses 1G, 2G, 3G, 4G and balanced, you'd end up with ones at 5G, 6G, 7G, 8G. The next time you balanced, you'd see the numbers count down: 8G, 7G, 6G, 5G, complete. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Happiness is mandatory. Are you happy? --- signature.asc Description: Digital signature
Re: btrfs balancing start - and stop?
On 1/4/2011 4:37 μμ, Hugo Mills wrote: On Fri, Apr 01, 2011 at 04:22:39PM +0300, Konstantinos Skarlatos wrote: On 1/4/2011 3:12 μμ, Helmut Hullen wrote: Du meintest am 01.04.11: dmesg counts down the number of remaining jobs. are you sure? here is a snippet of dmesg from a balance i did yesterday (2.6.38.1) btrfs: relocating block group 15338569728 flags 9 btrfs: found 17296 extents btrfs: found 17296 extents btrfs: relocating block group 13191086080 flags 9 btrfs: found 21029 extents btrfs: found 21029 extents btrfs: relocating block group 11043602432 flags 9 btrfs: found 4728 extents btrfs: found 4728 extents Count the number of block groups in the system (1GiB for data, 256MiB for metdata on a typical filesystem), and subtract the number of relocating block group messages... Not ideal, but it's possible. The balance cancel patch I mentioned earlier also supplies an additional patch for monitoring progress, which does show up in the dmesg output (as well as user-space support for prettier output). Great, I think it is very important to have a human-readable progress monitor for operations like that. Hugo. -- 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 free space cache when there are pinned extents and clusters V2
I noticed a huge problem with the free space cache that was presenting as an
early ENOSPC. Turns out when writing the free space cache out I forgot to take
into account pinned extents and more importantly clusters. This would result in
us leaking free space everytime we unmounted the filesystem and remounted it. I
fix this by making sure to check and see if the current block group has a
cluster and writing out any entries that are in the cluster to the cache, as
well as writing any pinned extents we currently have to the cache since those
will be available for us to use the next time the fs mounts. This patch also
adds a check to the end of load_free_space_cache to make sure we got the right
amount of free space cache, and if not make sure to clear the cache and re-cache
the old fashioned way. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
V1-V2:
- use block_group-free_space instead of
btrfs_block_group_free_space(block_group)
fs/btrfs/free-space-cache.c | 82 --
1 files changed, 78 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index f03ef97..74bc432 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -24,6 +24,7 @@
#include free-space-cache.h
#include transaction.h
#include disk-io.h
+#include extent_io.h
#define BITS_PER_BITMAP(PAGE_CACHE_SIZE * 8)
#define MAX_CACHE_BYTES_PER_GIG(32 * 1024)
@@ -222,6 +223,7 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info,
u64 num_entries;
u64 num_bitmaps;
u64 generation;
+ u64 used = btrfs_block_group_used(block_group-item);
u32 cur_crc = ~(u32)0;
pgoff_t index = 0;
unsigned long first_page_offset;
@@ -467,6 +469,17 @@ next:
index++;
}
+ spin_lock(block_group-tree_lock);
+ if (block_group-free_space != (block_group-key.offset - used -
+ block_group-bytes_super)) {
+ spin_unlock(block_group-tree_lock);
+ printk(KERN_ERR block group %llu has an wrong amount of free
+ space\n, block_group-key.objectid);
+ ret = 0;
+ goto free_cache;
+ }
+ spin_unlock(block_group-tree_lock);
+
ret = 1;
out:
kfree(checksums);
@@ -495,8 +508,11 @@ int btrfs_write_out_cache(struct btrfs_root *root,
struct list_head *pos, *n;
struct page *page;
struct extent_state *cached_state = NULL;
+ struct btrfs_free_cluster *cluster = NULL;
+ struct extent_io_tree *unpin = NULL;
struct list_head bitmap_list;
struct btrfs_key key;
+ u64 start, end, len;
u64 bytes = 0;
u32 *crc, *checksums;
pgoff_t index = 0, last_index = 0;
@@ -505,6 +521,7 @@ int btrfs_write_out_cache(struct btrfs_root *root,
int entries = 0;
int bitmaps = 0;
int ret = 0;
+ bool next_page = false;
root = root-fs_info-tree_root;
@@ -551,6 +568,18 @@ int btrfs_write_out_cache(struct btrfs_root *root,
*/
first_page_offset = (sizeof(u32) * num_checksums) + sizeof(u64);
+ /* Get the cluster for this block_group if it exists */
+ if (!list_empty(block_group-cluster_list))
+ cluster = list_entry(block_group-cluster_list.next,
+struct btrfs_free_cluster,
+block_group_list);
+
+ /*
+* We shouldn't have switched the pinned extents yet so this is the
+* right one
+*/
+ unpin = root-fs_info-pinned_extents;
+
/*
* Lock all pages first so we can lock the extent safely.
*
@@ -580,6 +609,12 @@ int btrfs_write_out_cache(struct btrfs_root *root,
lock_extent_bits(BTRFS_I(inode)-io_tree, 0, i_size_read(inode) - 1,
0, cached_state, GFP_NOFS);
+ /*
+* When searching for pinned extents, we need to start at our start
+* offset.
+*/
+ start = block_group-key.objectid;
+
/* Write out the extent entries */
do {
struct btrfs_free_space_entry *entry;
@@ -587,6 +622,8 @@ int btrfs_write_out_cache(struct btrfs_root *root,
unsigned long offset = 0;
unsigned long start_offset = 0;
+ next_page = false;
+
if (index == 0) {
start_offset = first_page_offset;
offset = start_offset;
@@ -598,7 +635,7 @@ int btrfs_write_out_cache(struct btrfs_root *root,
entry = addr + start_offset;
memset(addr, 0, PAGE_CACHE_SIZE);
- while (1) {
+ while (node !next_page) {
struct btrfs_free_space *e;
e = rb_entry(node, struct btrfs_free_space,
offset_index);
@@
Re: Cannot set-default back to ID 0
Bernhard Schmidt berni at birkenwald.de writes: Hi, a recent Ubuntu upgrade killed my system. Luckily I had done a btrfs snapshot before, so I set the particular subvolume as default using # btrfs subvolume set-default 261 /mnt from a rescue system and was back up in no time. I then mounted the original volume with subvolid=0 and repaired it. So far so good. However, I fail to set the default volume back to the original. # btrfs subvolume set-default 0 / apparently does nothing, I don't get an error but I'm still on the snapshot after reboot. Currently I'm working around this adding rootflag=subvolid=0 on the kernel command line, but that is kind of inconvenient. Is this expected? Ubuntu natty amd64, Kernel 2.6.38-rc5, btrfs-tools 0.19+20100601 Thanks Bernhard -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I was asking a similar question in IRC, and the answer I got was: The 0 alias for the top-level subvol is implemented in the kernel, not the userspace tools. I was however able to do this using: # btrfs subvolume set-default 5 / Using 5 for the _real_ subvolid Or alternatively: # mount -o defaults,subvolid=0 /mnt # btrfsctl -m /mnt/ It's a bit odd, agreed, and the people I spoke to seemed to agree as well =) - arand -- 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: [Ocfs2-devel] [PATCH 1/3] VFS/ioctl: Add punching-hole support to ioctl().
On Thu, Mar 31, 2011 at 08:34:50PM -0400, Josef Bacik wrote: More interesting would be to bring the ioctls up to generic code and have them backended by fallocate. I'm not sure they map without looking deeper, but it's at least an idea. I just did a cursory look and it seems like that would work out ok. Thanks, Note that ocfs2 and xfs have identical ioctl values (ocfs2 copied xfs's on purpose). Joel -- Life's Little Instruction Book #306 Take a nap on Sunday afternoons. http://www.jlbec.org/ jl...@evilplan.org -- 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: Do not use free space caching!
On Thu, 2011-03-31 at 18:59 -0400, Josef Bacik wrote: On Thu, Mar 31, 2011 at 05:06:42PM -0400, Calvin Walton wrote: On Wed, 2011-03-30 at 17:19 -0400, Josef Bacik wrote: Hello, Just found a big bug in the free space caching stuff that will result in early ENOSPC. I'm working on fixing this bug, but it won't be until tomorrow that I'll have it completely working, so for now make sure to mount -o clear_cache so that it just clears the cache and doesn't use it. Yeah it affects any kernel that has the free space cache feature, which I think started in .37. Course you have to have specifically enabled it, so it's not a huge problem. I've submitted a patch, but since it's currently an optional feature I don't think it needs to go to stable. Thanks, If you don't think the full fix is appropriate for the stable kernel, what about sending a simple patch to stable that just disables the free space caching support? That should be enough to stop any adventurous users (of the kind who don't read mailing lists) from trying the free space caching support, and possibly hitting this bug. -- Calvin Walton calvin.wal...@kepstin.ca -- 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: Do not use free space caching!
Excerpts from Calvin Walton's message of 2011-04-01 13:56:51 -0400: On Thu, 2011-03-31 at 18:59 -0400, Josef Bacik wrote: On Thu, Mar 31, 2011 at 05:06:42PM -0400, Calvin Walton wrote: On Wed, 2011-03-30 at 17:19 -0400, Josef Bacik wrote: Hello, Just found a big bug in the free space caching stuff that will result in early ENOSPC. I'm working on fixing this bug, but it won't be until tomorrow that I'll have it completely working, so for now make sure to mount -o clear_cache so that it just clears the cache and doesn't use it. Yeah it affects any kernel that has the free space cache feature, which I think started in .37. Course you have to have specifically enabled it, so it's not a huge problem. I've submitted a patch, but since it's currently an optional feature I don't think it needs to go to stable. Thanks, If you don't think the full fix is appropriate for the stable kernel, what about sending a simple patch to stable that just disables the free space caching support? That should be enough to stop any adventurous users (of the kind who don't read mailing lists) from trying the free space caching support, and possibly hitting this bug. We'll have a known stable patch for this shortly, I'd rather do that and send it back to the stable kernels. -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 balancing start - and stop?
On Fri, 2011-04-01 at 14:12 +0200, Helmut Hullen wrote: Hallo, Struan, Du meintest am 01.04.11: 1) Is the balancing operation expected to take many hours (or days?) on a filesystem such as this? Or are there known issues with the algorithm that are yet to be addressed? May be. Balancing about 15 GByte needed about 2 hours (or less), balancing about 2 TByte needed about 20 hours. [...] I've got a balance running since Monday on a 9TB volume (3.5 of which are used, 3.2 allegedly free), showing no sign of finishing soon. Should I be worried? Using /proc/sys/vm/block_dump, I can see it's seeking all over the place, which is probably why throughput is not high. I can also see it writing several times to the same sectors. # df -h /backup FilesystemSize Used Avail Use% Mounted on /dev/sda4 8.2T 3.5T 3.2T 53% /backup # btrfs fi sh Label: none uuid: ... Total devices 3 FS bytes used 3.43TB devid4 size 2.73TB used 1.16TB path /dev/sdc devid3 size 2.73TB used 1.16TB path /dev/sdb devid2 size 2.70TB used 1.14TB path /dev/sda4 Btrfs Btrfs v0.19 # ps -eolstart,args | grep balance Mon Mar 28 11:18:18 2011 sudo btrfs fi balance /backup Mon Mar 28 11:18:18 2011 btrfs fi balance /backup # date Fri Apr 1 19:28:40 BST 2011 # btrfs fi df /backup Data, RAID0: total=3.41TB, used=3.41TB System, RAID1: total=16.00MB, used=232.00KB Metadata, RAID1: total=27.75GB, used=20.47GB # iostat -md Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn sda 14.49 2.37 2.39 903123 913112 sdc 501.23 2.68 5.0610224561928462 sdb 477.28 2.58 5.06 9828531928482 It's already written more than the used space. Cheers, Stephane -- 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
On masking access to snapshots thru single path
Hello all, I've been trying to use btrfs with a very specific purpose during my MSc thesis, and now I would very much appreciate any comments you may have on a given issue. Currently I'm trying to mask accesses to different snapshots by different processes, while still using the same FS entry point. In a nutshell, a process trying to access /btrfs.mnt/S, instead of actually operating on 'S', will operate on /btrfs.mnt/Sx, with 'x' being the process' pid. I've already accomplished this, simply by implementing a btrfs-specific 'd_hash' on 'btrfs_dentry_operations', which will basically change the path accordingly to the implementation requirements and generate a new hash, thus avoiding dcache conflicts. However, given my yet-recent experience with btrfs, I can only wonder if any of you find any problems with such approach that I might have missed. I would honestly appreciate any input. Cheers, Joao --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu PGP.sig Description: This is a digitally signed message part
Re: btrfs balancing start - and stop?
Hallo, Stephane, Du meintest am 01.04.11: balancing about 2 TByte needed about 20 hours. [...] I've got a balance running since Monday on a 9TB volume (3.5 of which are used, 3.2 allegedly free), showing no sign of finishing soon. Should I be worried? Using /proc/sys/vm/block_dump, I can see it's seeking all over the place, which is probably why throughput is not high. I can also see it writing several times to the same sectors. Hugo has explained the limits of regarding dmesg | grep relocating or (more simple) the last lines of dmesg and looking for the relocating lines. But: what do these lines tell now? What is the (pessimistic) estimation when you extrapolate the data? (please excuse my gerlish) Viele Gruesse! Helmut -- 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
another messed-up btrfs
Hi, I have put a linux system on an external SSD recently, using btrfs for both root (/) and /home. After a couple of hibernation cycles the system got stuck and I had to reboot it ignoring the memory image on disk. Unfortunately, even a normal reboot did not work anymore. The kernel complains about not being able to mount the root filesystem. I connected the disk to another system, where the two partitions were not mountable either. btrfsck gave: btrfsck /dev/sdc2#this was root btrfsck: disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed. Aborted Taking advice from some earlier emails I have found on this list, I downloaded the recent btrfsck code using git, compiled it, and did: btrfsck -s 1 /dev/sdc2 btrfsck: disk-io.c:739: open_ctree_fd: Assertion `!(!tree_root-node)' failed. using SB copy 1, bytenr 67108864 Aborted btrfsck -s 2 /dev/sdc2 No valid Btrfs found on /dev/sdc2 using SB copy 2, bytenr 274877906944 The same commands for the other partition on the disk gives different messages, but still an unusable file system: btrfsck /dev/sdc4 parent transid verify failed on 59128545280 wanted 7937 found 7934 parent transid verify failed on 59128545280 wanted 7937 found 7934 parent transid verify failed on 59128545280 wanted 7937 found 7934 btrfsck: disk-io.c:739: open_ctree_fd: Assertion `!(!tree_root-node)' failed. btrfsck -s 1 /dev/sdc4 parent transid verify failed on 59128545280 wanted 7937 found 7934 parent transid verify failed on 59128545280 wanted 7937 found 7934 parent transid verify failed on 59128545280 wanted 7937 found 7934 btrfsck: disk-io.c:739: open_ctree_fd: Assertion `!(!tree_root-node)' failed. using SB copy 1, bytenr 67108864 btrfsck -s 2 /dev/sdc4 No valid Btrfs found on /dev/sdc4 using SB copy 2, bytenr 274877906944 The usual questions: Is there anything I could do to help analyze and fix the problem? Is there hope to restore the data any time soon, or should I better use the backup I have (and possibly move to an ext4 file system)? Thx Martin -- 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: another messed-up btrfs
Martin Fahr wrote: btrfsck: disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed. My fs is also broken this way, though for me it happened after resizing the fs and then partition. I still need to go back to the list thread and do some work on my image. The usual questions: Is there anything I could do to help analyze and fix the problem? Is there hope to restore the data any time soon, or should I better use the backup I have (and possibly move to an ext4 file system)? It seems the root node is a bit of a sore point with btrfs. :\ //Peter -- 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: another messed-up btrfs
Hi. Still waiting for this http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg08370.html Sincerely, Viacheslav Dobromyslov On Fri, Apr 1, 2011 at 8:01 PM, Peter Stuge pe...@stuge.se wrote: Martin Fahr wrote: btrfsck: disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed. My fs is also broken this way, though for me it happened after resizing the fs and then partition. I still need to go back to the list thread and do some work on my image. The usual questions: Is there anything I could do to help analyze and fix the problem? Is there hope to restore the data any time soon, or should I better use the backup I have (and possibly move to an ext4 file system)? It seems the root node is a bit of a sore point with btrfs. :\ //Peter -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Trace: use unsigned long long in trace print frames
On 04/01/2011 09:49 PM, Steven Rostedt wrote: On Fri, 2011-04-01 at 14:42 +0800, liubo wrote: While adding tracepoint for btrfs, I got a problem: btrfs uses some macros with ULL type, but tracepoint's macros, __print_[flags,symbols](), only have unsigned long, so on 32bit box there will be 64-32 truncate WARNINGs when compiling. Here I'm inclined to make the replacement to clear those WARNINGs. Hmm, I don't like this. unsigned long is a natural word for architectures, I don't want to have 32 bit suffer because one user is doing something with ULL. A better solution is to add a trace_print_flags_u64 or something, that can be used for cases that u64 is needed. For archs were sizeof(long) == sizeof(u64) we can have the two macros/structs be the same. All right, a u64 specific one is also in my mind. :) thanks, liubo -- Steve -- 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 -- 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 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Fri, Apr 1, 2011 at 8:40 PM, Chris Mason chris.ma...@oracle.com wrote: Excerpts from Christoph Hellwig's message of 2011-04-01 09:34:05 -0400: I don't think it's a good idea to introduce any user visible operations over subvolume boundaries. Currently we don't have any operations over mount boundaries, which is pretty fumdamental to the unix filesystem semantics. If you want to change this please come up with a clear description of the semantics and post it to linux-fsdevel for discussion. That of course requires a clear description of the btrfs subvolumes, which is still completely missing. The subvolume is just a directory tree that can be snapshotted, and has it's own private inode number space. reflink across subvolumes is no different from copying a file from one subvolume to another at the VFS level. The src and destination are different files and different inodes, they just happen to share data extents. ... and currently copying file from one subvolume to another requires copying the data as well. It'd be great if you could only copy the metadata. A good possible use that comes to mind is to quickly merge several subvolumes into a new one. -- 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
