On 09/08/2011 01:32 PM, C Anthony Risinger wrote:
On Wed, Sep 7, 2011 at 1:44 AM, Jeff Liujeff@oracle.com wrote:
On 09/07/2011 12:37 PM, cwillu wrote:
1. Create and format two images, the 1st in 400Mbytes, and 2nd in
286Mbytes.
root@pibroch:/btrfs-progs# ls -lh /usr/src/linux-3.0/img*
On 09/05/2011 06:29 PM, Hugo Mills wrote:
On Mon, Sep 05, 2011 at 12:25:21PM -0400, Christoph Hellwig wrote:
On Mon, Sep 05, 2011 at 06:23:23PM +0200, Tomasz Chmielewski wrote:
That's because dpkg is known for using (f)sync very heavily. btrfs
honours the sync request in all cases, so it's
On Wed, Sep 7, 2011 at 10:51 PM, Arne Jansen sensi...@gmx.net wrote:
I think Liu Bo posted a fix for this a while ago:
[PATCH] Btrfs: fix a bug of balance on full multi-disk partitions
-Arne
The behavior that this patch describes looks pretty much exactly like
what I was seeing, although in
Since btrfs_free_space_cachep is just used in free-space-cache.c, declaring it
as a static global variable in free-space-cache.c can make the source more
readable, and less coupling.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ctree.h|1 -
This patch introduce free space cluster for each node in the b+tree. And
we also simplify the fill method and the space allocation of the cluster:
- Allocate free space cluster for each node
- Allocate the free space extent (=256KB, split a large extent or get the
contiguous blocks from the
At the beginning of create_pending_snapshot, trans-block_rsv is set
to pending-block_rsv and is used for snapshot things, however, when
it is done, we do not recover it as will.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/transaction.c |4
1 files changed, 4
While truncating free space cache, we forget to change trans-block_rsv
back to the original one, but leave it with the orphan_block_rsv, and
then with option inode_cache enable, it leads to countless warnings of
btrfs_alloc_free_block and btrfs_orphan_commit_root:
WARNING: at
Hi All,
My company is considering using BtrFS for some of our production
systems, but before we can use it, I must positively verify that the
TRIM command is being issued to the SSDs. I attempted to verify TRIM
first using examples that work for Ext4
http://andyduffell.com/techblog/?p=852, but I
btrfs_invalidate_inodes has no error conditions and should return void.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/ctree.h |2 +-
fs/btrfs/inode.c |3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2590,7 +2590,7 @@
btrfs_submit_bio_hook currently calls btrfs_bio_wq_end_io in either case
of an if statement that determines one of the arguments.
This patch moves the function call outside of the if statement and uses it
to only determine the different argument. This allows us to catch an
error in one place
This patch handles btrfs_start_transaction failures that don't occur
in a loop and are obvious to simply push up. In all cases except the
mark_garbage_root case, the error is already handled by BUG_ON in the
caller.
Update v2: This version also checks the returns from btrfs_drop_snapshot.
This pushes failures from the submit_bio_hook callbacks,
btrfs_submit_bio_hook and btree_submit_bio_hook into the callers, including
callers of submit_one_bio where it catches the failures with BUG_ON.
It also pushes up through the -readpage_io_failed_hook to
end_bio_extent_writepage where
btrfs_init_compress doesn't have any failure conditions, so return void.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/compression.h |2 +-
fs/btrfs/super.c |5 +
2 files changed, 2 insertions(+), 5 deletions(-)
--- a/fs/btrfs/compression.c
+++
lock_extent, try_lock_extent, and lock_extent_bits can't currently fail
because errors are caught via BUG_ON.
This patch pushes the error handling up to callers, which currently
only handle them via BUG_ON themselves.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/compression.c
The previous patch pushed the clear_extent_bit error handling up a level,
which included unlock_extent and unlock_extent_cache.
This patch pushes the BUG_ON up into the callers of those functions.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/compression.c |9 ++--
btrfs_prepare_extent_commit, btrfs_set_block_group_rw, and
setup_inline_extent_backref have no error conditions and should return void.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/ctree.h |8
fs/btrfs/extent-tree.c | 20 +---
2 files changed, 13
wait_on_state, wait_extent_bit, __unlock_for_delalloc, check_page_uptodate,
check_page_locked, check_page_writeback, and clear_extent_buffer_dirty
have no error conditions and should return void.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/extent_io.c | 29
In the locking case, set_extent_bit can return -EEXIST but callers
already handle that.
In the non-locking case, it can't fail. Memory allocation failures are
handled by BUG_ON.
This patch pushes up the BUG_ONs from set_extent_bit to callers, except
where -ENOMEM can't occur (e.g.
clear_extent_bit can fail with -ENOMEM for a specific case but will BUG
on other memory allocation failures.
This patch returns -ENOMEM for memory allocation failures and handles them
with BUG_ON in callers which don't handle it already.
Signed-off-by: Jeff Mahoney je...@suse.com
---
Commit cb1b69f4 (Btrfs: forced readonly when btrfs_drop_snapshot() fails)
made btrfs_drop_snapshot return void because there were no callers checking
the return value. That is the wrong order to handle error propogation since
the caller will have no idea that an error has occured and continue on
btrfs_destroy_delalloc_inodes and __setup_root have no error conditions and
should return void.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/disk-io.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -54,7
btrfs_run_defrag_inodes contains no error conditions and should return
void.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/ctree.h |2 +-
fs/btrfs/file.c |3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2612,7
set_range_writeback has no error conditions that aren't fatal logic errors.
This patch makes it return void to eliminate an error site.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/extent_io.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
---
btrfs_pin_extent looks up a block group and then calls pin_down_extent
with it. If the lookup fails, it should return -ENOENT to allow callers
to handle the error condition. For the three existing callers, it is
a logic error if the lookup fails and a panic will occur.
Signed-off-by: Jeff
pin_down_extent performs some operations which can't fail and then calls
set_extent_dirty, which has two failure cases via set_extent_bit:
1) Return -EEXIST if exclusive bits are set
- Since it doesn't use any exclusive bits, this failure case can't
occur.
2) Return -ENOMEM if
btrfs_cleanup_fs_uuids, run_scheduled_bios, btrfs_close_extra_devices,
schedule_bio, and fill_device_from_item have no error conditions and
should return void.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/volumes.c | 25 +
fs/btrfs/volumes.h |4 ++--
2
Hi all -
The following 23 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
run_ordered_completions, btrfs_stop_workers, btrfs_requeue_work, and
btrfs_queue_worker don't have any error conditions and should return
void.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/async-thread.c | 31 ++-
fs/btrfs/async-thread.h |7 ---
btrfs_end_log_trans and wait_for_writer have no error conditions and should
return void.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/tree-log.c |6 ++
fs/btrfs/tree-log.h |2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
--- a/fs/btrfs/tree-log.c
+++
The *_state functions can only return 0 or -EEXIST. This patch addresses
the cases where those functions return -EEXIST, representing a locking
failure. It handles them by panicking with an appropriate error message.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/extent_io.c | 42
In submit_extent_page, there's a visually noisy if statement that, in
the midst of other conditions, does the tree dependency for tree-ops
and tree-ops-merge_bio_hook before calling it, and then another
condition afterwards. If an error is returned from merge_bio_hook,
there's no way to catch
As part of the effort to eliminate BUG_ON as an error handling
technique, we need to determine which errors are actual logic errors,
which are on-disk corruption, and which are normal runtime errors
e.g. -ENOMEM.
Annotating these error cases is helpful to understand and report them.
This
On Tue, 2011-08-30 at 14:27 +0800, Miao Xie wrote:
On mon, 29 Aug 2011 02:45:07 +0100, Maciej Marcin Piechotka wrote:
I receive the bug when I try to snapshot from fcron:
2011-08-29T02:00:46.529238+01:00 picard kernel: [ 4155.76]
[ cut here ]
On Fri, 09 Sep 2011 02:13:38 +0100
Maciej Marcin Piechotka uzytkown...@gmail.com wrote:
c) It usually happens a few minutes past 3 UTC. I have no idea what is
casuing this but it is consistent.
Did you check if your /etc/crontab or /etc/cron.d/* have anything scheduled for
that time?
--
On Fri, 2011-09-09 at 09:02 +0600, Roman Mamedov wrote:
On Fri, 09 Sep 2011 02:13:38 +0100
Maciej Marcin Piechotka uzytkown...@gmail.com wrote:
c) It usually happens a few minutes past 3 UTC. I have no idea what is
casuing this but it is consistent.
Did you check if your /etc/crontab or
(resend with linux-btrfs Cced)
Hi All,
My company is considering using BtrFS for some of our production
systems, but before we can use it, I must positively verify that the
TRIM command is being issued to the SSDs. 營 attempted to verify TRIM
first using examples that work for Ext4
36 matches
Mail list logo
