Re: [patch 1/2] grub-0.97: btrfs support for a singe device configuration
Am Donnerstag 29 Oktober 2009 00:02:08 schrieb Edward Shishkin: Johannes Hirte wrote: [...] This compiles and works, but only with stage2. When using stage1_5, grub hangs on boot with GRUB loading stage1.5 and blinking cursor. Is the multidevice patch also necessary for single devices? Yes, please use both patches! I have split the stuff because the mailing list refuse attachments 100K. Thanks, Edward. With both patches applied it works now with stage1_5. Thank you. The patch for gentoo is available on http://bugs.gentoo.org/show_bug.cgi?id=283637, if somebody is interested. Johannes -- 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: reserve space specifically for the extent root
On Fri, Oct 30, 2009 at 4:35 AM, Josef Bacik jo...@redhat.com wrote:
If there are alot of snapshots we could conceivably end up using much more
metadata space than what the worst case calculation would come up with, so
instead of trying to figure out how many extents will be modified by changing
items, just calculate it per tree, and then reserve space specifically for the
extent root. This patch does a max(size of extent root tree, 20% of free
metadata space) reservation for the extent root, and then tracks how much
space is used per transaction for the extent root. Then if we get close to
this amount in our transaction we will force the commit of the transaction to
free up space. This will help us better deal with the massive space
requirements that will come when users have alot of snapshots. This was
tested with my normal enospc tests. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/ctree.h | 2 +
fs/btrfs/extent-tree.c | 115
+---
fs/btrfs/transaction.c | 19 +++-
fs/btrfs/transaction.h | 1 +
4 files changed, 119 insertions(+), 18 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index e5dd628..3e00df1 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2049,6 +2049,8 @@ void btrfs_delalloc_reserve_space(struct btrfs_root
*root, struct inode *inode,
u64 bytes);
void btrfs_delalloc_free_space(struct btrfs_root *root, struct inode *inode,
u64 bytes);
+int btrfs_check_reserved_extent_space(struct btrfs_trans_handle *trans,
+ struct btrfs_root *root);
/* ctree.c */
int btrfs_bin_search(struct extent_buffer *eb, struct btrfs_key *key,
int level, int *slot);
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index c56f916..7a1f1a4 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2768,6 +2768,12 @@ static u64 calculate_bytes_needed(struct btrfs_root
*root, int num_items)
u64 num_bytes;
int level;
+ /*
+ * The level is the number of node level's we could possibly cow. So
+ * since we track root item reservations seperately we don't need
that,
+ * and we don't need to count the leaf level, so the max number of
+ * levels that could have nodes is MAX_LEVEL - 2.
+ */
level = BTRFS_MAX_LEVEL - 2;
/*
* NOTE: these calculations are absolutely the worst possible case.
@@ -2776,17 +2782,11 @@ static u64 calculate_bytes_needed(struct btrfs_root
*root, int num_items)
*/
/*
- * for every item we insert we could insert both an extent item and a
- * extent ref item. Then for ever item we insert, we will need to cow
- * both the original leaf, plus the leaf to the left and right of it.
- *
- * Unless we are talking about the extent root, then we just want the
- * number of items * 2, since we just need the extent item plus its
ref.
+ * For each item we need we'll assume that we're going to add a leaf
for
+ * it, and then we may cow the leaves on either side to make room for
+ * the items we're inserting, so multiply by 3.
*/
- if (root == root-fs_info-extent_root)
- num_bytes = num_items * 2;
- else
- num_bytes = (num_items + (2 * num_items)) * 3;
+ num_bytes = num_items * 3;
/*
* num_bytes is total number of leaves we could need times the leaf
@@ -3031,6 +3031,64 @@ out:
}
/*
+ * This checks how many bytes we've allocated for the extent tree vs. how
much
+ * we reserved, and if we need to go ahead and force the transaction to
commit.
+ */
+int btrfs_check_reserved_extent_space(struct btrfs_trans_handle *trans,
+ struct btrfs_root *root)
+{
+ struct btrfs_fs_info *info = root-fs_info;
+ struct btrfs_space_info *meta_sinfo;
+ u64 used;
+ u64 alloc_target;
+
+ /* don't force a commit if this is an embedded transaction */
+ if (current-journal_info != trans)
+ return 0;
+
+ /* get the space info for where the metadata will live */
+ alloc_target = btrfs_get_alloc_profile(root, 0);
+ meta_sinfo = __find_space_info(info, alloc_target);
+
+ spin_lock(meta_sinfo-lock);
+
+ if (unlikely(!meta_sinfo-bytes_root)) {
+ u64 bytes;
+
+ /*
+ * somebody should have already reserved space before starting
+ * the transaction, so WARN_ON so we can fix that person.
+ */
+ WARN_ON(1);
+
+ used = meta_sinfo-bytes_used + meta_sinfo-bytes_reserved +
+ meta_sinfo-bytes_pinned + meta_sinfo-bytes_readonly
+
+
Re: [PATCH] Btrfs: reserve space specifically for the extent root
On Fri, Oct 30, 2009 at 09:48:55AM +0800, Yan, Zheng wrote:
On Fri, Oct 30, 2009 at 4:35 AM, Josef Bacik jo...@redhat.com wrote:
If there are alot of snapshots we could conceivably end up using much more
metadata space than what the worst case calculation would come up with, so
instead of trying to figure out how many extents will be modified by
changing
items, just calculate it per tree, and then reserve space specifically for
the
extent root. This patch does a max(size of extent root tree, 20% of free
metadata space) reservation for the extent root, and then tracks how much
space is used per transaction for the extent root. Then if we get close to
this amount in our transaction we will force the commit of the transaction
to
free up space. This will help us better deal with the massive space
requirements that will come when users have alot of snapshots. This was
tested with my normal enospc tests. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/ctree.h | 2 +
fs/btrfs/extent-tree.c | 115
+---
fs/btrfs/transaction.c | 19 +++-
fs/btrfs/transaction.h | 1 +
4 files changed, 119 insertions(+), 18 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index e5dd628..3e00df1 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2049,6 +2049,8 @@ void btrfs_delalloc_reserve_space(struct btrfs_root
*root, struct inode *inode,
u64 bytes);
void btrfs_delalloc_free_space(struct btrfs_root *root, struct inode
*inode,
u64 bytes);
+int btrfs_check_reserved_extent_space(struct btrfs_trans_handle *trans,
+ struct btrfs_root *root);
/* ctree.c */
int btrfs_bin_search(struct extent_buffer *eb, struct btrfs_key *key,
int level, int *slot);
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index c56f916..7a1f1a4 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2768,6 +2768,12 @@ static u64 calculate_bytes_needed(struct btrfs_root
*root, int num_items)
u64 num_bytes;
int level;
+ /*
+ * The level is the number of node level's we could possibly cow.
So
+ * since we track root item reservations seperately we don't need
that,
+ * and we don't need to count the leaf level, so the max number of
+ * levels that could have nodes is MAX_LEVEL - 2.
+ */
level = BTRFS_MAX_LEVEL - 2;
/*
* NOTE: these calculations are absolutely the worst possible case.
@@ -2776,17 +2782,11 @@ static u64 calculate_bytes_needed(struct btrfs_root
*root, int num_items)
*/
/*
- * for every item we insert we could insert both an extent item and
a
- * extent ref item. Then for ever item we insert, we will need to
cow
- * both the original leaf, plus the leaf to the left and right of
it.
- *
- * Unless we are talking about the extent root, then we just want
the
- * number of items * 2, since we just need the extent item plus its
ref.
+ * For each item we need we'll assume that we're going to add a
leaf for
+ * it, and then we may cow the leaves on either side to make room
for
+ * the items we're inserting, so multiply by 3.
*/
- if (root == root-fs_info-extent_root)
- num_bytes = num_items * 2;
- else
- num_bytes = (num_items + (2 * num_items)) * 3;
+ num_bytes = num_items * 3;
/*
* num_bytes is total number of leaves we could need times the leaf
@@ -3031,6 +3031,64 @@ out:
}
/*
+ * This checks how many bytes we've allocated for the extent tree vs. how
much
+ * we reserved, and if we need to go ahead and force the transaction to
commit.
+ */
+int btrfs_check_reserved_extent_space(struct btrfs_trans_handle *trans,
+ struct btrfs_root *root)
+{
+ struct btrfs_fs_info *info = root-fs_info;
+ struct btrfs_space_info *meta_sinfo;
+ u64 used;
+ u64 alloc_target;
+
+ /* don't force a commit if this is an embedded transaction */
+ if (current-journal_info != trans)
+ return 0;
+
+ /* get the space info for where the metadata will live */
+ alloc_target = btrfs_get_alloc_profile(root, 0);
+ meta_sinfo = __find_space_info(info, alloc_target);
+
+ spin_lock(meta_sinfo-lock);
+
+ if (unlikely(!meta_sinfo-bytes_root)) {
+ u64 bytes;
+
+ /*
+ * somebody should have already reserved space before
starting
+ * the transaction, so WARN_ON so we can fix that person.
+
Re: [PATCH] Prevent btrfsck to run on mounted filesystems
On Thu, Oct 29, 2009 at 09:52:15PM +0100, Andi Drebes wrote: As recently discussed on the list, btrfsck should only be run on unmounted filesystems. This patch adds a short check for the mount status at the beginning of btrfsck. If the FS is mounted, the program aborts showing an error message. Just open the nodes with O_EXCL and you'll get all the checking for free. Also make sure that for a pure, read-only checks instead of a repair to allow running on at least a read-only mounted filesystem. -- 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
Hard link across subvolumes
Hi, In Btrfs, a hard link across subvolumes should be prohibited, but not prohibited yet. (It may be convenient if possible, I think.) If we make a hard link like this, filesystem may abort or after umount/mount, contents of file may be swapped to contents of other file(with same i-node number in same tree as 'from' file). About this, I found Christian Parpart's patch posted last year, and this patch seems to work well. http://www.spinics.net/lists/linux-btrfs/msg00749.html But this patch is not merged yet. Some work(to check more, to change error code or to simply test) shuould be done for this? -- taruisi -- 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
