committing new snapshots
When you create a new snap or subvol, first a new ROOT_ITEM is created while everything commits, and then the referring directory entry is set up (with a correspond ROOT_BACKREF). First, if you say 'btrfsctl -s foo .' and then 'reboot -f -n' before the next regularly scheduled commit, the snap is created, but lost.. there's no reference. Second, the unreferenced ROOT_ITEM is never cleaned up. Are there any existing plans for this? It would be nice if the reference could be committed as well the first time around. That probably requires a bit of futzing to determine what the root objectid is going to be beforehand, then adding the link in the namespace, then flushing things out and updating the root item in the right order? sage -- 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: make metadata chunks smaller and don't preallocate metadata during allocations
This patch makes us a bit less zealous about making sure we have enough free
metadata space by pearing down the size of new metadata chunks to 256mb instead
of 1gb. Also, we used to try an allocate metadata chunks when allocating data,
but that sort of thing is done elsewhere now so we can just remove it. With my
-ENOSPC test I used to have 3gb reserved for metadata out of 75gb, now I have
1.7gb. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/extent-tree.c | 10 +-
fs/btrfs/volumes.c |2 +-
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 46c8c2f..9181278 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4594,17 +4594,9 @@ again:
* the only place that sets empty_size is btrfs_realloc_node, which
* is not called recursively on allocations
*/
- if (empty_size || root->ref_cows) {
- if (!(data & BTRFS_BLOCK_GROUP_METADATA)) {
- ret = do_chunk_alloc(trans, root->fs_info->extent_root,
-2 * 1024 * 1024,
-BTRFS_BLOCK_GROUP_METADATA |
-(info->metadata_alloc_profile &
- info->avail_metadata_alloc_bits), 0);
- }
+ if (empty_size || root->ref_cows)
ret = do_chunk_alloc(trans, root->fs_info->extent_root,
num_bytes + 2 * 1024 * 1024, data, 0);
- }
WARN_ON(num_bytes < root->sectorsize);
ret = find_free_extent(trans, root, num_bytes, empty_size,
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 7eda483..198cff2 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2209,7 +2209,7 @@ static int __btrfs_alloc_chunk(struct btrfs_trans_handle
*trans,
max_chunk_size = 10 * calc_size;
min_stripe_size = 64 * 1024 * 1024;
} else if (type & BTRFS_BLOCK_GROUP_METADATA) {
- max_chunk_size = 4 * calc_size;
+ max_chunk_size = 256 * 1024 * 1024;
min_stripe_size = 32 * 1024 * 1024;
} else if (type & BTRFS_BLOCK_GROUP_SYSTEM) {
calc_size = 8 * 1024 * 1024;
--
1.5.4.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: kernel .32, btrfs-vol -b, why is metadata=data
> In other words, btrfs-show could tell you that 19GB has been used, but > df could say that 0 bytes are in use in the FS. Thanks Chris for the clarification. So despite saying 19G are used, I shouldn't be worried about running out of disk space, since these are just pre-allocated areas. Perhaps btrfs-show should show how much areas are really used, besides how much are just pre-allocated. The thing is, I keep monitoring that number to avoid ENOSPC and now I know that number is not accurate. Thanks for the stellar work Regards -- 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 .32, btrfs-vol -b, why is metadata=data
On Sun, Dec 06, 2009 at 10:50:45AM +0200, Ahmed Kamal wrote: > Hi everyone, > > I'm running kernel 2.6.32-0.65.rc8.git5.fc13.x86_64. And I ran > "btrfs-vol -b", however for 10G of data I still have 9G of metadata! > How do I fix this ? > > [r...@matrix ~]# btrfs-vol -b / > ioctl returns 0 > You have mail in /var/spool/mail/root > [r...@matrix ~]# btrfs-show > failed to read /dev/sr0 > Label: none uuid: 06b0d069-b1cb-48c4-b26f-c5088a2360d2 > Total devices 1 FS bytes used 10.43GB > devid1 size 25.72GB used 19.02GB path /dev/dm-1 Used means something different here than it does to df. It just means that we've preallocated 19GB of space on the drive as either data or metadata, but it doesn't say if that space is actively used by the FS yet or not. In other words, btrfs-show could tell you that 19GB has been used, but df could say that 0 bytes are in use in the FS. This is because btrfs allocates from devices to create chunks at a specific raid level and then does suballocations inside those chunks. -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
