search for: block_groups

The whole loop=0,1,2 thing was kind of odd and not very self explanatory. I''ve replaced it with a list_for_each_entry on space_info->block_groups. If we have a hint we just jump into the loop with the block group and start looking for space. If we don''t find anything we start at the beginning and start looking. We never come out of the loop with a ref on the block_group _unless_ we found space to use, then we drop it after we set...

...are in the hint phase. We lookup the block group for the hint, and lookup the space_info for what we want to allocate out of. If the block group we were pointed at by the hint either isn''t of the correct type, or just doesn''t have the space we need, we set head to space_info->block_groups, so we start at the beginning of the block groups for this particular space info, and loop through. This is also where we add the empty_cluster to total_needed. At this point loop is set to 1 and we just loop through all of the block groups for this particular space_info looking for the space we n...

I recently bought 2 different USB flash disks. These are some cheap no-name devices. Their parameters: bytes C/H/S ID 4194304512 509/255/63 Vendor: Generic Model: USB Flash Drive Rev: 1.00 ANSI SCSI revision: 02 4288676352 1023/132/62 Vendor: USB Model: USB 2.0 Rev: 1.00 ANSI SCSI revision: 02 When I put a FAT32 filesystem on them,

Yan Zheng hit a problem where we tried to remove some free space but failed because we couldn''t find the free space entry. This is because the free space was held within a bitmap that had a starting offset well before the actual offset of the free space, and there were free space extents that were in the same range as that offset, so tree_search_offset returned with NULL because we

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

If we are looking for a cluster in a particularly sparse or fragmented block group, we will do a lot of looping through the free space tree looking for various things, and if we need to look at bitmaps we will endup doing the whole dance twice. So instead add the bitmap entries to a temporary list so if we have to do the bitmap search we can just look through the list of entries we''ve

The biggest one is a fix for fstrim, and there''s a fix for on-disk free space cache. Others are small fixes and cleanups. The last three have been sent weeks ago. The patchset is also available in this repo: git://repo.or.cz/linux-btrfs-devel.git for-chris Note there''s a small confict with Al Viro''s vfs changes. Li Zefan (11): Btrfs: add pinned extents to

...(&block_group->space_info->lock); - block_group->space_info->bytes_super += block_group->bytes_super; - spin_unlock(&block_group->space_info->lock); - last = max_t(u64, block_group->key.objectid, BTRFS_SUPER_INFO_OFFSET); /* @@ -7499,6 +7541,7 @@ int btrfs_free_block_groups(struct btrfs if (block_group->cached == BTRFS_CACHE_STARTED) wait_block_group_cache_done(block_group); + free_excluded_extents(info->extent_root, block_group); btrfs_remove_free_space_cache(block_group); btrfs_put_block_group(block_group); @@ -7586,26 +7629,12 @@ int btrfs_r...

hiya! see the attached file for the resolved bug() call. my kernel spit out 185 messages like this: Mar 9 17:15:13 srck@trottelkunde attempt to access beyond end of device Mar 9 17:15:13 srck@trottelkunde 16:42: rw=0, want=0, limit=12289725 right before the bug(). this message didn't get parsed by ksymoops Mar 9 17:15:13 srck@trottelkunde Assertion failure in journal_start() at

If we have particularly full nodes, we could call btrfs_node_blockptr up to 32 times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the extent buffer while we look for readahead targets. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ctree.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git

...es, int reserve, int sinfo); int btrfs_prepare_extent_commit(struct btrfs_trans_handle *trans, struct btrfs_root *root); int btrfs_finish_extent_commit(struct btrfs_trans_handle *trans, @@ -2269,8 +2267,11 @@ void btrfs_put_block_group_cache(struct btrfs_fs_info *info); u64 btrfs_account_ro_block_groups_free_space(struct btrfs_space_info *sinfo); int btrfs_error_unpin_extent_range(struct btrfs_root *root, u64 start, u64 end); -int btrfs_error_discard_extent(struct btrfs_root *root, u64 bytenr, - u64 num_bytes, u64 *actual_bytes); +int btrfs_discard_extent(struct btrfs_root *root,...

...es, int reserve, int sinfo); int btrfs_prepare_extent_commit(struct btrfs_trans_handle *trans, struct btrfs_root *root); int btrfs_finish_extent_commit(struct btrfs_trans_handle *trans, @@ -2269,8 +2267,11 @@ void btrfs_put_block_group_cache(struct btrfs_fs_info *info); u64 btrfs_account_ro_block_groups_free_space(struct btrfs_space_info *sinfo); int btrfs_error_unpin_extent_range(struct btrfs_root *root, u64 start, u64 end); -int btrfs_error_discard_extent(struct btrfs_root *root, u64 bytenr, - u64 num_bytes, u64 *actual_bytes); +int btrfs_discard_extent(struct btrfs_root *root,...

Hello, This patch fixes a problem where we end up seeking too much when *last_ptr is valid. This happens because btrfs_lookup_first_block_group only returns a block group that starts on or after the given search start, so if the search_start is in the middle of a block group it will return the block group after the given search_start, which is suboptimal. This patch fixes that by doing a

Hi all, It seems like memory barrier is not required in cached_block_group.I am looking at kernel 2.6.34-rc2. cache_block_group(struct btrfs_block_group_cache *cache) { smp_mb(); if (cache->cached != BTRFS_CACHE_NO) return 0; .... } This function is called from btrfs_alloc_logged_file_extent and find_free_extent. In btrfs_alloc_logged_file_extent the code snippet is as follows

Hello, This patch simplifies the nodatacow checker. If all references were created after the latest snapshot, then we can avoid COW safely. This patch also updates run_delalloc_nocow to do more fine-grained checking. Regards Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 3/fs/btrfs/ctree.h 4/fs/btrfs/ctree.h --- 3/fs/btrfs/ctree.h 2008-10-27 16:31:51.000000000 +0800 +++

...e.c @@ -26,6 +26,7 @@ #include "transaction.h" #include "crc32c.h" #include "volumes.h" +#include "free-space-cache.h" #define BLOCK_GROUP_DATA EXTENT_WRITEBACK #define BLOCK_GROUP_METADATA EXTENT_UPTODATE @@ -3176,6 +3177,7 @@ out: int btrfs_free_block_groups(struct btrfs_fs_info *info) { struct btrfs_space_info *sinfo; + struct btrfs_block_group_cache *cache; u64 start; u64 end; u64 ptr; @@ -3187,8 +3189,14 @@ int btrfs_free_block_groups(struct btrfs_fs_info *info) if (ret) break; ret = get_state_private(&info->block_group_cac...

Hi ! My system is RH7.2 with Adaptec/DPT/I2O drivers (http://people.redhat.com/tcallawa/dpt/). There is a 2 disk RAID 1 array which had no disk fail. Several partition on it: Filesystem Size Used Avail Use% Mounted on /dev/sda1 1.9G 435M 1.4G 24% / /dev/sda2 13G 3.2G 9.1G 26% /home none 504M 0 503M 0% /dev/shm At this time, all

I have a usb hd that I use for backup. Occasionally it dies. scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device scsi 6:0:0:0: rejecting I/O to dead device Buffer I/O error on device sdc1, logical block 0 lost page write due to I/O error on sdc1 EXT2-fs error (device sdc1): read_inode_bitmap: Cannot read inode bitmap -

...may_use, - (unsigned long long)info->bytes_used); + (unsigned long long)info->bytes_used, + (unsigned long long)info->bytes_readonly, + (unsigned long long)info->bytes_super); down_read(&info->groups_sem); list_for_each_entry(cache, &info->block_groups, list) { spin_lock(&cache->lock); printk(KERN_INFO "block group %llu has %llu bytes, %llu used " - "%llu pinned %llu reserved\n", + "%llu pinned %llu reserved %llu super and is%s " + "read only\n", (unsigned long...

Hello, This patch adds a new parameter 'full_scan' to 'find_search_start', thereby 'find_search_start' can know whether 'find_free_extent' is in full scan phrase. I feel that 'find_search_start' should skip calling 'btrfs_find_block_group' when 'find_free_extent' is in full scan phrase. In my test on a 2GB volume, Oops occurs when space