Hello,
We're sorry to have to inform you that your account has been locked for your
security Someone else has had access to your account, and we need to verify a
few information so you could unlock your account and use it again, Please
follow the instructions using the link below:
On Sat, Dec 08, 2018 at 08:50:32AM +0800, Qu Wenruo wrote:
> > I've adapted a stress tests that unpacks a large tarball, snaphosts
> > every 20 seconds, deletes a random snapshot every 50 seconds, deletes
> > file from the original subvolume, now enhanced with qgroups just for the
> > new
On 2018/12/8 上午8:47, David Sterba wrote:
> On Fri, Dec 07, 2018 at 06:51:21AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018/12/7 上午3:35, David Sterba wrote:
>>> On Mon, Nov 12, 2018 at 10:33:33PM +0100, David Sterba wrote:
On Thu, Nov 08, 2018 at 01:49:12PM +0800, Qu Wenruo wrote:
> This
On Fri, Dec 07, 2018 at 06:51:21AM +0800, Qu Wenruo wrote:
>
>
> On 2018/12/7 上午3:35, David Sterba wrote:
> > On Mon, Nov 12, 2018 at 10:33:33PM +0100, David Sterba wrote:
> >> On Thu, Nov 08, 2018 at 01:49:12PM +0800, Qu Wenruo wrote:
> >>> This patchset can be fetched from github:
> >>>
On Thu, Dec 06, 2018 at 04:29:32PM -0800, Omar Sandoval wrote:
> From: Omar Sandoval
>
> I apparently didn't test this on a pre-4.18 kernel.
> test_subvolume_info_unprivileged() checks for an ENOTTY, but this
> doesn't seem to work correctly with subTest().
>
On 6.12.18 г. 8:58 ч., Qu Wenruo wrote:
> 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
I ran that command and I cannot get the email to send properly to the
mailing list as the attachment of the output is over 4.6M.
On 12/7/2018 11:49 AM, Doni Crosby wrote:
The output of the command is attached. This is what errors showed up
on the system:
parent transid verify failed on
I just looked at the VM it does not have a cache. That's the default
in proxmox to improve performance.
On Fri, Dec 7, 2018 at 7:25 AM Austin S. Hemmelgarn
wrote:
>
> On 2018-12-07 01:43, Doni Crosby wrote:
> >> This is qemu-kvm? What's the cache mode being used? It's possible the
> >> usual
From: Filipe Manana
Since cloning and deduplication are no longer Btrfs specific operations, we
now have generic code to handle parameter validation, compare file ranges
used for deduplication, clear capabilities when cloning, etc. This change
makes Btrfs use it, eliminating a lot of code in
On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> From: Josef Bacik
>
> Traditionally we've had voodoo in btrfs to account for the space that
> delayed refs may take up by having a global_block_rsv. This works most
> of the time, except when it doesn't. We've had issues reported and seen
> in
Urgently need money? We can help you!
Are you by the current situation in trouble or threatens you in trouble?
In this way, we give you the ability to take a new development.
As a rich person I feel obliged to assist people who are struggling to give
them a chance. Everyone deserved a second
From: Filipe Manana
Since cloning and deduplication are no longer Btrfs specific operations, we
now have generic code to handle parameter validation, compare file ranges
used for deduplication, clear capabilities when cloning, etc. This change
makes Btrfs use it, eliminating a lot of code in
From: Filipe Manana
Since scrub workers only do memory allocation with GFP_KERNEL when they
need to perform repair, we can move the recent setup of the nofs context
up to scrub_handle_errored_block() instead of setting it up down the call
chain at insert_full_stripe_lock() and
On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> From: Josef Bacik
>
> We use this number to figure out how many delayed refs to run, but
> __btrfs_run_delayed_refs really only checks every time we need a new
> delayed ref head, so we always run at least one ref head completely no
> matter what
On 2018-12-07 01:43, Doni Crosby wrote:
This is qemu-kvm? What's the cache mode being used? It's possible the
usual write guarantees are thwarted by VM caching.
Yes it is a proxmox host running the system so it is a qemu vm, I'm
unsure on the caching situation.
On the note of QEMU and the cache
On 2018-12-06 23:09, Andrei Borzenkov wrote:
06.12.2018 16:04, Austin S. Hemmelgarn пишет:
* On SCSI devices, a discard operation translates to a SCSI UNMAP
command. As pointed out by Ronnie Sahlberg in his reply, this command
is purely advisory, may not result in any actual state change on
On 7.12.18 г. 9:09 ч., Nikolay Borisov wrote:
>
>
> On 6.12.18 г. 19:54 ч., David Sterba wrote:
>> On Thu, Dec 06, 2018 at 06:52:21PM +0200, Nikolay Borisov wrote:
>>>
>>>
>>> On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
Now with the delayed_refs_rsv we can now know exactly how much
Thomas Mohr posted on Thu, 06 Dec 2018 12:31:15 +0100 as excerpted:
> We wanted to convert a file system to a RAID0 with two partitions.
> Unfortunately we had to reboot the server during the balance operation
> before it could complete.
>
> Now following happens:
>
> A mount attempt of the
On 2018/12/7 下午1:24, Doni Crosby wrote:
> All,
>
> I'm coming to you to see if there is a way to fix or at least recover
> most of the data I have from a btrfs filesystem. The system went down
> after both a breaker and the battery backup failed. I cannot currently
> mount the system, with the
On 6.12.18 г. 19:54 ч., David Sterba wrote:
> On Thu, Dec 06, 2018 at 06:52:21PM +0200, Nikolay Borisov wrote:
>>
>>
>> On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
>>> Now with the delayed_refs_rsv we can now know exactly how much pending
>>> delayed refs space we need. This means we can
> This is qemu-kvm? What's the cache mode being used? It's possible the
> usual write guarantees are thwarted by VM caching.
Yes it is a proxmox host running the system so it is a qemu vm, I'm
unsure on the caching situation.
> Old version of progs, I suggest upgrading to 4.17.1 and run
I updated
On Thu, Dec 6, 2018 at 10:24 PM Doni Crosby wrote:
>
> All,
>
> I'm coming to you to see if there is a way to fix or at least recover
> most of the data I have from a btrfs filesystem. The system went down
> after both a breaker and the battery backup failed. I cannot currently
> mount the
All,
I'm coming to you to see if there is a way to fix or at least recover
most of the data I have from a btrfs filesystem. The system went down
after both a breaker and the battery backup failed. I cannot currently
mount the system, with the following error from dmesg:
Note: The vda1 is just
06.12.2018 16:04, Austin S. Hemmelgarn пишет:
>
> * On SCSI devices, a discard operation translates to a SCSI UNMAP
> command. As pointed out by Ronnie Sahlberg in his reply, this command
> is purely advisory, may not result in any actual state change on the
> target device, and is not
On Tue, Nov 27, 2018 at 02:24:41PM +0900, Misono Tomohiro wrote:
> Hello,
>
> This is basically the resend of
> "[PATCH v2 00/20] btrfs-progs: Rework of "subvolume list/show" and relax the
> root privileges of them" [1]
> which I submitted in June. The aim of this series is to allow
From: Omar Sandoval
I apparently didn't test this on a pre-4.18 kernel.
test_subvolume_info_unprivileged() checks for an ENOTTY, but this
doesn't seem to work correctly with subTest().
test_subvolume_iterator_unprivileged() doesn't have a check at all. Add
an explicit check to both before doing
On 2018/12/7 上午7:15, Michael Wade wrote:
> Hi Qu,
>
> Me again! Having formatted the drives and rebuilt the RAID array I
> seem to have be having the same problem as before (no power cut this
> time [I bought a UPS]).
But strangely, your super block shows it has log tree, which means
either
On 2018/12/7 上午3:35, David Sterba wrote:
> On Mon, Nov 12, 2018 at 10:33:33PM +0100, David Sterba wrote:
>> On Thu, Nov 08, 2018 at 01:49:12PM +0800, Qu Wenruo wrote:
>>> This patchset can be fetched from github:
>>> https://github.com/adam900710/linux/tree/qgroup_delayed_subtree_rebased
>>>
>>>
On Thu, 6 Dec 2018, Johannes Thumshirn wrote:
> On 05/12/2018 15:46, Julia Lawall wrote:
> [...]
> >> +@r_patch depends on !context && patch && !org && !report@
> >> +expression E;
> >> +type T;
> >> +@@
> >> +
> >> +(
> >> +- E & ~PAGE_MASK
> >> ++ offset_in_page(E)
> >> +|
> >> +- E &
On Mon, Nov 12, 2018 at 10:33:33PM +0100, David Sterba wrote:
> On Thu, Nov 08, 2018 at 01:49:12PM +0800, Qu Wenruo wrote:
> > This patchset can be fetched from github:
> > https://github.com/adam900710/linux/tree/qgroup_delayed_subtree_rebased
> >
> > Which is based on v4.20-rc1.
>
> Thanks,
On Wed, Dec 05, 2018 at 12:12:21PM -0500, 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
On Fri, Nov 30, 2018 at 12:19:18PM -0500, Josef Bacik wrote:
> On Fri, Nov 30, 2018 at 05:14:54PM +, Filipe Manana wrote:
> > On Fri, Nov 30, 2018 at 4:53 PM Josef Bacik wrote:
> > >
> > > From: Josef Bacik
> > >
> > > When debugging some weird extent reference bug I suspected that we were
>
On Thu, Dec 06, 2018 at 06:52:21PM +0200, Nikolay Borisov wrote:
>
>
> On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> > Now with the delayed_refs_rsv we can now know exactly how much pending
> > delayed refs space we need. This means we can drastically simplify
>
> IMO it will be helpful if
On 05/12/2018 15:46, Julia Lawall wrote:
[...]
>> +@r_patch depends on !context && patch && !org && !report@
>> +expression E;
>> +type T;
>> +@@
>> +
>> +(
>> +- E & ~PAGE_MASK
>> ++ offset_in_page(E)
>> +|
>> +- E & (PAGE_SIZE - 1)
>> ++ offset_in_page(E)
>
> The two lines above should be
On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> Now with the delayed_refs_rsv we can now know exactly how much pending
> delayed refs space we need. This means we can drastically simplify
IMO it will be helpful if there is a sentence here referring back to
btrfs_update_delayed_refs_rsv to put
On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> Over the years we have built up a lot of infrastructure to keep delayed
> refs in check, mostly by running them at btrfs_end_transaction() time.
> We have a lot of different maths we do to figure out how much, if we
> should do it inline or async,
On Mon, Dec 03, 2018 at 10:20:28AM -0500, Josef Bacik wrote:
> v1->v2:
> - addressed the comments from the various reviewers.
> - split "introduce delayed_refs_rsv" into 5 patches. The patches are the same
> together as they were, just split out more logically. They can't really be
>
On Wed, Dec 05, 2018 at 03:23:02PM +0100, Johannes Thumshirn wrote:
> 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
On 2018-12-06 01:11, Robert White wrote:
(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
On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> Any space used in the delayed_refs_rsv will be freed up by a transaction
> commit, so instead of just counting the pinned space we also need to
> account for any space in the delayed_refs_rsv when deciding if it will
> make a different to commit the
On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> From: Josef Bacik
>
> We were missing some quota cleanups in check_ref_cleanup, so break the
> ref head accounting cleanup into a helper and call that from both
> check_ref_cleanup and cleanup_ref_head. This will hopefully ensure that
> we don't
On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> From: Josef Bacik
>
> We do this dance in cleanup_ref_head and check_ref_cleanup, unify it
> into a helper and cleanup the calling functions.
>
> Signed-off-by: Josef Bacik
> Reviewed-by: Omar Sandoval
Reviewed-by: Nikolay Borisov
> ---
>
On 11:07 06/12, Johannes Thumshirn wrote:
> On 05/12/2018 13: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
On 6:52 05/12, Christoph Hellwig wrote:
> If you want to export these at all they have to be EXPORT_SYMBOL_GPL.
>
Understood.
> 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.
This is not
Dear developers of BTRFS,
we have a problem. We wanted to convert a file system to a RAID0 with
two partitions. Unfortunately we had to reboot the server during the
balance operation before it could complete.
Now following happens:
A mount attempt of the array fails with following error
On 05/12/2018 13: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
>
Hi,
I am more of a SCSI guy than ATA so forgive where I am ignorant.
The SCSI equivalent to TRIM is called UNMAP.
UNMAP is unfortunately only a "hint" to the device so if the device
for any reason
is busy, it can just do a NO-OP, leave the data as is and still
return status SUCCESS.
That is
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
1 - 100 of 77199 matches
Mail list logo
