On 21.10.2017 02:53, Liu Bo wrote:
> In functions like btrfs_create(), we run both
> btrfs_balance_delayed_items() and btrfs_btree_balance_dirty() after
> the operation, but btrfs_btree_balance_dirty() is surely going to run
> btrfs_balance_delayed_items().
>
> This keeps only btrfs_btree_balanc
On Fri, Oct 20, 2017 at 05:53:41PM -0600, Liu Bo wrote:
>In functions like btrfs_create(), we run both
>btrfs_balance_delayed_items() and btrfs_btree_balance_dirty() after
>the operation, but btrfs_btree_balance_dirty() is surely going to run
>btrfs_balance_delayed_items().
>
>This keeps only btrfs
Hi,
Please ignore this patch, I misunderstood the lock order.
thanks,
-liubo
On Fri, Oct 20, 2017 at 05:40:12PM -0600, Liu Bo wrote:
> Here %path is set with ->leave_spinning=1, thus it'll hold the rwlock
> after btrfs_search_slot(), however, when processing delayed items in
> __btrfs_commit_in
Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted:
> Is it generally possible to restore a btrfs partition from a tape backup
> ?
> I'm just starting, and I'm asking myself. What is about the subvolumes ?
> This information isn't stored in files, but in the fs ? This is not on a
In functions like btrfs_create(), we run both
btrfs_balance_delayed_items() and btrfs_btree_balance_dirty() after
the operation, but btrfs_btree_balance_dirty() is surely going to run
btrfs_balance_delayed_items().
This keeps only btrfs_btree_balance_dirty().
Signed-off-by: Liu Bo
---
fs/btrfs/
Here %path is set with ->leave_spinning=1, thus it'll hold the rwlock
after btrfs_search_slot(), however, when processing delayed items in
__btrfs_commit_inode_delayed_items(), it goes to acquire node->mutex
which might sleep, that is, it may sleep under spin_lock.
Given node->mutex is necessary t
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of Lentes, Bernd
> Sent: Friday, October 20, 2017 7:26 PM
> To: Btrfs ML
> Subject: RE: SLES 11 SP4: can't mount btrfs
>
>
> > -Original Message-
> > From: Andrei
On Wed, Oct 11, 2017 at 12:13:30PM -0600, Liu Bo wrote:
> It's pointless to defer it to a kthread helper as we're not under any
> special context.
>
> A bit more about device's lifetime, filesystems use an exclusive way
> to access devices and hold a reference count on the devices in use.
> Now th
btrfs_end_bio() is using btrfs_dev_stat_inc() and then
btrfs_dev_stat_print_on_error() separately instead use
btrfs_dev_stat_inc_and_print() directly.
As of now there isn't any bio in btrfs which is - a non-empty write and
also the REQ_PREFLUSH flag is set. So in actual the condition
if (bio->b
On 10/20/2017 11:27 PM, David Sterba wrote:
On Fri, Oct 20, 2017 at 05:50:59PM +0800, Anand Jain wrote:
btrfs_end_bio() is using btrfs_dev_stat_inc() and then
btrfs_dev_stat_print_on_error() separately instead
use btrfs_dev_stat_inc_and_print() directly.
No need to worry about print lines one
> -Original Message-
> From: Andrei Borzenkov [mailto:arvidj...@gmail.com]
> Sent: Friday, October 20, 2017 6:09 AM
> To: Chris Murphy ; Lentes, Bernd
>
> Cc: Btrfs ML
> Subject: Re: SLES 11 SP4: can't mount btrfs
>
> 19.10.2017 23:04, Chris Murphy пишет:
> > Btrfs
> > is not just suppor
On Thu, Oct 19, 2017 at 02:15:54PM -0400, Josef Bacik wrote:
> Here's the updated batch of the remaining queue of patches from me. I've
> addressed all of the outstanding review feedback for everything and they've
> been
> pretty thoroughly tested. Most of the changes are around changelogs and
On Fri, Oct 20, 2017 at 05:50:59PM +0800, Anand Jain wrote:
> btrfs_end_bio() is using btrfs_dev_stat_inc() and then
> btrfs_dev_stat_print_on_error() separately instead
> use btrfs_dev_stat_inc_and_print() directly.
>
> No need to worry about print lines one for read/write
> and another if the so
- On Oct 20, 2017, at 11:10 AM, Nikolay Borisov nbori...@suse.com wrote:
> Commit addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev stats
> is
> cleared")
> reworked the way device stats changes are tracked. A new atomic dev_stats_ccnt
> counter was introduced which is increme
It's sole callsite was removed in a previous patch so just nuke it for good.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/volumes.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
index 0b8ddcbf8462..3509a68d274f 100644
--- a/fs/btrfs/volumes.h
+++
As per atomic_t.txt documentation :
- RMW operations that have a return value are fully ordered;
atomic_xchg is one such operation so it already includes everything it needs
w.r.t memory ordering and add a comment ot be more explicit about that.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/volu
Commit addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev stats
is cleared")
reworked the way device stats changes are tracked. A new atomic dev_stats_ccnt
counter was introduced which is incremented every time any of the device stats
counters are changed. This serves as a flag wheth
We aren't setting the FMODE_WRITE when initializing btrfs_device
structure and when calling blkdev_put, however we are setting it
only when calling blkdev_get_by_path().
Signed-off-by: Anand Jain
---
v2: Reword commit log.
fs/btrfs/volumes.c | 16
1 file changed, 8 insertions(+
On 10/20/2017 08:26 PM, Nikolay Borisov wrote:
On 20.10.2017 13:33, Anand Jain wrote:
We aren't saving the fmode_t flags at %struct btrfs_device->mode same
as it used to open the device at device replace, so fix that.
I think this could use a bit of rewording to better explain what the
pro
On Fri, Oct 20, 2017 at 01:48:01AM +0300, Timofey Titovets wrote:
> 2017-10-19 18:39 GMT+03:00 David Sterba :
> > On Fri, Sep 29, 2017 at 06:22:00PM +0200, David Sterba wrote:
> >> On Thu, Sep 28, 2017 at 05:33:35PM +0300, Timofey Titovets wrote:
> >> > Compile tested, hand tested on live system
>
On 20.10.2017 13:33, Anand Jain wrote:
> We aren't saving the fmode_t flags at %struct btrfs_device->mode same
> as it used to open the device at device replace, so fix that.
I think this could use a bit of rewording to better explain what the
problem and what it can potentially cause.
>
> Sig
On 2017-10-19 14:39, Peter Grandi wrote:
[ ... ]
Oh please, please a bit less silliness would be welcome here.
In a previous comment on this tedious thread I had written:
If the block device abstraction layer and lower layers work
correctly, Btrfs does not have problems of that sort when
addi
On 20.10.2017 12:50, Anand Jain wrote:
> btrfs_end_bio() is using btrfs_dev_stat_inc() and then
> btrfs_dev_stat_print_on_error() separately instead
> use btrfs_dev_stat_inc_and_print() directly.
>
> No need to worry about print lines one for read/write
> and another if the source of IO request
We aren't saving the fmode_t flags at %struct btrfs_device->mode same
as it used to open the device at device replace, so fix that.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/
Devices opened through replace/add would have FMODE_WRITE | FMODE_EXCL,
as compared with devices opened through the mount which will have
FMODE_READ | FMODE_WRITE | FMODE_EXCL. So maintain consistency.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 4 ++--
1 file changed, 2 insertions(+), 2
> Elena Reshetova writes:
> > Elena Reshetova (6):
> > block: convert bio.__bi_cnt from atomic_t to refcount_t
> > block: convert blk_queue_tag.refcnt from atomic_t to refcount_t
> > block: convert blkcg_gq.refcnt from atomic_t to refcount_t
> > block: convert io_context.active_ref from a
btrfs_end_bio() is using btrfs_dev_stat_inc() and then
btrfs_dev_stat_print_on_error() separately instead
use btrfs_dev_stat_inc_and_print() directly.
No need to worry about print lines one for read/write
and another if the source of IO request is flush, since
as mentioned in this patch
[patch] b
On 2017年10月20日 17:25, Po-Hsu Lin wrote:
> Thanks for the info.
>
> I have checked the comment inside the test case, which state that:
> # And unfortunately, btrfs send is one of these operations, and will cause
> # softlock or OOM on systems with small memory(<4G).
>
> To my experience, this wi
Thanks for the info.
I have checked the comment inside the test case, which state that:
# And unfortunately, btrfs send is one of these operations, and will cause
# softlock or OOM on systems with small memory(<4G).
To my experience, this will stuck on a system with 32G memory too.
And in the en
Elena Reshetova writes:
> Elena Reshetova (6):
> block: convert bio.__bi_cnt from atomic_t to refcount_t
> block: convert blk_queue_tag.refcnt from atomic_t to refcount_t
> block: convert blkcg_gq.refcnt from atomic_t to refcount_t
> block: convert io_context.active_ref from atomic_t to re
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
Changes in v4:
- Improved commit messages and signoff info.
- Rebase on top of linux-next as of yesterday.
- WARN_ONs are restored since x86 refcount_t does not WARN on zero
Changes in v3:
No changes in patches apart from trivial rebases, but now by
default refcount_t = atomic_t and uses all at
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
37 matches
Mail list logo
