When printing tree nodes, we output slots like:
key (EXTENT_TREE ROOT_ITEM 0) block 73625600 (17975) gen 16
The number in the parentheses is blockptr / nodesize.
However this number doesn't really do any thing useful.
And in fact for unaligned metadata block group (block group start bytenr
is not
On 23.08.2018 00:38, Liu Bo wrote:
> hmm, looks like the current mutex with adaptive spinning doesn't offer
> read/write version, meaning we're not able to simple drop rwlock.
What about rw_semaphores?
On 2018/8/23 上午11:25, Zirconium Hacker wrote:
> Hi.
> My primary (boot) filesystem is broken, due to an interrupted resize
> operation.
> I'm hoping that I can get help either fixing the filesystem or
> recovering some of my data, but I'd also like to know why btrfs and
> its tools acted the way
On 2018/8/23 上午11:11, Zygo Blaxell wrote:
> This is a repro script for a btrfs bug that causes corrupted data reads
> when reading a mix of compressed extents and holes. The bug is
> reproducible on at least kernels v4.1..v4.18.
This bug already sounds more serious than previous nodatasum +
com
Austin S. Hemmelgarn posted on Wed, 22 Aug 2018 07:30:09 -0400 as
excerpted:
>> Meanwhile, since broken rootflags requiring an initr* came up let me
>> take the opportunity to ask once again, does btrfs-raid1 root still
>> require an initr*? It'd be /so/ nice to be able to supply the
>> appropria
Hi.
My primary (boot) filesystem is broken, due to an interrupted resize operation.
I'm hoping that I can get help either fixing the filesystem or
recovering some of my data, but I'd also like to know why btrfs and
its tools acted the way they did.
I think I've also found a bug in GParted.
Output
This is a repro script for a btrfs bug that causes corrupted data reads
when reading a mix of compressed extents and holes. The bug is
reproducible on at least kernels v4.1..v4.18.
Some more observations and background follow, but first here is the
script and some sample output:
root@res
On 2018/8/23 上午3:51, Liu Bo wrote:
> Several structs in btrfs are using rb_first() in a while loop, it'd be
> more efficient to do this with rb_first_cached() which has the O(1)
> complexity.
I'm a little curious about such rb_first() inside loop usage.
What I can find is mostly deletion + iter
On 2018/8/23 上午3:14, Liu Bo wrote:
> As next_state() is already defined to get the next state, update us to use
> the helper.
>
> No functional changes.
>
> Signed-off-by: Liu Bo
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> fs/btrfs/extent_io.c | 7 +--
> 1 file changed, 1 insertion(+),
Unless it's going to read inline extents from btree leaf to page,
btrfs_get_extent won't sleep during the period of holding path lock.
This sets leave_spinning at first and sets path to blocking mode right
before reading inline extent if that's the case. The benefit is that a
path in spinning mod
trace_btrfs_get_extent() has nothing to do with path, place
btrfs_free_path ahead so that we can unlock path on error.
Signed-off-by: Liu Bo
---
fs/btrfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 31d43355f052..6a0380f3f3
Unless it's going to read inline extents from btree leaf to page,
btrfs_get_extent won't sleep during the period of holding path lock.
This sets leave_spinning at first and sets path to blocking mode right
before reading inline extent if that's the case. The benefit is that a
path in spinning mod
On Tue, Aug 21, 2018 at 02:48:47PM -0400, Chris Mason wrote:
> On 21 Aug 2018, at 14:15, Liu Bo wrote:
>
> > On Tue, Aug 21, 2018 at 01:54:11PM -0400, Chris Mason wrote:
> > > On 16 Aug 2018, at 17:07, Liu Bo wrote:
> > >
> > > > The lock contention on btree nodes (esp. root node) is apparently a
rb_first_cached() trades an extra pointer "leftmost" for doing the
same job as rb_first() but in O(1).
As evict_inode_truncate_pages() removes all extent mapping by always
looking for the first rb entry, it's helpful to use rb_first_cached
instead.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_map.
rb_first_cached() trades an extra pointer "leftmost" for doing the same
job as rb_first() but in O(1).
Functions manipulating href->ref_tree need to get the first entry, this
converts href->ref_tree to use rb_first_cached().
Signed-off-by: Liu Bo
---
fs/btrfs/backref.c | 2 +-
fs/btrfs/del
Several structs in btrfs are using rb_first() in a while loop, it'd be
more efficient to do this with rb_first_cached() which has the O(1)
complexity.
This patch set updates five structs which may have a large rb tree in
practice
Liu Bo (5):
Btrfs: href_root: use rb_first_cached
Btrfs: href->
rb_first_cached() trades an extra pointer "leftmost" for doing the
same job as rb_first() but in O(1).
Functions manipulating href_root need to get the first entry, this
converts href_root to use rb_first_cached().
Signed-off-by: Liu Bo
---
fs/btrfs/delayed-ref.c | 26 +++---
rb_first_cached() trades an extra pointer "leftmost" for doing the same
job as rb_first() but in O(1).
Functions manipulating delayed_item need to get the first entry, this
converts it to use rb_first_cached().
Signed-off-by: Liu Bo
---
fs/btrfs/delayed-inode.c | 29
rb_first_cached() trades an extra pointer "leftmost" for doing the same
job as rb_first() but in O(1).
While resolving indirect refs and missing refs, it always looks for the
first rb entry in a while loop, it's helpful to use rb_first_cached
instead.
Signed-off-by: Liu Bo
---
fs/btrfs/backref.
As next_state() is already defined to get the next state, update us to use
the helper.
No functional changes.
Signed-off-by: Liu Bo
---
fs/btrfs/extent_io.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 628f1aef34b0..
On Wed, Aug 22, 2018 at 03:13:28PM +0200, David Sterba wrote:
> On Wed, Aug 22, 2018 at 05:54:37AM +0800, Liu Bo wrote:
> > w/o patch:
> > real2m27.307s
> > user0m12.839s
> > sys 13m42.831s
> >
> > w/ patch:
> > real1m2.273s
> > user0m15.802s
> > sys 8m16.495s
>
> This loo
On 2018-08-22 11:01, David Sterba wrote:
On Wed, Aug 22, 2018 at 09:56:59AM -0400, Austin S. Hemmelgarn wrote:
On 2018-08-22 09:48, David Sterba wrote:
On Tue, Aug 21, 2018 at 01:01:00PM -0400, Austin S. Hemmelgarn wrote:
On 2018-08-21 12:05, David Sterba wrote:
On Tue, Aug 21, 2018 at 10:10:
Hi Chris,
Here's a pre-preview of my conversion of btrfs to the mount API:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=btrfs-mount-api
The last patch is the one that does the heavy lifting.
The code compiles and you can load the module. in theory it sh
On Wed, Aug 22, 2018 at 09:56:59AM -0400, Austin S. Hemmelgarn wrote:
> On 2018-08-22 09:48, David Sterba wrote:
> > On Tue, Aug 21, 2018 at 01:01:00PM -0400, Austin S. Hemmelgarn wrote:
> >> On 2018-08-21 12:05, David Sterba wrote:
> >>> On Tue, Aug 21, 2018 at 10:10:04AM -0400, Austin S. Hemmelga
On 2018-08-22 09:48, David Sterba wrote:
On Tue, Aug 21, 2018 at 01:01:00PM -0400, Austin S. Hemmelgarn wrote:
On 2018-08-21 12:05, David Sterba wrote:
On Tue, Aug 21, 2018 at 10:10:04AM -0400, Austin S. Hemmelgarn wrote:
On 2018-08-21 09:32, Janos Toth F. wrote:
so pretty much everyone who w
On Tue, Aug 21, 2018 at 01:01:00PM -0400, Austin S. Hemmelgarn wrote:
> On 2018-08-21 12:05, David Sterba wrote:
> > On Tue, Aug 21, 2018 at 10:10:04AM -0400, Austin S. Hemmelgarn wrote:
> >> On 2018-08-21 09:32, Janos Toth F. wrote:
> >> so pretty much everyone who wants to avoid the overhead
On Wed, Aug 22, 2018 at 05:54:37AM +0800, Liu Bo wrote:
> w/o patch:
> real2m27.307s
> user0m12.839s
> sys 13m42.831s
>
> w/ patch:
> real1m2.273s
> user0m15.802s
> sys 8m16.495s
This looks good. The change does not have any potential correctness
problems right? I'm asking
On 2018-08-21 23:57, Duncan wrote:
Austin S. Hemmelgarn posted on Tue, 21 Aug 2018 13:01:00 -0400 as
excerpted:
Otherwise, the only option for people who want it set is to patch the
kernel to get noatime as the default (instead of relatime). I would
look at pushing such a patch upstream myself
28 matches
Mail list logo