[PATCH -progs] Fix unused-but-set errors in gcc-4.6
gcc-4.6 (as shipped in Fedora) turns on -Wunused-but-set-variable by
default, which breaks the build when combined with -Wall, e.g.:
debug-tree.c: In function ‘print_extent_leaf’:
debug-tree.c:45:13: error: variable ‘last_len’ set but not used
[-Werror=unused-but-set-variable]
debug-tree.c:44:13: error: variable ‘last’ set but not used
[-Werror=unused-but-set-variable]
debug-tree.c:41:21: error: variable ‘item’ set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
This patch fixes the errors by removing the unused variables.
Signed-off-by: Chris Ball c...@laptop.org
---
This is a pretty big patch -- I'm happy to split it out per-file if
you'd prefer to review it that way. It's against the next branch.
It removes some #if 0 blocks completely; seemed easier to let that
code live on in Git history than to add #if 0 blocks around the
declarations of all the variables only used inside those blocks.
btrfs-map-logical.c |2 --
btrfsck.c | 15 ++-
ctree.c | 16
debug-tree.c| 43 +--
dir-item.c |2 +-
disk-io.c |4
extent-cache.c |6 ++
extent-tree.c | 30 --
extent_io.c |4
mkfs.c |2 --
print-tree.c|3 ---
utils.c |3 +--
volumes.c |4
13 files changed, 7 insertions(+), 127 deletions(-)
diff --git a/btrfs-map-logical.c b/btrfs-map-logical.c
index a109c6a..8a12074 100644
--- a/btrfs-map-logical.c
+++ b/btrfs-map-logical.c
@@ -41,7 +41,6 @@ struct extent_buffer *debug_read_block(struct btrfs_root
*root, u64 bytenr,
u32 blocksize, int copy)
{
int ret;
- int dev_nr;
struct extent_buffer *eb;
u64 length;
struct btrfs_multi_bio *multi = NULL;
@@ -53,7 +52,6 @@ struct extent_buffer *debug_read_block(struct btrfs_root
*root, u64 bytenr,
if (!eb)
return NULL;
- dev_nr = 0;
length = blocksize;
while (1) {
ret = btrfs_map_block(root-fs_info-mapping_tree, READ,
diff --git a/btrfsck.c b/btrfsck.c
index 63e44d1..e3cd435 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -1037,7 +1037,7 @@ static int process_one_leaf(struct btrfs_root *root,
struct extent_buffer *eb,
break;
};
}
- return 0;
+ return ret;
}
static void reada_walk_down(struct btrfs_root *root,
@@ -1917,7 +1917,6 @@ static int check_owner_ref(struct btrfs_root *root,
struct btrfs_root *ref_root;
struct btrfs_key key;
struct btrfs_path path;
- int ret;
int level;
int found = 0;
@@ -1950,7 +1949,7 @@ static int check_owner_ref(struct btrfs_root *root,
btrfs_init_path(path);
path.lowest_level = level + 1;
- ret = btrfs_search_slot(NULL, ref_root, key, path, 0, 0);
+ btrfs_search_slot(NULL, ref_root, key, path, 0, 0);
if (buf-start == btrfs_node_blockptr(path.nodes[level + 1],
path.slots[level + 1]))
@@ -2539,16 +2538,6 @@ static int run_next_block(struct btrfs_root *root,
continue;
}
if (key.type == BTRFS_BLOCK_GROUP_ITEM_KEY) {
- struct btrfs_block_group_item *bi;
- bi = btrfs_item_ptr(buf, i,
- struct btrfs_block_group_item);
-#if 0
- fprintf(stderr,block group %Lu %Lu used %Lu ,
- btrfs_disk_key_objectid(disk_key),
- btrfs_disk_key_offset(disk_key),
- btrfs_block_group_used(bi));
- fprintf(stderr, flags %x\n, bi-flags);
-#endif
continue;
}
if (key.type == BTRFS_EXTENT_REF_V0_KEY) {
diff --git a/ctree.c b/ctree.c
index f70e10c..12f1a55 100644
--- a/ctree.c
+++ b/ctree.c
@@ -262,7 +262,6 @@ int __btrfs_cow_block(struct btrfs_trans_handle *trans,
struct extent_buffer **cow_ret,
u64 search_start, u64 empty_size)
{
- u64 generation;
struct extent_buffer *cow;
struct btrfs_disk_key disk_key;
int level;
@@ -272,7 +271,6 @@ int __btrfs_cow_block(struct btrfs_trans_handle *trans,
WARN_ON(root-ref_cows trans-transid != root-last_trans);
level = btrfs_header_level(buf);
- generation = btrfs_header_generation(buf);
if (level == 0)
btrfs_item_key(buf, disk_key, 0);
@@ -795,7 +793,6 @@ static int balance_level(struct btrfs_trans_handle *trans,
int wret
Re: kernel BUG
Hi,
Hi! I got a kernel BUG at
fs/btrfs/disk-io.c:2311
when testing the 2.6.37-rc5 kernel today.
It's good to mention which line this is, since the line numbers are
always changing. This is:
if (total_errors max_errors) {
printk(KERN_ERR btrfs: %d errors while writing supers\n,
total_errors);
BUG();
}
in write_all_supers(). Does dmesg say anything about the nature of
the errors above the BUG() line?
- Chris.
--
Chris Ball c...@laptop.org
One Laptop Per Child
--
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: kernel BUG
Hi Michael, in write_all_supers(). Does dmesg say anything about the nature of the errors above the BUG() line? The message was output to the console of the crashed system - so I'm sorry I cannot supply further informations. Ah, okay. You could consider installing kgdb/kdb -- it will let you drop to the kdb shell after the crash and run dmesg through a pager. Just: CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_TESTS=y # CONFIG_KGDB_TESTS_ON_BOOT is not set CONFIG_KGDB_LOW_LEVEL_TRAP=y CONFIG_KGDB_KDB=y CONFIG_KDB_KEYBOARD=y and then boot with kgdboc=kms,kbd added. But exactly the same crash happened again some minutes ago. (I'm now back to my old kernel.) Not sure I understand. Do you mean that the same crash happens on your older kernel now, or that you've reverted to your older kernel because you had another -rc5 crash? If the crash happens on -rc5 but not the older kernel (what revision is the older kernel?), that's extremely interesting. Josef/Chris, any knowledge about hitting this BUG() on -rc5? - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: kernel BUG
Hi, Currently I'm running with -rc7. If the system still runs tomorrow morning I will do another test with -rc5 - this time on the USB 3.0 port. This should show whether this is a hardware or software problem. Thanks, sounds good. Yes, the location of the BUG() does suggest a hardware problem, assuming it's coded correctly. dmesg would tell us for sure, because the I/O error would be reported above the BUG() output. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: tiny btrfs bug.....
Hi, In stead, df reports the size of the partition to be about 60GB. For each GB written to the partition, 2GB gets used. https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: ls flush-btrfs-1 sit at 100% sys
Hi, Is doesn't return, I check top and both ls and flush-btrfs-1 are sitting at ~50% sys usage each. Does anything new appear in dmesg when the hang happens? Can you run alt-sysrq-t (show tasks) and send us the output for the ls process? - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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
Update to Project_ideas wiki page
different raid levels. Some of these are quite easy -- e.g. for RAID0 to RAID1, we just halve the available bytes on the fs, then queue a rebalance. == DISCARD utilities == For SSDs with discard support, we could use a scrubber that goes through the fs and performs discard on anything that is unused. You could first use the balance operation to compact data to the front of the drive, then discard the rest. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Blog: BTRFS is effectively stable
Hi, A friend of mine who builds storage systems designed for HPC use has been keeping an eye on btrfs and has just done some testing of it with 2.6.36 and seems to like what he sees in terms of stability. http://scalability.org/?p=2711 This is nice to see, but we should be clearer about what stability means. This was just fio testing; it doesn't say anything about resilience to crashes, power offs, or the presence of corruption. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: converting one-disk btrfs into RAID-1?
Hi, Is it possible to turn a 1-disk (partition) btrfs filesystem into RAID-1? Not yet, but I'm pretty sure it's on the roadmap. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Slow link/Capacity changed + Kernel OOPS... possible hardware issues, ideas?
Hi, can anyone point me in the right direction? it looks like maybe the SSD is failing to me (all the slow link and capacity changed to 0 stuff), but i really don't know. i knew there was a reason they were selling these things cheap on Newegg!!! Yes, the read errors are coming all the way up from the hardware; I don't think this is a btrfs problem. There's not much btrfs could do to help, except (over time) grow to handle I/O errors without BUG()ing out. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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 user survey?
Hi Francis, Well, all in all, you get the idea, and I'm probably not the guy to craft questions for such a survey. But having input from as large a panel of users as possible would be a nice thing to have. Your questions are fine -- I might add: * Rank the following future features in importance, 4 == most important [ ] working fsck [ ] GUIs for userspace actions e.g. snapshots [ ] data deduplication [ ] hot data relocation Please use something like Google Spreadsheets (which has a forms option) if you're going to run such a survey, rather than having everyone reply on-list -- we shouldn't bother this list with any results other than the final summary. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Updating the wiki pages adding btrfs command
Hi, adding a --wait or --sync switch to the delete command is certainly possible, you'd want to add it to the last in a series of deletes. I think this (--sync) is a much better idea than the alternatives so far. Thanks, -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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: Updating the wiki pages adding btrfs command
Hi, Or make --sync the default behavior. This is probably what most people are expecting anyway (similar to how standard filesystem commands like rm work). Add an --aysnc option for those that only care about knowing when the subvolume is taken out of the tree. Yeah. We've also talked about making snapshot _creation_ perform an FS sync first by default, since otherwise you get a snapshot with stale files, or without files that existed (not yet on disk) at creation-time. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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: Updating the wiki pages adding btrfs command
Hi Sage, Actually, that was fixed in 2.6.34 (0bdb1db2). Creating a snapshot syncs all dirty data and metadata to disk, so you get a fully consistent point in time snapshot. No 'sync' is necessary (and doing a 'sync' yourself would be racy any). Oh, thanks! Am happy to see that. Why not just do: # btrfs subvolume delete /path/to/subvolume1 # btrfs subvolume delete /path/to/subvolume2 # sync Or even better, btrfs filesystem sync path. I'm assuming that the caller wants to wait until the subvol delete has happened, but is unwilling to wait until all other writes to the FS have finished, and is even more unwilling to wait for all writes on the rest of the system to finish. I don't know whether that's actually a reasonable/plausible use case, though. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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] Add the btrfs filesystem label command
Hi, How can one char equal two chars? input[i] == '\\' If the first char is the C escape sequence for string literals. :) - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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: 2.6.36-rc1 btrfs still unstable
Hi, the other big question is: Is btrfs with 2.6.36 really rockstable and ready to use in productive environments? No, certainly not until there's a working fsck tool -- at the moment it's rather easy to kill a btrfs by just losing power. I just added a paragraph to the main page of the wiki about this, since we've had a few people on IRC express surprise that their filesystem aren't fixable after power loss. Feel free to reword: Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power. This will be fixed when the fsck tool is ready. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: 2.6.36-rc1 btrfs still unstable
Hi, I don't think the signboards are big enough. Sure; that's why I tried to make one of them larger. Most people assume that there is some way of fixing a broken file system, and finding out the btrfs does not have one usually is quite surprising and just a little too late. Agreed, that's my experience from the IRC channel. I was under the impression that with atomic writes it's impossible to mess up a file system? Yes, we're not seeing data corruption, we're correctly reporting that the transid of the data block doesn't match the transid in the parent node's pointer, which means that some writes went missing. Then we're hitting a BUG() as a result, which hangs. I don't know what the right way of dealing with this is going to be, but answers like pretend the lost writes never happened and sync the transids, or do something other than BUG() on verify_parent_transid() failure sound plausible. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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 subvolumes be specified as compressed?
Hi, So, is there such a method: in a specified directory, the compression feature is enabled, and the file in this directory will be compressed automatically, while the others don't enable compression. I don't think so, but it wouldn't be difficult -- you'd just set a per-inode flag on whether to compress, and if it's set on a directory then it's inherited by the files in that directory. I think the hold up has been that we've waited for a *generic* cross-filesystem flag to appear, and it hasn't (or it has and I didn't notice). Does anyone have suggestions on how to break the deadlock there? - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: raid1 not reporting the right size
Hi, I'm trying to create a raid1 (mirrored) raid using two 1 Tb disks. The result is something twice as large as it should be fore mirrored raid. https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: default subvolume abilities/restrictions
Hi, moving along to a question... can the default subvolume be swapped/removed/renamed/popped/shifted? I think btrfs subvolume list; btrfs subvolume set-default id path does what you need. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Cross-subvolume link causes kernel BUG
Hi, ln segfaults, and the bug above is found in dmesg. Subsequent accesses to the subvolume result in a D state hung process. Full dmesg follows. I first observed this on a Gentoo system and reproduced it on Ubuntu. Both were running unpatched 2.6.32.9 kernels. I think this is fixed in 2.6.33, as a result of the patch below. Let us know if you see a segfault on 2.6.33, or after applying this patch to your current kernel. Thanks, - Chris. commit 4a8be425a8fb8fbb5d881eb55fa6634c3463b9c9 Author: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com Date: Thu Nov 12 07:14:26 2009 + Btrfs: deny sys_link across subvolumes. I rebased Christian Parpart's patch to deny hard link across subvolumes. Original patch modifies also btrfs_rename, but I excluded it because we can move across subvolumes now and it make no problem. - Hard link across subvolumes should not allowed in Btrfs. btrfs_link checks root of 'to' directory is same as root of 'from' file. If not same, btrfs_link returns -EPERM. Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com Signed-off-by: Chris Mason chris.ma...@oracle.com diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 168e8c0..da76cad 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4462,6 +4462,10 @@ static int btrfs_link(struct dentry *old_dentry, struct inode *dir, if (inode-i_nlink == 0) return -ENOENT; + /* do not allow sys_link's with other subvols of the same device */ + if (root-objectid != BTRFS_I(inode)-root-objectid) + return -EPERM; + /* * 1 item for inode ref * 2 items for dir items -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Raid1 with 3 drives
Hi, DF with btrfs is a loaded question. In the RAID1 case you are going to show 3TB of free space, but everytime you use some space you are going to show 3 times the amount used (I think thats right). There are some patches forthcoming to make the reporting for RAID stuff make more sense, but for the time being just ignore df. Added to: http://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F since we're often seeing this question on the list and IRC. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: zero-length files in snapshots
Hi, Is there a race in there? It seems like if a process starts modifying a file between the sync and the snapshot, data could still be lost. Is there something else going on here that I'm missing that would prevent this race? AIUI, you're correct that a writer process concurrent to a snapshot leads to a race with data that doesn't make it in to the snapshot, but I think you're wrong in thinking that there's much we could do about it -- either you miss writes between sync and snapshot, as we do now, or we do sync-and-snapshot atomically, and the concurrent writes are missed because we decided to block further writes from that process before we took the snapshot. The only real answer is to quiesce the writer process before you begin. Does that make sense? - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: zero-length files in snapshots
Hi, I often get zero-length files in btrfs snapshots (when the original files were not zero-length). The shell script below reproduces this problem on two Ubuntu machines, with Ubuntu kernels 2.6.31-17.54 and 2.6.32-12.17. Is there some mistaken assumption I'm making here in terms of how btrfsctl works? [..] echo x1 /mnt/x/d/foo.txt || exit 2 btrfsctl -s /mnt/x/snap /mnt/x/d You're just missing a sync/fsync() between these two lines. We argued on IRC a while ago about whether this is a sensible default; cmason wants the no-sync version of snapshot creation to be available, but was amenable to the idea of changing the default to be sync before snapshot, since it was pointed out that no-one other than him had understood we were supposed to be running sync first. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Using snapshots as quick restore point
Hi, * create snapshot * mount it somewhere (read-write) * operate on the snapshot, change some files etc... * revert changes made to the snapshot to its original state Make two snapshots instead of one, and only modify one of them? Because of CoW, new snapshots have very low overhead. with or without unmounting it. You would have to unmount it if it had any open files. If not, is there any filesystem that can do that ? I don't know of any filesystem that lets you discard changes to a snapshot, but I've just described a method for doing so where you always make a read-only -pristine version of that snapshot and have tools that base your read-write snapshots on that. I don't think it would be possible for any filesystem to handle changing snapshot on a mounted filesystem with files open, so it makes sense that it's a remount operation. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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] Reclaim space.
btrfs_fs_info *fs_info);
+int btrfs_make_readonly(struct btrfs_fs_info *fs_info);
#endif
diff --git a/extent-tree.c b/extent-tree.c
index e1d7ffd..49bffe7 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -3135,6 +3135,68 @@ error:
return ret;
}
+void btrfs_update_block_groups_readonly(struct btrfs_fs_info *info)
+{
+ struct btrfs_block_group_cache *cache;
+ struct extent_io_tree *block_group_cache;
+ int ret;
+ u64 ptr;
+ u64 start;
+ u64 end;
+
+ block_group_cache = info-block_group_cache;
+ start = BTRFS_SUPER_INFO_OFFSET + BTRFS_SUPER_INFO_SIZE;
+ while (1) {
+ ret = find_first_extent_bit(block_group_cache,
+ start, start, end,
+ BLOCK_GROUP_DATA |
+ BLOCK_GROUP_METADATA |
+ BLOCK_GROUP_SYSTEM);
+ if (ret)
+ break;
+ ret = get_state_private(block_group_cache, start, ptr);
+ if (ret)
+ break;
+
+ cache = (struct btrfs_block_group_cache *)(unsigned long)ptr;
+ cache-ro = btrfs_chunk_readonly(info-extent_root,
+cache-key.objectid);
+ start = end + 1;
+ }
+}
+
+u64 btrfs_total_used(struct btrfs_root *root)
+{
+ struct btrfs_block_group_cache *cache;
+ struct extent_io_tree *block_group_cache;
+ int ret;
+ u64 ptr;
+ u64 start;
+ u64 end;
+ u64 total = 0;
+
+ block_group_cache = root-fs_info-block_group_cache;
+ start = BTRFS_SUPER_INFO_OFFSET + BTRFS_SUPER_INFO_SIZE;
+ while (1) {
+ ret = find_first_extent_bit(block_group_cache,
+ start, start, end,
+ BLOCK_GROUP_DATA |
+ BLOCK_GROUP_METADATA |
+ BLOCK_GROUP_SYSTEM);
+ if (ret)
+ break;
+ ret = get_state_private(block_group_cache, start, ptr);
+ if (ret)
+ break;
+
+ cache = (struct btrfs_block_group_cache *)(unsigned long)ptr;
+ total += btrfs_block_group_used(cache-item);
+ start = end + 1;
+ }
+
+ return total;
+}
+
int btrfs_make_block_group(struct btrfs_trans_handle *trans,
struct btrfs_root *root, u64 bytes_used,
u64 type, u64 chunk_objectid, u64 chunk_offset,
--
1.5.4.3
--
Chris Ball c...@laptop.org
One Laptop Per Child
--
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] Reclaim space.
Hi, btrfsctl -D ext2_saved/ ioctl:: Invalid argument It's merged (during 2.6.32) -- I think you just have the wrong syntax. See http://btrfs.wiki.kernel.org/index.php/Btrfsctl. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Mount via /etc/fstab constant failure
Hi Reg, Hi, I have a btrfs 'pool' of x2 Samsung 500GB HDD's in non-raid format. It works fine for the most part except for mounting on bootup. Every bootup I have to change the block-device to and fro /dev/sda /dev/sdb. This happens on linux-2.6.32.2 and 2.6.33-rc2. Are you running btrfsctl -a in an initrd? It's necessary to do that before the mount call on a multi-disk volume. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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
RFC: Btrfs snapshots feature proposal for Fedora 13
Hi, I've written up a draft of an Fedora 13 feature proposal for filesystem rollback using Btrfs snapshots that are automatically created by yum: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs It'd be great to get feedback on whether this is a good idea, and how the UI interaction should work. We're also discussing it in this fedora-devel thread: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/123695 Some comments I've got already received, from the thread: * People want the UI to allow independent active snapshots per filesystem (i.e. btrfs /home is the live filesystem, and btrfs / is an older snapshot). * Several people think that the ZFS Time Slider patches to nautilus¹ look good, and want that for btrfs. Sounds plausible, but I'm more interested in first working on ways to let developers feel comfortable upgrading to the development version of Fedora each day with the possibility of reverting. * Instead of inventing a new system-config-blah, this should probably be part of Palimpsest². * Perhaps we should encourage people using the Fedora installer with btrfs to create a rootfs separate to their /home, so that they can rollback rootfs snapshots without affecting their homedir. Thanks! - Chris. ¹: http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs http://blogs.sun.com/erwann/entry/time_slider_screencast http://blogs.sun.com/erwann/entry/new_time_slider_features_in ²: http://library.gnome.org/users/palimpsest/stable/intro.html.en -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Kernel oops with 2.6.31 in btrfs_set_acl
Hi, Hi, I got an oops this morning with btrfs on the Ubuntu 2.6.31 kernel. I mounted with compress and thread_pool=4. This is on a 64 bit quad AMD machine. [614439.132228] [a0f3c157] ? btrfs_set_acl+0x87/0x230 Could you tell us what line of the source code that is? This should work, after gdb btrfs.ko: (gdb) list *btrfs_set_acl+0x87 - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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/2] Btrfs: Fix setting umask when POSIX ACLs are not enabled
We currently set sb-s_flags |= MS_POSIXACL unconditionally, which is incorrect -- it tells the VFS that it shouldn't set umask because we will, yet we don't set it ourselves if we aren't using POSIX ACLs, so the umask ends up ignored. Signed-off-by: Chris Ball c...@laptop.org --- fs/btrfs/super.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 6d6d06c..48ed1c0 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -344,7 +344,9 @@ static int btrfs_fill_super(struct super_block *sb, sb-s_export_op = btrfs_export_ops; sb-s_xattr = btrfs_xattr_handlers; sb-s_time_gran = 1; +#ifdef CONFIG_BTRFS_POSIX_ACL sb-s_flags |= MS_POSIXACL; +#endif tree_root = open_ctree(sb, fs_devices, (char *)data); -- 1.6.4 -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Why does stat() return invalid st_dev field for btrfs ??
Hi, Mmm.. btrfs appears to configure itself as a pseudo filesystem, which is why it returns fake device numbers via stat(), similar to procfs or sysfs. Probably because a single btrfs filesystem can be composed of multiple devices; one major/minor would not be sufficient. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- 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: Add an alarm for long-running transactions.
If we're waiting for a transaction to end, and it started more than five
minutes ago, emit a warning.
Signed-off-by: Chris Ball c...@laptop.org
---
fs/btrfs/transaction.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index f94c2ad..9fa477c 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -80,6 +80,7 @@ static noinline int join_transaction(struct btrfs_root *root)
root-fs_info-running_transaction = cur_trans;
spin_unlock(root-fs_info-new_trans_lock);
} else {
+ WARN_ON_ONCE(get_seconds() - cur_trans-start_time 300);
cur_trans-num_writers++;
cur_trans-num_joined++;
}
--
1.6.1.3
--
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: [review] Btrfs: Allow shrinking close to used space
Hi,
Here's a new patch that incorporates these comments. We now update
device-fs_devices-total_rw_bytes before the shrink, as Josef suggests,
and create a new field in btrfs_device to store an on-disk size that is
only updated on a successful shrink operation, as requested by Yan.
(Thanks, Yan and Josef, for the patient explanations.)
==
From: Chris Ball c...@laptop.org
Btrfs: When shrinking, only update disk size on success
Previously, we updated a device's size prior to attempting a shrink
operation. This patch moves the device resizing logic to only happen if
the shrink completes successfully. In the process, it introduces a new
field to btrfs_device -- disk_total_bytes -- to track the on-disk size.
Signed-off-by: Chris Ball c...@laptop.org
---
fs/btrfs/volumes.c | 35 ---
fs/btrfs/volumes.h |3 +++
2 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1316139..303b7d6 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1433,7 +1433,7 @@ static noinline int btrfs_update_device(struct
btrfs_trans_handle *trans,
btrfs_set_device_io_align(leaf, dev_item, device-io_align);
btrfs_set_device_io_width(leaf, dev_item, device-io_width);
btrfs_set_device_sector_size(leaf, dev_item, device-sector_size);
- btrfs_set_device_total_bytes(leaf, dev_item, device-total_bytes);
+ btrfs_set_device_total_bytes(leaf, dev_item, device-disk_total_bytes);
btrfs_set_device_bytes_used(leaf, dev_item, device-bytes_used);
btrfs_mark_buffer_dirty(leaf);
@@ -1828,14 +1828,6 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
device-total_bytes = new_size;
if (device-writeable)
device-fs_devices-total_rw_bytes -= diff;
- ret = btrfs_update_device(trans, device);
- if (ret) {
- unlock_chunks(root);
- btrfs_end_transaction(trans, root);
- goto done;
- }
- WARN_ON(diff old_total);
- btrfs_set_super_total_bytes(super_copy, old_total - diff);
unlock_chunks(root);
btrfs_end_transaction(trans, root);
@@ -1867,7 +1859,7 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
length = btrfs_dev_extent_length(l, dev_extent);
if (key.offset + length = new_size)
- goto done;
+ break;
chunk_tree = btrfs_dev_extent_chunk_tree(l, dev_extent);
chunk_objectid = btrfs_dev_extent_chunk_objectid(l, dev_extent);
@@ -1880,6 +1872,26 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
goto done;
}
+ /* Shrinking succeeded, else we would be at done. */
+ trans = btrfs_start_transaction(root, 1);
+ if (!trans) {
+ ret = -ENOMEM;
+ goto done;
+ }
+ lock_chunks(root);
+
+ device-disk_total_bytes = new_size;
+ /* Now btrfs_update_device() will change the on-disk size. */
+ ret = btrfs_update_device(trans, device);
+ if (ret) {
+ unlock_chunks(root);
+ btrfs_end_transaction(trans, root);
+ goto done;
+ }
+ WARN_ON(diff old_total);
+ btrfs_set_super_total_bytes(super_copy, old_total - diff);
+ unlock_chunks(root);
+ btrfs_end_transaction(trans, root);
done:
btrfs_free_path(path);
return ret;
@@ -2959,7 +2971,8 @@ static int fill_device_from_item(struct extent_buffer
*leaf,
unsigned long ptr;
device-devid = btrfs_device_id(leaf, dev_item);
- device-total_bytes = btrfs_device_total_bytes(leaf, dev_item);
+ device-disk_total_bytes = btrfs_device_total_bytes(leaf, dev_item);
+ device-total_bytes = device-disk_total_bytes;
device-bytes_used = btrfs_device_bytes_used(leaf, dev_item);
device-type = btrfs_device_type(leaf, dev_item);
device-io_align = btrfs_device_io_align(leaf, dev_item);
diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
index 86c44e9..bf1ba75 100644
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -52,6 +52,9 @@ struct btrfs_device {
/* size of the device */
u64 total_bytes;
+ /* size of the disk */
+ u64 disk_total_bytes;
+
/* bytes used */
u64 bytes_used;
--
1.6.1.3
- Chris.
--
Chris Ball c...@laptop.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
[review] Btrfs: Allow shrinking close to used space
Hi,
This patch (against experimental HEAD) attempts to make shrinking more
robust, by only updating device size if we've succeeded in creating
enough free space without any failures in btrfs_relocate_chunk().
Here's a log with my patch applied. The two things to note are that a
near-limit shrink now works, and that a failed shrink (in this case,
trying to shrink to less than the used space) no longer updates the
device size erroneously:
http://dev.laptop.org/~cjb/btrfs/shrink-log
Please review carefully -- I'm still new to btrfs. The short version of
the patch is:
* create a success path, as a break out of the while(1) relocating
(rather than going to the done label).
* move the device size updating code into that path
* leave path-reada = 2; behind in the entry path, since path is
used by the searching operation rather than the later resize.
Thanks!
Signed-off-by: Chris Ball c...@laptop.org
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1316139..e2fa072 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1815,30 +1815,8 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
if (!path)
return -ENOMEM;
- trans = btrfs_start_transaction(root, 1);
- if (!trans) {
- ret = -ENOMEM;
- goto done;
- }
-
path-reada = 2;
- lock_chunks(root);
-
- device-total_bytes = new_size;
- if (device-writeable)
- device-fs_devices-total_rw_bytes -= diff;
- ret = btrfs_update_device(trans, device);
- if (ret) {
- unlock_chunks(root);
- btrfs_end_transaction(trans, root);
- goto done;
- }
- WARN_ON(diff old_total);
- btrfs_set_super_total_bytes(super_copy, old_total - diff);
- unlock_chunks(root);
- btrfs_end_transaction(trans, root);
-
key.objectid = device-devid;
key.offset = (u64)-1;
key.type = BTRFS_DEV_EXTENT_KEY;
@@ -1867,7 +1845,7 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
length = btrfs_dev_extent_length(l, dev_extent);
if (key.offset + length = new_size)
- goto done;
+ break;
chunk_tree = btrfs_dev_extent_chunk_tree(l, dev_extent);
chunk_objectid = btrfs_dev_extent_chunk_objectid(l, dev_extent);
@@ -1880,6 +1858,31 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
goto done;
}
+ /*
+* We've succeeded in freeing up enough space and can now update
+* the device's size.
+*/
+ trans = btrfs_start_transaction(root, 1);
+ if (!trans) {
+ ret = -ENOMEM;
+ goto done;
+ }
+
+ lock_chunks(root);
+ device-total_bytes = new_size;
+ if (device-writeable)
+ device-fs_devices-total_rw_bytes -= diff;
+ ret = btrfs_update_device(trans, device);
+ if (ret) {
+ unlock_chunks(root);
+ btrfs_end_transaction(trans, root);
+ goto done;
+ }
+ WARN_ON(diff old_total);
+ btrfs_set_super_total_bytes(super_copy, old_total - diff);
+ unlock_chunks(root);
+ btrfs_end_transaction(trans, root);
+
done:
btrfs_free_path(path);
return ret;
--
Chris Ball c...@laptop.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
[PATCH] btrfs: Handle SGID bit when creating inodes
Before this patch, new files/dirs would ignore the SGID bit on their
parent directory and always be owned by the creating user's uid/gid.
Signed-off-by: Chris Ball c...@laptop.org
---
fs/btrfs/inode.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ebd7d6c..ce25bb3 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3470,7 +3470,14 @@ static struct inode *btrfs_new_inode(struct
btrfs_trans_handle *trans,
root-highest_inode = objectid;
inode-i_uid = current_fsuid();
- inode-i_gid = current_fsgid();
+
+ if (dir-i_mode S_ISGID) {
+ inode-i_gid = dir-i_gid;
+ if (S_ISDIR(mode))
+ mode |= S_ISGID;
+ } else
+ inode-i_gid = current_fsgid();
+
inode-i_mode = mode;
inode-i_ino = objectid;
inode_set_bytes(inode, 0);
--
1.6.1.2
--
Chris Ball c...@laptop.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
