Displaying 20 results from an estimated 900 matches similar to: "[PATCH 02/11] Btrfs: use atomic for fs_info->last_trans_committed"
2013 Jan 10
0
[PATCH 03/11] Btrfs: use atomic for fs_info->last_trans_log_full_commit
fs_info->last_trans_log_full_commit is a 64bits variant, we might get a
wrong value on the 32bit machines if we access it directly. Fix it by atomic
operation.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
---
fs/btrfs/ctree.h | 2 +-
fs/btrfs/extent-tree.c | 3 ++-
fs/btrfs/inode.c | 3 ++-
fs/btrfs/tree-log.c |
2010 Apr 19
0
[PATCH 08/12] Btrfs: Introduce global metadata reservation
Reserve metadata space for extent tree, checksum tree and root tree
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
---
diff -urp 8/fs/btrfs/ctree.h 9/fs/btrfs/ctree.h
--- 8/fs/btrfs/ctree.h 2010-04-18 10:26:38.327697818 +0800
+++ 9/fs/btrfs/ctree.h 2010-04-18 10:30:01.883697869 +0800
@@ -682,21 +682,15 @@ struct btrfs_space_info {
u64 bytes_reserved; /* total bytes the allocator has
2007 Aug 09
1
[RFC] All my fsync changes
Hello,
Ok here are all my fsync changes, including the fix for the put_transaction
stuff that I posted earlier. I figure it'll be easier to just commit it as one
thing then each individual peice. The additional thing that I did was add a
radix tree that tracks the current outstanding transactions. I also added a
field to the in memory btrfs inode that keeps track of the last transaction
2009 Aug 24
0
[PATCH] Btrfs: proper metadata -ENOSPC handling
This patch finally gives us full proper -ENOSPC handling for btrfs. Now
whenever you do a btrfs_start_transaction, you must specify the number of items
you are planning to add/delete/modify. The worst case number of blocks that
could be modified by changing that number of items will be calculated and
checked against the amount of free space in the space_info where the root you
are modifying
2011 Mar 23
0
[PATCH] Btrfs: cleanup some BUG_ON()
This patch changes some BUG_ON() to the error return.
(but, most callers still use BUG_ON())
Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
---
fs/btrfs/ctree.c | 3 ++-
fs/btrfs/disk-io.c | 5 ++++-
fs/btrfs/extent-tree.c | 25 ++++++++++++++++++-------
fs/btrfs/file-item.c | 3 ++-
fs/btrfs/inode-map.c | 3 ++-
fs/btrfs/ioctl.c | 5 ++++-
2010 Oct 26
0
[PATCH v2] Btrfs: fix deadlock in btrfs_commit_transaction
We calculate timeout (either 1 or MAX_SCHEDULE_TIMEOUT) based on whether
num_writers > 1 or should_grow at the top of the loop. Then, much much
later, we wait for that timeout if either num_writers or should_grow is
true. However, it''s possible for a racing process (calling
btrfs_end_transaction()) to decrement num_writers such that we wait
forever instead of for 1.
Fix this by
2011 Jun 21
19
[GIT PULL v3] Btrfs: improve write ahead log with sub transaction
I''ve been working to try to improve the write-ahead log''s performance,
and I found that the bottleneck addresses in the checksum items,
especially when we want to make a random write on a large file, e.g a 4G file.
Then a idea for this suggested by Chris is to use sub transaction ids and just
to log the part of inode that had changed since either the last log commit or
the last
2013 Mar 04
2
[PATCH 1/2] Btrfs: fix wrong handle at error path of create_snapshot() when the commit fails
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
2010 Sep 03
0
[PATCH 1/2] btrfs: document where we use BUG_ON instead of error handling
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
2012 Jan 10
0
[PATCH V2] Btrfs: cleanup: move node-,leaf-,sectorsize to fs_info
moved the node-,leaf-,sectorsize from btrfs_root to btrfs_fs_info
since we don''t intend to allow different sizes between trees
also removed sectorsize from btrfs_block_group_cache because it now
can use the one in fs_info
updated all uses accordingly
please note in disk-io.c:
-static int __setup_root(nodesize, leafsize, sectorsize, stripesize,
- *root,
2011 Aug 26
0
[PATCH] Btrfs: make some functions return void
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 ++++------
2015 Nov 12
0
[PATCH] VMCI: Use 32bit atomics for queue headers on X86_32
This change restricts the reading and setting of the head and tail
pointers on 32bit X86 to 32bit for both correctness and
performance reasons. On uniprocessor X86_32, the atomic64_read
may be implemented as a non-locked cmpxchg8b. This may result in
updates to the pointers done by the VMCI device being overwritten.
On MP systems, there is no such correctness issue, but using 32bit
atomics avoids
2015 Nov 12
0
[PATCH] VMCI: Use 32bit atomics for queue headers on X86_32
This change restricts the reading and setting of the head and tail
pointers on 32bit X86 to 32bit for both correctness and
performance reasons. On uniprocessor X86_32, the atomic64_read
may be implemented as a non-locked cmpxchg8b. This may result in
updates to the pointers done by the VMCI device being overwritten.
On MP systems, there is no such correctness issue, but using 32bit
atomics avoids
2015 Oct 07
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
The virtgpu driver prints the last_seq variable using the %ld or
%lu format string, which does not work correctly on all architectures
and causes this compiler warning on ARM:
drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str':
drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but
2015 Oct 07
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
The virtgpu driver prints the last_seq variable using the %ld or
%lu format string, which does not work correctly on all architectures
and causes this compiler warning on ARM:
drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str':
drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but
2010 Mar 22
5
[PATCH 0/5] asynchronous commit, snapshot ponies
Hi everyone,
This patchset is the latest approach I''m using for the Ceph storage daemon to
keep track of which data has safely committed to disk. The basic idea is to
not use the (problematic) user transaction ioctls at all. Instead, the daemon
quiesces its own write requests, initiates an async snapshot, and then
continues.
The snapshot approach is nice because it provides rollback.
2015 Sep 02
1
[PATCH] virtio-gpu: fix compilation warnings
Update snprintf format in virtgpu_fence.c and virtgpu_debugfs.c to fix the
following compilation warnings:
C [M] drivers/gpu/drm/virtio/virtgpu_fence.o
drivers/gpu/drm/virtio/virtgpu_fence.c: In function ?virtio_timeline_value_str? :
drivers/gpu/drm/virtio/virtgpu_fence.c:64:2: warning: format ?%lu? expects argument of type ?long unsigned int?, but argument 4 has type ?long long int? [-Wformat=]
2015 Sep 02
1
[PATCH] virtio-gpu: fix compilation warnings
Update snprintf format in virtgpu_fence.c and virtgpu_debugfs.c to fix the
following compilation warnings:
C [M] drivers/gpu/drm/virtio/virtgpu_fence.o
drivers/gpu/drm/virtio/virtgpu_fence.c: In function ?virtio_timeline_value_str? :
drivers/gpu/drm/virtio/virtgpu_fence.c:64:2: warning: format ?%lu? expects argument of type ?long unsigned int?, but argument 4 has type ?long long int? [-Wformat=]
2012 Aug 24
4
[PATCH] Btrfs: pass lockdep rwsem metadata to async commit transaction
The freeze rwsem is taken by sb_start_intwrite() and dropped during the
commit_ or end_transaction(). In the async case, that happens in a worker
thread. Tell lockdep the calling thread is releasing ownership of the
rwsem and the async thread is picking it up.
Josef and I worked out a more complicated solution that made the async
commit thread join and potentially get a later transaction, but
2013 Apr 13
0
btrfs crash (and softlockup btrfs-endio-wri)
I am using NFS over brtfs (vanilla 3.8.5) for heavy CoW to clone virtual
disks with sizes 20-50GB. It worked OK for a couple of days, but
yesterday it crashed. Reboot fixed the problem and I do not see any data
corruption. I have a couple of different kdumps, I will include one as
text and attach the other ones.
I am using Fedora 18 with vanilla 3.8.5. The filesystem is created over
a SAN volume