On Mon 22 Feb 2021 at 14:33, Qu Wenruo wrote:
For btree_set_page_dirty(), we should also check the extent
buffer
sanity for subpage support.
Unlike the regular sector size case, since one page can contain
multiple
extent buffers, we need to make sure there is at least one dirty
extent
bu
On Tue, Feb 16, 2021 at 12:46:11PM +0100, David Sterba wrote:
> On Tue, Feb 16, 2021 at 01:33:28PM +0900, Naohiro Aota wrote:
> > On Mon, Feb 15, 2021 at 04:58:05PM +, Johannes Thumshirn wrote:
> > > On 11/02/2021 16:48, David Sterba wrote:
> > > > On Thu, Feb 11, 2021 at 03:26:04PM +, Joha
hi,
Add address output in dax_iomap_pfn() in order to perform a memcpy() in
CoW case. Since this function both output address and pfn, rename it to
dax_iomap_direct_access().
Signed-off-by: Shiyang Ruan
---
fs/dax.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-
For subpage metadata, we don't use page locking at all.
So just skip the page locking part for subpage.
All the remaining routine can be reused.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent_io.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_io.c b/fs
The new function, write_one_subpage_eb(), as a subroutine for subpage
metadata write, will handle the extent buffer bio submission.
The main difference between the new write_one_subpage_eb() and
write_one_eb() is:
- No page locking
When entering write_one_subpage_eb() the page is no longer locke
This patch introduce the following functions to handle btrfs subpage
writeback status:
- btrfs_subpage_set_writeback()
- btrfs_subpage_clear_writeback()
- btrfs_subpage_test_writeback()
Those helpers can only be called when the range is ensured to be
inside the page.
- btrfs_page_set_writeback
The new function, submit_eb_subpage(), will submit all the dirty extent
buffers in the page.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent_io.c | 95
1 file changed, 95 insertions(+)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index edfca
The new function, end_bio_subpage_eb_writepage(), will handle the
metadata writeback endio.
The major difference involved is:
- How to grab extent buffer
Now page::private is a pointer to btrfs_subpage, we can no longer grab
extent buffer directly.
Thus we need to use the bv_offset to locate
This patch introduce the following functions to handle btrfs subpage
dirty status:
- btrfs_subpage_set_dirty()
- btrfs_subpage_clear_dirty()
- btrfs_subpage_test_dirty()
Those helpers can only be called when the range is ensured to be
inside the page.
- btrfs_page_set_dirty()
- btrfs_page_clea
For set_extent_buffer_dirty() to support subpage sized metadata, just
call btrfs_page_set_dirty() to handle both cases.
For clear_extent_buffer_dirty(), it needs to clear the page dirty if and
only if all extent buffers in the page range are no longer dirty.
Also do the same for page error.
This
Current set_btree_ioerr() only accepts @page parameter and grabs extent
buffer from page::private.
This works fine for sector size == PAGE_SIZE case, but not for subpage
case.
Adds an extra parameter, @eb, for callers to pass extent buffer to this
function, so that subpage code can reuse this fun
In alloc_extent_buffer(), we make sure that the newly allocated page is
never dirty.
This is fine for sector size == PAGE_SIZE case, but for subpage it's
possible that one extent buffer in the page is dirty, thus the whole
page is marked dirty, and could cause false alert.
To support subpage, cal
There are quite some assert test on page uptodate in extent buffer write
accessors.
They ensure the destination page is already uptodate.
This is fine for regular sector size case, but not for subpage case, as
for subpage we only mark the page uptodate if the page contains no hole
and all its exte
For btree_set_page_dirty(), we should also check the extent buffer
sanity for subpage support.
Unlike the regular sector size case, since one page can contain multiple
extent buffers, we need to make sure there is at least one dirty extent
buffer in the page.
So this patch will iterate through th
Add a new helper, csum_dirty_subpage_buffers(), to iterate through all
dirty extent buffers in one bvec.
Also extract the code of calculating csum for one extent buffer into
csum_one_extent_buffer(), so that both the existing csum_dirty_buffer()
and the new csum_dirty_subpage_buffers() can reuse t
This patchset can be fetched from the following github repo, along with
the full subpage RW support:
https://github.com/adam900710/linux/tree/subpage
This patchset is for metadata read write support.
[TEST]
Since the data write path is not included in this patchset, we can't
really test it, but d
On Sun, Feb 21, 2021 at 01:45:10AM +0200, Dāvis Mosāns wrote:
> piektd., 2021. g. 19. febr., plkst. 07:16 — lietotājs Chris Murphy
> () rakstīja:
[...]
> > btrfs check -b /dev/
> So I think btrfs check -b --repair should be able to fix most of things.
Why do you think that? If the HBA was failing
On Fri, Feb 19, 2021 at 02:22:01PM +, Matthew Wilcox wrote:
> On Thu, Feb 18, 2021 at 01:27:09PM -0800, Erik Jensen wrote:
> > On 2/18/21 4:15 AM, Matthew Wilcox wrote:
> >
> > > On Thu, Feb 18, 2021 at 04:54:46PM +0800, Qu Wenruo wrote:
> > > > Recently we got a strange bug report that, one 3
On Sat, Feb 20, 2021 at 07:10:14AM +0800, Qu Wenruo wrote:
>
>
> On 2021/2/20 上午12:12, Theodore Ts'o wrote:
> > On Fri, Feb 19, 2021 at 08:37:30AM +0800, Qu Wenruo wrote:
> > > So it means the 32bit archs are already 2nd tier targets for at least
> > > upstream linux kernel?
> >
> > At least as
On Sat, Feb 20, 2021 at 5:26 PM Wang Yugui wrote:
> 1, this warning [*1] is not loged in /var/log/messages
> because it happened after the ro remount of /
>my server is a dell PowerEdge T640, this log can be confirmed by
> iDRAC console.
This is a fair point. The systemd journal is also
The pull request you sent on Thu, 18 Feb 2021 19:33:02 -0800:
> git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/iomap-5.12-merge-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4f016a316f2243efb0d1c0e7259f07817eb99e67
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Tue, 16 Feb 2021 13:56:46 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.12-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6f3952cbe00b74739f540981d1afe84cd4dac879
Thank you!
--
Deet-doot-dot, I am a bot
On Wed, Feb 17, 2021 at 11:44 AM Josef Bacik wrote:
>
> On 2/17/21 11:29 AM, Neal Gompa wrote:
> > On Wed, Feb 17, 2021 at 9:59 AM Josef Bacik wrote:
> >>
> >> On 2/17/21 9:50 AM, Neal Gompa wrote:
> >>> On Wed, Feb 17, 2021 at 9:36 AM Josef Bacik wrote:
>
> On 2/16/21 9:05 PM, Neal Go
Am 21.02.21 um 12:57 schrieb Alexander Wetzel:
While compiling I also switched to
https://github.com/kdave/btrfs-progs.git. Same problem.
I then tracked the error down up to btrfs_uuid_tree_lookup_any():
nr_items is zero after the call
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, &search_arg);
(ret
On Sat, Feb 20, 2021 at 04:01:17PM -0800, Erik Jensen wrote:
> On Sat, Feb 20, 2021 at 3:23 PM Matthew Wilcox wrote:
> > On Sat, Feb 20, 2021 at 03:02:26PM -0800, Erik Jensen wrote:
> > > Out of curiosity, would it be at all feasible to use 64-bits for the page
> > > offset *without* changing XArr
On Fri, Feb 19, 2021 at 05:17:07PM +0100, David Sterba wrote:
> On Thu, Feb 18, 2021 at 02:56:14AM +, Sidong Yang wrote:
> > I found some error when I run unittest code in btrfs-progs.
> > fsck/012-leaf-corruption test corrupt leaf and check that it's recovered.
> > but the test was failed and
While compiling I also switched to
https://github.com/kdave/btrfs-progs.git. Same problem.
I then tracked the error down up to btrfs_uuid_tree_lookup_any():
nr_items is zero after the call
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, &search_arg);
(ret is also zero)
So looks like this is a filesyste
Am 21.02.21 um 07:54 schrieb Andrei Borzenkov:
20.02.2021 20:45, Alexander Wetzel пишет:
# time btrfs receive -v -f test2 .
receiving snapshot 2021-02-20-TEMP
uuid=120113e6-f83c-b240-ba27-259be4c92ea7, ctransid=206769
parent_uuid=d31d553f-0917-3c48-b65c-ec51fd0c6d89, parent_ctransid=195056
...
Dear Qu Wenruo/all
Did this patch ever get accepted?
This is the one which allowed a degraded disk to be RW if it was safe to
do so.
For my use case (2 disk NAS RAID1) this is the one patch I'm waiting for
before upgrading to BTRFS, I suspect I'm not alone.
It would help avoid being locke
29 matches
Mail list logo
