similar to: [PATCH] Btrfs: fix missing clear_extent_bit

We currently have this problem where you can truncate pages that have not yet been written for an ordered extent. We do this because the truncate will be coming behind to clean us up anyway so what''s the harm right? Well if truncate fails for whatever reason we leave an orphan item around for the file to be cleaned up later. But if the user goes and truncates up the file and tries to

Hi all - The following 9 patches add more error handling to the btrfs code: - Add btrfs_panic - Catch locking failures in {set,clear}_extent_bit - Push up set_extent_bit errors to callers - Push up lock_extent errors to callers - Push up clear_extent_bit errors to callers - Push up unlock_extent errors to callers - Make pin_down_extent return void - Push up btrfs_pin_extent errors to

We''re going to use this flag EXTENT_DEFRAG to indicate which range belongs to defragment so that we can implement snapshow-aware defrag: We set the EXTENT_DEFRAG flag when dirtying the extents that need defragmented, so later on writeback thread can differentiate between normal writeback and writeback started by defragmentation. This patch is used for the latter one. Originally patch

The inode eviction can be very slow, because during eviction we tell the VFS to truncate all of the inode''s pages. This results in calls to btrfs_invalidatepage() which in turn does calls to lock_extent_bits() and clear_extent_bit(). These calls result in too many merges and splits of extent_state structures, which consume a lot of time and cpu when the inode has many pages. In some

Rewrite btrfs_drop_extents by using btrfs_duplicate_item, so we can avoid calling lock_extent within transaction. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- fs/btrfs/ctree.h | 7 +- fs/btrfs/file.c | 659 ++++++++++++++++++++------------------------------- fs/btrfs/inode.c | 27 +-- fs/btrfs/ioctl.c | 3 +- fs/btrfs/tree-log.c | 4 +- 5 files changed, 277

I noticed that if the free space cache has an error writing out it''s data it won''t actually error out, it will just carry on. This is because it doesn''t check the return value of btrfs_wait_ordered_range, which didn''t actually return anything. So fix this in order to keep us from making free space cache look valid when it really isnt. Thanks, Signed-off-by:

Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them

Document those places in the btrfs code which are BUGing on non-fatal error conditions that should be handled by proper error paths. This makes it easier to distinguish between what needs fixing versus which BUG_ON''s we might want to keep (to trap code bugs, unexpected inconsistencies, etc). Do this with a trivial macro, ''btrfs_fixable_bug_on'' which just defines to

This depends on the change to ordered data search. Signed-off-by: jim owens <owens6336@gmail.com> --- fs/btrfs/dio.c | 150 +++++++++++++++++++++++++++++++++++++++----------------- 1 files changed, 104 insertions(+), 46 deletions(-) diff --git a/fs/btrfs/dio.c b/fs/btrfs/dio.c index b6934be..c930ff5 100644 --- a/fs/btrfs/dio.c +++ b/fs/btrfs/dio.c @@ -435,14 +435,81 @@ static void

Use access_extent_buffer_page() to point at btree location of inline compressed data so it can be inflated without a memcopy. Signed-off-by: jim owens <jowens@hp.com> Signed-off-by: jim owens <jim6336@gmail.com> --- V2 fixes whitespace checkpatch warning fs/btrfs/extent_io.c | 16 ++++++++++++++++ fs/btrfs/extent_io.h | 3 +++ 2 files changed, 19 insertions(+), 0 deletions(-)

From: Wade Cline <clinew@linux.vnet.ibm.com> This patch is only an RFC. My internship is ending and I was hoping to get some feedback and incorporate any suggestions people may have before my internship ends along with life as we know it (this Friday). The filesystem should mount/umount properly but tends towards the explosive side when writes start happening. My current focus is on

In clear_extent_bit, it is enough that next node is adjacent in tree level. Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> --- fs/btrfs/extent_io.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index fcf77e1..e941cc4 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -577,8 +577,7 @@ hit_next: if

So both Liu and I made huge messes of find_lock_delalloc_range trying to fix stuff, me first by fixing extent size, then him by fixing something I broke and then me again telling him to fix it a different way. So this is obviously a candidate for some testing. This patch adds a pseudo fs so we can allocate fake inodes for tests that need an inode or pages. Then it addes a bunch of tests to make

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

I've had a few systems with a lot of RAM and very busy filesystems come up with filesystem errors that took a manual 'fsck -y' after what should have been a clean reboot. This is particularly annoying on remote systems where I have to talk someone else through the recovery. Is there some time limit on the cache write with a 'reboot' (no options) command or is ext4 that

The type of some functions that return only 0 is changed to ''void''. In addition, the check on the return value in the caller of these functions becomes unnecessary. So, these check is removed. Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> --- fs/btrfs/async-thread.c | 17 ++++-------- fs/btrfs/async-thread.h | 4 +- fs/btrfs/compression.c | 14 ++++------

Hi everybody, I'm runing dovecot 2.2.12 and a user mailbox got the "broken sync positions in index file" error twice in the last 20 days. this is an extract from the maillog maillog First Error -------------------- Mar 23 16:13:25 andromeda dovecot: pop3-login: Login: user=<myuser at mydomain.com>, method=PLAIN, rip=187.237.107.24, lip=207.7.90.83, mpid=3983,

We specifically do not update the disk i_size if there are ordered extents outstanding for any area between the current disk_i_size and our ordered extent so that we do not expose stale data. The problem is the check we have only checks if the ordered extent starts at or after the current disk_i_size, which doesn''t take into account an ordered extent that starts before the current

There are several bugs at error path of create_snapshot() when the transaction commitment failed. - access the freed transaction handler. At the end of the transaction commitment, the transaction handler was freed, so we should not access it after the transaction commitment. - we were not aware of the error which happened during the snapshot creation if we submitted a async transaction

This patch adds value_byte_runs and node_byte_runs. Each byte run represents the offset and length of a data structure within the hive, one per node, and one or two per value depending on the length of the value data. These byte run functions also add additional data sanity checks as a hive is being parsed, mainly checking that a node address actually points to a node, and similarly for values.