Gentle ping?
Any comment on this?
Thanks,
Qu
On 2019/2/27 下午2:05, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/btrfs-progs/tree/file_extents_fixes
>
> This is based on v4.20.2 tag.
>
> Originally for fsck-tests/001-bad-file-extent-bytenr we're go
For kernel operation we have METADATA/FUA/FLUSH flags as a beacon, but
for user space write we don't have any useful flag unless the user space
tool call fsync() to generate a FLUSH bio.
This means for user space write, we don't really have an equivalent of
--next-fua to find super block write.
S
Hello this is Mr Wong again from hongkong,Can we send the Swift as discuss best
regards.
Mr Wong Cheng
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
On 2019/3/28 上午12:02, David Sterba wrote:
> The commit fcebe4562dec ("Btrfs: rework qgroup accounting") reworked
> qgroups and added some new structures. Another rework of qgroup
> mechanics e69bcee37692 ("btrfs: qgroup: Cleanup the old
> ref_node-oriented mechanism.") stopped using them and left
On 5:00 27/03, Matthew Wilcox wrote:
> On Wed, Mar 27, 2019 at 06:00:52AM -0500, Goldwyn Rodrigues wrote:
> > On 12:10 26/03, Matthew Wilcox wrote:
> > > On Tue, Mar 26, 2019 at 02:02:47PM -0500, Goldwyn Rodrigues wrote:
> > > > This sets S_DAX in inode->i_flags, which can be used with
> > > > IS_
On 21:14 27/03, Adam Borowski wrote:
> On Tue, Mar 26, 2019 at 02:09:08PM -0500, Goldwyn Rodrigues wrote:
> > This patch set adds support for dax on the BTRFS filesystem.
>
> This patchset doesn't seem to support MAP_SYNC, which is the usual way to
> use (and detect) DAX. Basically, it requests f
On 26.03.2019 14:37 Qu Wenruo wrote:
> On 2019/3/26 下午6:24, berodual_xyz wrote:
>> Mount messages below.
>>
>> Thanks for your input, Qu!
>>
>> ##
>> [42763.884134] BTRFS info (device sdd): disabling free space tree
>> [42763.884138] BTRFS info (device sdd): force clearing of disk cache
>> [42763.8
On Tue, Mar 26, 2019 at 02:09:08PM -0500, Goldwyn Rodrigues wrote:
> This patch set adds support for dax on the BTRFS filesystem.
This patchset doesn't seem to support MAP_SYNC, which is the usual way to
use (and detect) DAX. Basically, it requests for page faults to be
synchronous -- ie, when a
Thanks for the extensive answer, Chris!
> a. Check with the manufacturer of the hardware raid for firmware
> updates for all the controllers. Also check if the new version is
> backward compatible with an array made with the version you have, and
> if not, if downgrade is possible. That way you h
On Tue, Mar 26, 2019 at 10:37:06PM -0400, Zygo Blaxell wrote:
> On Tue, Mar 19, 2019 at 11:39:59PM -0400, Zygo Blaxell wrote:
> > I haven't been able to easily reproduce these in a test environment;
> > however, they have been happening several times a year on servers in
> > production.
> >
> > Ke
Removing Andrei and Qu.
On Wed, Mar 27, 2019 at 12:52 PM Chris Murphy wrote:
>
> And then also in the meantime, prepare for having to rebuild this array.
a. Check with the manufacturer of the hardware raid for firmware
updates for all the controllers. Also check if the new version is
backward co
On 10:54 27/03, Darrick J. Wong wrote:
> On Tue, Mar 26, 2019 at 02:02:50PM -0500, Goldwyn Rodrigues wrote:
> > From: Goldwyn Rodrigues
> >
> > The IOMAP_F_COW is a flag to notify dax that it needs to copy
> > the data from iomap->cow_addr to iomap->addr, if the start/end
> > of I/O are not page
On Wed, Mar 27, 2019 at 7:03 AM berodual_xyz
wrote:
> My questions now:
>
> * what is the chance of "btrfs rescue" "chunk-recover" / "super-recover" /
> "zero-log" having a positive effect on the filesystem.
>
> * what is the chance of "btrfs check --init-extent-tree" fixing the described
> issu
On Tue, Mar 26, 2019 at 02:02:50PM -0500, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> The IOMAP_F_COW is a flag to notify dax that it needs to copy
> the data from iomap->cow_addr to iomap->addr, if the start/end
> of I/O are not page aligned.
>
> This also introduces dax_to_dax_copy(
On Tue, Mar 26, 2019 at 12:10:01PM -0700, Matthew Wilcox wrote:
> On Tue, Mar 26, 2019 at 02:02:47PM -0500, Goldwyn Rodrigues wrote:
> > The dax option is restricted to non multi-device mounts.
> > dax interacts with the device directly instead of using bio, so
> > all bio-hooks which we use for mu
On Tue, Mar 12, 2019 at 05:20:24PM +0200, Nikolay Borisov wrote:
> @@ -1190,45 +1201,71 @@ static int cow_file_range_async(struct inode *inode,
> struct page *locked_page,
> unsigned int write_flags)
> {
> struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
The commit fcebe4562dec ("Btrfs: rework qgroup accounting") reworked
qgroups and added some new structures. Another rework of qgroup
mechanics e69bcee37692 ("btrfs: qgroup: Cleanup the old
ref_node-oriented mechanism.") stopped using them and left uncleaned.
Signed-off-by: David Sterba
---
fs/bt
Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh,
hello dear
I came across your contact during my private search. Mrs Aisha Al-
Qaddafi is my name, the only daughter of late Libyan president, am a
single Mother and a Widow with three Children.I have funds the sum of
$27.5 million USD for, investme
On 2019/3/27 下午10:07, Adam Borowski wrote:
> On Wed, Mar 27, 2019 at 05:46:50PM +0800, Qu Wenruo wrote:
>> This urgent patchset can be fetched from github:
>> https://github.com/adam900710/btrfs-progs/tree/flush_super
>> Which is based on v4.20.2.
>>
>> Before this patch, btrfs-progs writes to th
On 2019/3/27 下午10:39, Qu Wenruo wrote:
>
>
> On 2019/3/27 下午10:07, Adam Borowski wrote:
>> On Wed, Mar 27, 2019 at 05:46:50PM +0800, Qu Wenruo wrote:
>>> This urgent patchset can be fetched from github:
>>> https://github.com/adam900710/btrfs-progs/tree/flush_super
>>> Which is based on v4.20.2
On 2019/3/27 下午10:07, Adam Borowski wrote:
> On Wed, Mar 27, 2019 at 05:46:50PM +0800, Qu Wenruo wrote:
>> This urgent patchset can be fetched from github:
>> https://github.com/adam900710/btrfs-progs/tree/flush_super
>> Which is based on v4.20.2.
>>
>> Before this patch, btrfs-progs writes to th
On Wed, Mar 27, 2019 at 03:07:48PM +0100, Adam Borowski wrote:
> On Wed, Mar 27, 2019 at 05:46:50PM +0800, Qu Wenruo wrote:
> > This urgent patchset can be fetched from github:
> > https://github.com/adam900710/btrfs-progs/tree/flush_super
> > Which is based on v4.20.2.
> >
> > Before this patch,
On Wed, Mar 27, 2019 at 05:46:50PM +0800, Qu Wenruo wrote:
> This urgent patchset can be fetched from github:
> https://github.com/adam900710/btrfs-progs/tree/flush_super
> Which is based on v4.20.2.
>
> Before this patch, btrfs-progs writes to the fs has no barrier at all.
> All metadata and supe
Dear Chris,
correct - the metadata profile was set to single (with the thought of
consolidating metadata updates to a smaller subset of disks instead of creating
IO overhead between "data" operations and "metadata" updates).
It seems that "-o clear_cache" was used early on in an attempt to fix
On 5:00 27/03, Matthew Wilcox wrote:
> On Wed, Mar 27, 2019 at 06:00:52AM -0500, Goldwyn Rodrigues wrote:
> > On 12:10 26/03, Matthew Wilcox wrote:
> > > On Tue, Mar 26, 2019 at 02:02:47PM -0500, Goldwyn Rodrigues wrote:
> > > > This sets S_DAX in inode->i_flags, which can be used with
> > > > IS_
btrfs_device structs are freed from RCU context since device iteration
is protected by RCU. Currently this is achieved by using call_rcu since
no blocking functions are called within btrfs_free_device. Future
refactoring of pending/pinned chunks will require calling sleeping
functions. This patch i
Now that those function no longer require a handle to transaction to
inspect pending/pinned chunks the argument can be removed. At the same
time also remove any surrounding code which acquired the handle.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 36 +++-
This function is very similar to find_first_extent_bit except that it
locates the first contiguous span of space which does not have bits set.
It's intended use is in the freespace trimming code.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 73 +++
Instead of always calling the allocator to search for a free extent,
that satisfies the input criteria, switch btrfs_trim_free_extents to
using find_first_clear_extent_bit. With this change it's no longer
necessary to read the device tree in order to figure out holes in
the devices.
Now the code a
It will be used in a future patch that will require modifying an
extent_io_tree struct under a spinlock.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 7 +++
fs/btrfs/extent_io.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
in
Currently unallocated chunks are always trimmed. For example
2 consecutive trims on large storage would trim freespace twice
irrespective of whether the space was actually allocated or not between
those trims.
Optimise this behavior by exploiting the newly introduced alloc_state
tree of btrfs_devi
From: Jeff Mahoney
The pending chunks list contains chunks that are allocated in the
current transaction but haven't been created yet. The pinned chunks
list contains chunks that are being released in the current transaction.
Both describe chunks that are not reflected on disk as in use but are
u
Here is the (hopefully final) v4 of the fitrim patches. Main changes since v3:
* Fixed leaked btrfs_path in patch 3.
* Fixed multiple assignemnt on single line in patch 3.
* New patch 9 transposing btrfs_close_devices/btrfs_mapping_tree_free, in v3
this change was wrongly squashed in patch "Intr
During device shrink pinned/pending chunks (i.e those which have been
deleted/created respectively, in the current transaction and haven't
touched disk) need to be accounted when doing device shrink. Presently
this happens after the main relocation loop in btrfs_shrink_device,
which could lead to m
This function is going to be used to clear out the device extent
allocation information. Give it a more generic name and export it. This
is in preparation to replacing the pending/pinned chunk lists with an
extent tree. No functional changes.
Reviewed-by: David Sterba
Signed-off-by: Nikolay Boris
We currently overload the pending_chunks list to handle updating
btrfs_device->commit_bytes used. We don't actually care about
the extent mapping or even the device mapping for the chunk - we
just need the device, and we can end up processing it multiple
times. The fs_devices->resized_list does m
Following the introduction of the alloc_state tree, some of the callees
of btrfs_mapping_tree_free will have to interact with the btrfs_device
of the constituent devices. Enable this by moving the code responsible
for freeing devices after the last user (btrfs_mapping_tree_free).
Otherwise the kern
This is used in more than one places so let's factor it out in ctree.h.
No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 2 ++
fs/btrfs/extent-tree.c | 1 -
fs/btrfs/volumes.c | 1 -
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ctr
Chunks read from disk currently don't get their ->orig_block_len member
set, in contrast when a new chunk is allocated, the respective
extent_map's ->orig_block_len is assigned the size of the stripe of this
chunk. Let's apply the same strategy for chunks which are read from
disk, not only does thi
Rather than hijacking the existing defines let's just define new bits,
with more descriptive names. Instead of using yet more (currently at 18)
bits for the new flags, use the fact those flags will be specific to
the device allocation tree so define them using existing EXTENT_* flags.
Signed-off-b
Up until know trimming the freespace was done irrespective of what the
arguments of the FITRIM ioctl were. For example fstrim's -o/-l arguments
will be entirely ignored. Fix it by correctly handling those paramter.
This requires breaking if the found freespace extent is after the end
of the passed
On Wed, Mar 27, 2019 at 06:00:52AM -0500, Goldwyn Rodrigues wrote:
> On 12:10 26/03, Matthew Wilcox wrote:
> > On Tue, Mar 26, 2019 at 02:02:47PM -0500, Goldwyn Rodrigues wrote:
> > > This sets S_DAX in inode->i_flags, which can be used with
> > > IS_DAX().
> > >
> > > The dax option is restricted
On 27.03.19 г. 11:46 ч., Qu Wenruo wrote:
> When we failed to write super blocks, we just output something like:
> WARNING: failed to write sb: I/O error
> Or
> WARNING: failed to write all sb data
>
> There is no info about which device failed and there are two different
> error message fo
On 12:36 26/03, Dan Williams wrote:
> On Wed, Dec 5, 2018 at 4:29 AM Goldwyn Rodrigues wrote:
> >
> > From: Goldwyn Rodrigues
> >
> > These functions are required for btrfs dax support.
> >
> > Signed-off-by: Goldwyn Rodrigues
> > ---
> > fs/dax.c| 35 ---
On 12:10 26/03, Matthew Wilcox wrote:
> On Tue, Mar 26, 2019 at 02:02:47PM -0500, Goldwyn Rodrigues wrote:
> > This sets S_DAX in inode->i_flags, which can be used with
> > IS_DAX().
> >
> > The dax option is restricted to non multi-device mounts.
> > dax interacts with the device directly instead
When we failed to write super blocks, we just output something like:
WARNING: failed to write sb: I/O error
Or
WARNING: failed to write all sb data
There is no info about which device failed and there are two different
error message for the same write error.
This patch will change it to somet
[BUG]
There are tons of reports of btrfs-progs screwing up the fs, the most
recent one is "btrfs check --clear-space-cache v1" triggered BUG_ON()
and then leaving the fs with transid mismatch problem.
[CAUSE]
In kernel, we have block layer handing the flush work, even on devices
without FUA suppor
This urgent patchset can be fetched from github:
https://github.com/adam900710/btrfs-progs/tree/flush_super
Which is based on v4.20.2.
Before this patch, btrfs-progs writes to the fs has no barrier at all.
All metadata and superblock are just buffered write, no barrier between
super blocks and met
On 2019/3/27 下午4:37, Nikolay Borisov wrote:
>
>
> On 27.03.19 г. 9:25 ч., Qu Wenruo wrote:
>> [BUG]
>> There are tons of reports of btrfs-progs screwing up the fs, the most
>> recent one is "btrfs check --clear-space-cache v1" triggered BUG_ON()
>> and then leaving the fs with transid mismatch p
On 27.03.19 г. 9:25 ч., Qu Wenruo wrote:
> [BUG]
> There are tons of reports of btrfs-progs screwing up the fs, the most
> recent one is "btrfs check --clear-space-cache v1" triggered BUG_ON()
> and then leaving the fs with transid mismatch problem.
>
> [CAUSE]
> In kernel, we have block layer
On 2019/3/27 下午4:00, Nikolay Borisov wrote:
>
>
> On 27.03.19 г. 9:24 ч., Qu Wenruo wrote:
>> When we failed to write super blocks, we just output something like:
>> WARNING: failed to write sb: I/O error
>> Or
>> WARNING: failed to write all sb data
>>
>> There is no info about which devi
On 27.03.19 г. 9:24 ч., Qu Wenruo wrote:
> When we failed to write super blocks, we just output something like:
> WARNING: failed to write sb: I/O error
> Or
> WARNING: failed to write all sb data
>
> There is no info about which device failed and there are two different
> error message for
When we failed to write super blocks, we just output something like:
WARNING: failed to write sb: I/O error
Or
WARNING: failed to write all sb data
There is no info about which device failed and there are two different
error message for the same write error.
This patch will change it to somet
[BUG]
There are tons of reports of btrfs-progs screwing up the fs, the most
recent one is "btrfs check --clear-space-cache v1" triggered BUG_ON()
and then leaving the fs with transid mismatch problem.
[CAUSE]
In kernel, we have block layer handing the flush work, even on devices
without FUA suppor
This urgent patchset can be fetched from github:
https://github.com/adam900710/btrfs-progs/tree/flush_super
Which is based on v4.20.2.
Before this patch, btrfs-progs writes to the fs has no barrier at all.
All metadata and superblock are just buffered write, no barrier between
super blocks and met
55 matches
Mail list logo
