Can be fetched from github:
https://github.com/adam900710/linux/tree/refactor_find_free_extent
Which is based on v4.19-rc1.
extent-tree.c::find_free_extent() could be one of the most
ill-structured functions, it has at least 6 non-exit tags and jumps
between them.
Refactor it into 4 parts:
1) f
We have a complex loop design for find_free_extent(), that has different
behavior for each loop, some even includes new chunk allocation.
Instead of putting such a long code into find_free_extent() and makes it
harder to read, just extract them into find_free_extent_update_loop().
With all the cl
Instead of tons of different local variables in find_free_extent(),
extract them into find_free_extent_ctl structure, and add better
explanation for them.
Some modification may looks redundant, but will later greatly simplify
function parameter list during find_free_extent() refactor.
Signed-off-
We have two main methods to find free extents inside a block group:
1) clustered allocation
2) unclustered allocation
This patch will extract the clustered allocation into
find_free_extent_clustered() to make it a little easier to read.
Instead of jumping between different labels in find_free_ext
This patch will extract unclsutered extent allocation code into
find_free_extent_unclustered().
And this helper function will use return value to indicate what to do
next.
This should make find_free_extent() a little easier to read.
Signed-off-by: Qu Wenruo
Reviewed-by: Su Yue
Reviewed-by: Jos
On 10/17/2018 03:49 AM, Chris Murphy wrote:
On Tue, Oct 16, 2018 at 2:13 AM, Anand Jain wrote:
On 10/14/2018 06:28 AM, Chris Murphy wrote:
Is it practical and desirable to make Btrfs based OS installation
images reproducible? Or is Btrfs simply too complex and
non-deterministic? [1]
The
Dear
I earn a living in the oil industry as leader of the Procurement Unit/account
department in a refining outfit owned by a Sasol SA.
On my desk is a mandate to arrange for crude oil purchase from Libya for up to
2,000,000 barrels on monthly bases for 12 calendar months.
The essence of my rea
On 2018/10/16 下午11:25, Anton Shepelev wrote:
> Qu Wenruo to Anton Shepelev:
>
>>> On all our servers with BTRFS, which are otherwise working
>>> normally, `btrfs check /' complains that
>>>
>>> Superblock bytenr is larger than device size
>>> Couldn't open file system
>>>
>> Please try latest bt
On 2018/10/17 上午5:27, Dmitry Katsubo wrote:
> Dear btrfs team,
>
> I often observe kernel traces on linux-4.14.0 (mostly likely due to background
> "btrfs scrub") which contain the following "characterizing" line (for the rest
> see attachments):
>
> btrfs_remove_chunk+0x26a/0x7e0 [btrfs]
>
>
Dear btrfs team / community,
Sometimes it happens that kernel resets USB subsystem (looks like hardware
problem). Nevertheless all USB devices are unattached and attached back. After
few hours of struggle btrfs finally comes to the situation when read-only
filesystem mount is necessary. During thi
Dear btrfs team,
I often observe kernel traces on linux-4.14.0 (mostly likely due to background
"btrfs scrub") which contain the following "characterizing" line (for the rest
see attachments):
btrfs_remove_chunk+0x26a/0x7e0 [btrfs]
I wonder if somebody from developers team knows anything about t
On Tue, Oct 16, 2018 at 9:42 AM, Austin S. Hemmelgarn
wrote:
> On 2018-10-16 11:30, Anton Shepelev wrote:
>>
>> Hello, all
>>
>> What may be the reason of a CRC mismatch on a BTRFS file in
>> a virutal machine:
>>
>> csum failed ino 175524 off 1876295680 csum 451760558
>> expected csum 144
On Tue, Oct 16, 2018 at 2:13 AM, Anand Jain wrote:
>
>
> On 10/14/2018 06:28 AM, Chris Murphy wrote:
>>
>> Is it practical and desirable to make Btrfs based OS installation
>> images reproducible? Or is Btrfs simply too complex and
>> non-deterministic? [1]
>>
>> The main three problems with Btrfs
On 2018-10-16 11:30, Anton Shepelev wrote:
Hello, all
What may be the reason of a CRC mismatch on a BTRFS file in
a virutal machine:
csum failed ino 175524 off 1876295680 csum 451760558
expected csum 1446289185
Shall I seek the culprit in the host machine on in the guest
one? Supposin
Hello, all
What may be the reason of a CRC mismatch on a BTRFS file in
a virutal machine:
csum failed ino 175524 off 1876295680 csum 451760558
expected csum 1446289185
Shall I seek the culprit in the host machine on in the guest
one? Supposing the host machine healty, what operations on
t
Qu Wenruo to Anton Shepelev:
>>On all our servers with BTRFS, which are otherwise working
>>normally, `btrfs check /' complains that
>>
>>Superblock bytenr is larger than device size
>>Couldn't open file system
>>
>Please try latest btrfs-progs and see if btrfs check
>reports any error.
It is SUS
On 2018/10/16 下午10:05, Anton Shepelev wrote:
> Hello, all
>
> On all our servers with BTRFS, which are otherwise working
> normally, `btrfs check /' complains that
Btrfs check shouldn't continue on mount point.
Latest one would report error like:
Opening filesystem to check...
ERROR: not
Hello, all
On all our servers with BTRFS, which are otherwise working
normally, `btrfs check /' complains that
Superblock bytenr is larger than device size
Couldn't open file system
Since am not using any "dangerous" options and want merely
to analyse the system for errors without any modi
On Fri, Oct 12, 2018 at 01:59:34PM -0700, Andrew Morton wrote:
> On Tue, 11 Sep 2018 15:34:44 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > The SWP_FILE flag serves two purposes: to make swap_{read,write}page()
> > go through the filesystem, and to make swapoff() call
> > ->swap_
On 10/14/2018 07:08 PM, waxhead wrote:
In case BTRFS fails to WRITE to a disk. What happens?
Does the bad area get mapped out somehow?
There was a proposed patch, its not convincing because the disks does
the bad block relocation part transparently to the host and if disk runs
out of r
On Sat, Oct 13, 2018 at 12:37:25AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> At inode.c:compress_file_range(), under the "free_pages_out" label, we can
> end up dereferencing the "pages" pointer when it has a NULL value. This
> case happens when "start" has a value of 0 and we f
On 10/14/2018 06:28 AM, Chris Murphy wrote:
Is it practical and desirable to make Btrfs based OS installation
images reproducible? Or is Btrfs simply too complex and
non-deterministic? [1]
The main three problems with Btrfs right now for reproducibility are:
a. many objects have uuids other t
22 matches
Mail list logo
