Dear Rider,
RED Racing Parts offers the new full line of carbon fiber parts for your
motorbike.
For road / offroad motorcycles, visit our website on
https://www.redracingparts.com/english/motorbikesmotorcycles/productsandcomponents/general/intro/carbonfibrefiber.php
For trial motorcycles,
On 12/5/18 9:37 PM, Jeff Mahoney wrote:
The high level idea that Jan Kara and I came up with in our conversation
at Labs conf is pretty expensive. We'd need to set a flag that pauses
new page faults, set the WP bit on affected ranges, do the snapshot,
commit, clear the flag, and wake up the
Just like btrfs_add_delayed_tree_ref(), use btrfs_ref to refactor
btrfs_add_delayed_data_ref().
Signed-off-by: Qu Wenruo
---
fs/btrfs/delayed-ref.c | 19 +--
fs/btrfs/delayed-ref.h | 8 +++-
fs/btrfs/extent-tree.c | 24 +++-
3 files changed, 27
Similar to btrfs_inc_extent_ref(), just use btrfs_ref to replace the
long parameter list and the confusing @owner parameter.
Signed-off-by: Qu Wenruo
---
fs/btrfs/ctree.h | 5 +---
fs/btrfs/extent-tree.c | 53 ++
fs/btrfs/file.c| 23
The process_func is never a function hook used anywhere else.
Open code it to make later delayed ref refactor easier, so we can
refactor btrfs_inc_extent_ref() and btrfs_free_extent() in different
patches.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent-tree.c | 33
Now we don't need to play the dirty game of reusing @owner for tree block
level.
Signed-off-by: Qu Wenruo
---
fs/btrfs/ctree.h | 6 ++---
fs/btrfs/extent-tree.c | 58 ++
fs/btrfs/file.c| 20 ++-
fs/btrfs/inode.c | 10
It's a perfect match for btrfs_ref_tree_mod() to use btrfs_ref, as
btrfs_ref describes a metadata/data reference update comprehensively.
Now we have one less function use confusing owner/level trick.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent-tree.c | 27 +++--
btrfs_add_delayed_tree_ref() has a longer and longer parameter list, and
some caller like btrfs_inc_extent_ref() are using @owner as level for
delayed tree ref.
Instead of making the parameter list longer and longer, use btrfs_ref to
refactor it, so each parameter assignment should be
Current delayed ref interface has several problems:
- Longer and longer parameter lists
bytenr
num_bytes
parent
ref_root
owner
offset
for_reloc << Only qgroup code cares.
- Different interpretation for the same parameter
Above @owner for data ref is ino owning this extent,
while
Since add_pinned_bytes() only needs to know if the extent is metadata
and if it's a chunk tree extent, btrfs_ref is a perfect match for it, as
we don't need various owner/level trick to determine extent type.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent-tree.c | 26 ++
1
Current delayed ref interface has several problems:
- Longer and longer parameter lists
bytenr
num_bytes
parent
So far so good
ref_root
owner
offset
I don't feel well now
for_reloc
This parameter only makes sense for qgroup code, but we need
to pass the
On Thu, 6 Dec 2018 06:11:46 +
Robert White wrote:
> So it would be dog-slow, but it would be neat if BTRFS had a mount
> option to convert any TRIM command from above into the write of a zero,
> 0xFF, or trash block to the device below if that device doesn't support
> TRIM. Real TRIM
(1) Automatic and selective wiping of unused and previously used disk
blocks is a good security measure, particularly when there is an
encryption layer beneath the file system.
(2) USB attached devices _never_ support TRIM and they are the most
likely to fall into strangers hands.
(3) I
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooperation. I got your contact from an email database from your country. I
have a financial transaction i would like to discuss with you. Please reply to
reem2...@daum.net, for more details if you are
On 12/5/18 7:28 AM, Goldwyn Rodrigues wrote:
This is a support for DAX in btrfs. I understand there have been
previous attempts at it. However, I wanted to make sure copy-on-write
(COW) works on dax as well.
Before I present this to the FS folks I wanted to run this through the
btrfs. Even
On 12/5/18 8:03 AM, Qu Wenruo wrote:
On 2018/12/5 下午8:28, Goldwyn Rodrigues wrote:
This is a support for DAX in btrfs. I understand there have been
previous attempts at it. However, I wanted to make sure copy-on-write
(COW) works on dax as well.
Before I present this to the FS folks I wanted
On Wed, Dec 5, 2018 at 5:14 PM Josef Bacik wrote:
>
> From: Josef Bacik
>
> With my delayed refs patches in place we started seeing a large amount
> of aborts in __btrfs_free_extent
>
> BTRFS error (device sdb1): unable to find ref byte nr 91947008 parent 0 root
> 35964 owner 1 offset 0
> Call
On 2018-12-05 14:50, Roman Mamedov wrote:
Hello,
To migrate my FS to a different physical disk, I have added a new empty device
to the FS, then ran the remove operation on the original one.
Now my FS has only devid 2:
Label: 'p1' uuid: d886c190-b383-45ba-9272-9f00c6a10c50
Total
Hello,
To migrate my FS to a different physical disk, I have added a new empty device
to the FS, then ran the remove operation on the original one.
Now my FS has only devid 2:
Label: 'p1' uuid: d886c190-b383-45ba-9272-9f00c6a10c50
Total devices 1 FS bytes used 36.63GiB
devid
On 5 Dec 2018, at 5:59, Andrea Gelmini wrote:
> On Tue, Dec 04, 2018 at 10:29:49PM +, Chris Mason wrote:
>> I think (hope) this is:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=201685
>>
>> Which was just nailed down to a blkmq bug. It triggers when you have
>> scsi devices using
From: Josef Bacik
With my delayed refs patches in place we started seeing a large amount
of aborts in __btrfs_free_extent
BTRFS error (device sdb1): unable to find ref byte nr 91947008 parent 0 root
35964 owner 1 offset 0
Call Trace:
? btrfs_merge_delayed_refs+0xaf/0x340
On Mon, Dec 03, 2018 at 12:25:32PM +0200, Nikolay Borisov wrote:
> When extent_readpages is called from the generic readahead code it first
> builds a batch of 16 pages (which might or might not be consecutive,
> depending on whether add_to_page_cache_lru failed) and submits them to
>
On Wed, Nov 21, 2018 at 05:10:52PM +0200, Nikolay Borisov wrote:
> Running btrfs/124 in a loop hung up on me sporadically with the
> following call trace:
> btrfs D0 5760 5324 0x
> Call Trace:
>? __schedule+0x243/0x800
>schedule+0x33/0x90
>
On Wed, Dec 05, 2018 at 02:43:03PM +0200, Nikolay Borisov wrote:
> One question below though .
>
> > +++ b/fs/btrfs/super.c
> > @@ -739,6 +741,17 @@ int btrfs_parse_options(struct btrfs_fs_info *info,
> > char *options,
> > case Opt_user_subvol_rm_allowed:
> >
If you want to export these at all they have to be EXPORT_SYMBOL_GPL.
But I'd really like to avoid seeing another duplicate DAX I/O path.
Please try to adopt the existing iomap-based infrastructure for your
needs first.
On Wed, 5 Dec 2018, Johannes Thumshirn wrote:
> Constructs like 'var & (PAGE_SIZE - 1)' or 'var & ~PAGE_MASK' can be
> replaced by the offset_in_page() macro instead of open-coding it.
>
> Add a coccinelle semantic patch to ease detection and conversion of these.
>
> This unfortunately doesn't
Hello
Is it correct way to fix this issue as add max retry count
https://github.com/kdave/btrfs-progs/pull/151/files
I have added max retry count ? is it correct way to fix this ?
Thanks
AK
On 5.12.18 г. 16:23 ч., Johannes Thumshirn wrote:
> Constructs like 'var & (PAGE_SIZE - 1)' or 'var & ~PAGE_MASK' can denote an
> offset into a page.
>
> So replace them by the offset_in_page() macro instead of open-coding it if
> they're not used as an alignment check.
>
> Signed-off-by:
On 5.12.18 г. 16:23 ч., Johannes Thumshirn wrote:
> When using a 'var & (PAGE_SIZE - 1)' construct one is checking for a page
> alignment and thus should use the PAGE_ALIGNED() macro instead of
> open-coding it.
>
> Convert all open-coded occurrences of PAGE_ALIGNED().
>
> Signed-off-by:
Constructs like 'var & (PAGE_SIZE - 1)' or 'var & ~PAGE_MASK' can denote an
offset into a page.
So replace them by the offset_in_page() macro instead of open-coding it if
they're not used as an alignment check.
Signed-off-by: Johannes Thumshirn
---
fs/btrfs/check-integrity.c | 12 +--
Constructs like 'var & (PAGE_SIZE - 1)' or 'var & ~PAGE_MASK' can be
replaced by the offset_in_page() macro instead of open-coding it.
Add a coccinelle semantic patch to ease detection and conversion of these.
This unfortunately doesn't account for the case when we want PAGE_ALIGNED()
instead of
Use the offset_in_page() and PAGE_ALIGNED() macros instead of open-coding them
throughout btrfs.
This series also includes a patch for 'make coccicheck' which is marked as an
RFC and I've CCed Julia in the hoping to get input from her.
Johannes Thumshirn (3):
btrfs: use offset_in_page instead
When using a 'var & (PAGE_SIZE - 1)' construct one is checking for a page
alignment and thus should use the PAGE_ALIGNED() macro instead of
open-coding it.
Convert all open-coded occurrences of PAGE_ALIGNED().
Signed-off-by: Johannes Thumshirn
---
fs/btrfs/check-integrity.c | 8
Hi,
btrfs-progs version 4.19.1 have been released. There are build fixes, minor
update to libbtrfsutil and documentation updates.
Changes since 4.19.1-rc1: fix typos in CHANGES
Changes:
* build fixes
* big-endian builds fail due to bswap helper clashes
* 'swap' macro is too generic,
On 2018/12/5 下午9:40, David Sterba wrote:
> On Wed, Dec 05, 2018 at 02:40:12PM +0800, Qu Wenruo wrote:
>> GCC 8.2.1 will report the following warning with "make W=1":
>>
>> ctree.c: In function 'btrfs_next_sibling_tree_block':
>> ctree.c:2990:21: warning: 'slot' may be used uninitialized in
On 05/12/2018 13:28, Goldwyn Rodrigues wrote:
[...]
> -static void *grab_mapping_entry(struct xa_state *xas,
> +void *grab_mapping_entry(struct xa_state *xas,
> struct address_space *mapping, unsigned long size_flag)
> {
> unsigned long index = xas->xa_index;
> @@ -531,6
On Wed, Dec 05, 2018 at 06:28:25AM -0600, Goldwyn Rodrigues wrote:
> This is a support for DAX in btrfs.
Yay!
> I understand there have been previous attempts at it. However, I wanted
> to make sure copy-on-write (COW) works on dax as well.
btrfs' usual use of CoW and DAX are thoroughly in
On 05/12/2018 13:28, Goldwyn Rodrigues wrote:
[...]
> +static int copy_extent_page(struct extent_map *em, void *daddr, u64 pos)
> +{
> +struct dax_device *dax_dev;
^ space instead of tabs?
> + void *saddr;
> + sector_t start;
> + size_t len;
> +
> + if (em->block_start
On Wed, Dec 05, 2018 at 02:40:12PM +0800, Qu Wenruo wrote:
> GCC 8.2.1 will report the following warning with "make W=1":
>
> ctree.c: In function 'btrfs_next_sibling_tree_block':
> ctree.c:2990:21: warning: 'slot' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>
On 5.12.18 г. 14:28 ч., Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Since we will be using it in another part of the code, use a
> better name to declare it non-static
>
> Signed-off-by: Goldwyn Rodrigues
> ---
> fs/btrfs/ctree.h | 7 +--
> fs/btrfs/inode.c | 14
On 5.12.18 г. 14:28 ч., Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Signed-off-by: Goldwyn Rodrigues
> ---
> fs/btrfs/dax.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/dax.c b/fs/btrfs/dax.c
> index d614bf73bf8e..5a297674adec 100644
>
On 05/12/2018 13:28, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Signed-off-by: Goldwyn Rodrigues
Can you explain why we can't use th dax_iomap_rw() interface like XFS or
EXT4?
[...]
> +static ssize_t em_dax_rw(struct inode *inode, struct extent_map *em, u64 pos,
> +
On 5.12.18 г. 14:28 ч., Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Signed-off-by: Goldwyn Rodrigues
> ---
> fs/btrfs/Makefile | 1 +
> fs/btrfs/ctree.h | 5
> fs/btrfs/dax.c| 68
> +++
> fs/btrfs/file.c | 13
On 2018/12/5 下午8:28, Goldwyn Rodrigues wrote:
> This is a support for DAX in btrfs. I understand there have been
> previous attempts at it. However, I wanted to make sure copy-on-write
> (COW) works on dax as well.
>
> Before I present this to the FS folks I wanted to run this through the
>
On 5.12.18 г. 14:28 ч., Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Also, set the inode->i_flags to S_DAX
>
> Signed-off-by: Goldwyn Rodrigues
Reviewed-by: Nikolay Borisov
One question below though .
> ---
> fs/btrfs/ctree.h | 1 +
> fs/btrfs/ioctl.c | 5 -
>
On 05/12/2018 13:28, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Also, set the inode->i_flags to S_DAX
>
> Signed-off-by: Goldwyn Rodrigues
> ---
> fs/btrfs/ctree.h | 1 +
> fs/btrfs/ioctl.c | 5 -
> fs/btrfs/super.c | 15 +++
> 3 files changed, 20 insertions(+),
From: Goldwyn Rodrigues
Create a page size extent and copy the contents of the original
extent into the new one, and present to user space as the page
to write.
Signed-off-by: Goldwyn Rodrigues
---
fs/btrfs/dax.c | 39 +++
1 file changed, 39 insertions(+)
From: Goldwyn Rodrigues
This is a combination of direct and buffered I/O. Similarties
with direct I/O is that it needs to allocate space before
writing. Similarities with buffered is when the data is not
page-aligned, it needs to copy parts of the previous extents. In
order to accomplish that,
From: Goldwyn Rodrigues
Signed-off-by: Goldwyn Rodrigues
---
fs/btrfs/dax.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/dax.c b/fs/btrfs/dax.c
index 88017f8799d1..6d68d39cc5da 100644
--- a/fs/btrfs/dax.c
+++ b/fs/btrfs/dax.c
@@
From: Goldwyn Rodrigues
These functions are required for btrfs dax support.
Signed-off-by: Goldwyn Rodrigues
---
fs/dax.c| 35 ---
include/linux/dax.h | 16
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/fs/dax.c
From: Goldwyn Rodrigues
Signed-off-by: Goldwyn Rodrigues
---
fs/btrfs/dax.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/dax.c b/fs/btrfs/dax.c
index d614bf73bf8e..5a297674adec 100644
--- a/fs/btrfs/dax.c
+++ b/fs/btrfs/dax.c
@@ -54,7 +54,12 @@ ssize_t
This is a support for DAX in btrfs. I understand there have been
previous attempts at it. However, I wanted to make sure copy-on-write
(COW) works on dax as well.
Before I present this to the FS folks I wanted to run this through the
btrfs. Even though I wish, I cannot get it correct the first
From: Goldwyn Rodrigues
Also, set the inode->i_flags to S_DAX
Signed-off-by: Goldwyn Rodrigues
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/ioctl.c | 5 -
fs/btrfs/super.c | 15 +++
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
From: Goldwyn Rodrigues
Since we will be using it in another part of the code, use a
better name to declare it non-static
Signed-off-by: Goldwyn Rodrigues
---
fs/btrfs/ctree.h | 7 +--
fs/btrfs/inode.c | 14 +-
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git
From: Goldwyn Rodrigues
Signed-off-by: Goldwyn Rodrigues
---
fs/btrfs/Makefile | 1 +
fs/btrfs/ctree.h | 5
fs/btrfs/dax.c| 68 +++
fs/btrfs/file.c | 13 ++-
4 files changed, 86 insertions(+), 1 deletion(-)
create mode
From: Goldwyn Rodrigues
Signed-off-by: Goldwyn Rodrigues
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/dax.c | 43 +++
fs/btrfs/file.c | 12 +++-
3 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index
From: Goldwyn Rodrigues
This makes btrfs_get_extent_map_write() independent of Direct
I/O code.
Signed-off-by: Goldwyn Rodrigues
---
fs/btrfs/ctree.h | 2 ++
fs/btrfs/inode.c | 40 +++-
2 files changed, 29 insertions(+), 13 deletions(-)
diff --git
On Tue, Dec 04, 2018 at 10:29:49PM +, Chris Mason wrote:
> I think (hope) this is:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=201685
>
> Which was just nailed down to a blkmq bug. It triggers when you have
> scsi devices using elevator=none over blkmq.
Thanks a lot Chris. Really.
The first step fo the rebalance process, ensuring there is 1mb free on
each device. This number seems rather small. And in fact when talking
to the original authors their opinions were:
"man that's a little bonkers"
"i don't think we even need that code anymore"
"I think it was there to make sure
59 matches
Mail list logo
